Hi Mageshwaran,

SEGMENT_SIZE must be power of 2 in order to fit into max long (in case that message xid reaches 2^64). But that is just an implementation detail.

Queue segments are arrays and amount of used instances is driven by demand from consumer (e.g.: ofplugin outbound mechanism). By low traffic there might be only 2 segment instances used. As soon as the first one is full then the overlaying outbound queue takes the second one. And as soon as all messages in the first segment are done (confirmed, failed or covered by subsequent barrier)  then the first segment gets recycled. The original message reference is erased upon being sent and corresponding callback reference is erased upon completion/failure fired. This makes segment entries (OutboundQueueEntry) friendly to garbage collector.

In nutshell :

 Segments are cheap.

 And as soon as a OF message is subject to rpc (or some asynchronous mechanism) then it is essential to detect when device finished processing it.

 In my opinion - until there is no profiling data pointing at memory leak around outbound queue and segments I would postpone any optimization. Especially when based on setups with low utilization.

Regarding the RpcResponseKey - this is the old way of getting device reply within a hardcoded interval. It is still used before the outbound queue mechanism is plugged in (between connection established and protocol handshake finish).

Regards,

Michal