I found this while working with BidirGIOP, and reported on mailing lists:

https://groups.google.com/forum/#!topic/comp.soft-sys.ace/w5fhVVwJqB4

Transport_Cache_Manager uses hash map to keep ip:port:index->Transport mappings. 

When there are multiple transports with same IP:port values, key in Cache_ExtId is modified with a new value of index:1, resulting in a different hash value.
If all connections are up, and index:0 is BUSY Transport_Cache_Manager_T::find_i would loop and make another lookup with index:1. As long as all Transports to this IP:port are alive, everything works.

However, if the first established transport is closed, entry with index:0 would be removed, but any other existing (and perhaps available) entries with higher indexes would no longer be reachable. This is amplified in BiDirGIOP use case, if the remote client uses same ip and port for callbacks after each restart