[tao-users] Stale connections with BiDirGIOP

[Milan Cvetkovic]

     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
include ${ACE_ROOT}/include/makeinclude/platform_linux.GNU

     AREA/CLASS/EXAMPLE AFFECTED:
	BiDirGIOP / Transport_Cache_Manager_T / SSLIOP
     DOES THE PROBLEM AFFECT:
         EXECUTION: YES

    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.

DESCRIPTION:

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 
still cached.

Thanks, Milan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bidir-timeout.log
Type: text/x-log
Size: 2670 bytes
Desc: not available
URL: <http://list.isis.vanderbilt.edu/pipermail/tao-users/attachments/20151012/4585cde0/attachment.bin>