When the client is on a multi-homed host, and the listen endpoint is defaulted, The BiDirConnectionClientInterceptor will create a service context containing only the primary address, so the server interceptor synthesizes a profile with only one address, which is then added to the connection cache. Later, the client sends a callback IOR that contains 1 or more alternate addresses as Tagged Components. This means that when the server wants to invoke on the callback, the ClientConnectionManager fails to find the previously added connection since the profile sans-alternates is not equal to the profile with-alternates, even though the primary addresses match.
It turns out that IIOPProfile has a "final" value called checkAlternateAddresses that in the case of a defaulted listen endpoint is set to false, but later the IIOPListener object calls a method, addAllWildcardAddresses, which appends the remaining interface addresses as alternates.
My solution is to remove the finality from checkAlternateAddresses and set it to true if there are indeed extra addresses to add to the alternates. I'll attach a patch shortly.
BTW, I believe the table managed by the ClientConnectionManager is inappropriately keyed. It is keyed with a Profile, which contains possibly multiple addresses, which in turn may relate to multiple connections as well as non-connection related stuff. I think the connections table should be keyed by an address, which had it been so, the need to pass multiple alternate addresses in the bidir service context goes away. This would require some additional refactoring inside the connection manager, but I don't think there are any interface changes to affect any other classes.
*** This bug has been marked as a duplicate of bug 1026 ***
I believe that Your first suggestion for the fix will not be sufficient, because in my case the IIOPProfile which has checkAlternateAddresses == false has also empty attribute components, so even if checkAlternateAddresses would be true, it has nowhere to read from the alternate addresses.
My IIOPProfile is created in the BiDirConnectionServerInterceptor.addConnections() via the constructor
public IIOPProfile(IIOPAddress address, byte objectKey, int minor)
Details about my scenario are in this post:
So I would suggest rather the refactoring of ClientConnectionManager to get rid of IIOPProfiles from the connection mapping.
Looks like in our case this bug is quite serious as it affects not only the clients which have multiple physical network interfaces active, but on many windows machines there is some pseudo-interface installed by default to support IPv6. It is called Teredo Tunneling Pseudo-Interface http://superuser.com/questions/22290/what-is-the-teredo-tunneling-pseudo-interface
Phil, do You think You could get to this matter any time soon?