Read only archive ; use for new issues
Bug 1027 - BiDir IIOP fails when client creates a callback IOR with alternate addresses
Summary: BiDir IIOP fails when client creates a callback IOR with alternate addresses
Status: RESOLVED DUPLICATE of bug 1026
Alias: None
Product: JacORB
Classification: Unclassified
Component: ORB (show other bugs)
Version: 3.7
Hardware: PC All
: P5 minor
Assignee: Mailinglist to track bugs
Depends on:
Reported: 2016-02-10 16:58 CET by Phil Mesnier
Modified: 2016-05-03 02:46 CEST (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Phil Mesnier 2016-02-10 16:58:20 CET
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.
Comment 1 Phil Mesnier 2016-02-10 17:04:09 CET

*** This bug has been marked as a duplicate of bug 1026 ***
Comment 2 Gergely Jakab 2016-05-03 02:46:40 CEST
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

Phil, do You think You could get to this matter any time soon?