[BZ-4207] Transport Cache Manager does not allow access to index:1 when transport at index:0 is closed #4207
Description
| Field | Value |
|---|---|
| Bugzilla ID | 4207 |
| Reporter | milan.cvetkovic |
| Assigned to | DOC Center Support List (internal) |
| Product | TAO |
| Component | ORB |
| Version | 2.3.3 |
| Platform / OS | x86 / Linux |
| Priority | P3 |
| Severity | normal |
| Status | NEW |
| Resolution | |
| Created | 2015-11-06 21:31:21 -0600 |
Originally posted by milan.cvetkovic on 2015-11-06 21:31:21 -0600
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