TAO VERSION: 2.2.1
ACE VERSION: 6.2.1
HOST MACHINE and OPERATING SYSTEM: Debian wheezy on x86_64
THE $ACE_ROOT/ace/config.h FILE: config-linux.h
THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE:
c++11 = 1
ssl = 1
BiDirGIOP / Transport_Cache_Manager_T / SSLIOP
DOES THE PROBLEM AFFECT:
SYNOPSIS: After loss of network connection from a client, server is
no longer able to invoke callback RPCs, even after client reconnected,
and resubmitted its callback IOR.
I have BiDirGIOP setup over SSLIOP. Client is behind firewall router on 192.168.12.x network. Client incarnates callback object, listening on 192.168.12.113:7770 and port 7771 for ss. Client contacts the server
over the internet, and it sends the IOR to callback object above. Server later uses callback object to send various notifications. This setup
utilizes bidirectional GIOP, over SSLIOP.
Everything works as desired, until client loses connectivity to server.
When client re-registers, server adds the new Transport to Transport
cache manager, however in some scenarios it does not remove the old transport, and keeps using it for callbacks, failing on CORBA::TIMEOUT
My understanding is that Transport_Cache_Manager keeps the hash map
table of all connections. These connections have the same key, being
issued from the same IP:port every time (in the example above, 192.168.12.113:7771). In some cases, the server does not replace the
existing transport entry, but adds it with an increased index, and keeps using index:0 for making callbacks.
I am attaching the portions of TAO logs. Note that second registration
binds with index :1. The stale transport is kept with index :0.
How do I control the content of Transport_Cache_Manager_T. I removed the references to callback objects from server, however the transport is
|Location:||Huddersfield, West Yorkshire, UK|
|Nodes:||8 (1 / 7)|