Please report new issues athttps://github.com/DOCGroup
The size of the dispatcher table in the TAO_Muxed_TMS class currently cannot be configured at ORB initialization time. This prevents more than 1024 (i.e. ACE_DEFAULT_MAP_SIZE) invocations to be simultaneously pending when using the MUXED transport muxing strategy. In practice, this may not be problem since it is unlikely that an application will ever have more than 1024 pending invocations. However, it does unnecessarily increase the memory requirements of applications that will never have 1024 pending invocations in a MUXED transport muxing strategy configuration.
Corrected spelling in subject.
Assigning the bug to me
Accepting the bug
Changed the summary to add more information on the nature of the bug report. There were some ideas floated by Carlos and me thinks they are something to think seriously about. Instead of using a Hash_Map in the Muxed_TMS strategy, we could use a circular array. We could start of with size 16. Once we run out of it we could duplicate at that point. What are the advantages 1. Circular buffer that can be indexed removes the need for forward and reverse pointers and that saves us 8 bytes 2. Starting at 16 elements in size cuts down the size of the Transport object which in turn encapsulates a connection a lot. Some practical issues that Carlos pointed out: ---------------------------------------------------------------- Start with a small array (16 entries or so), to create a request id find the first element "unused" in the array. If you do not find any duplicate the size of the array. Only gotcha I can think of: if a request times out you cannot clear the array element, you need to mark it "timed out" until the reply really arrives. You could end up with a lot of timed out requests taking up space. Using a circular buffer would solve that, but it has other problems (for example, it is significantly more complex, though it can be unit tested!) -------------------------------------------------------------------
to pool