[jacorb-bugs] [Bug 1027] New: BiDir IIOP fails when client creates a callback IOR with alternate addresses

[bugzilla-daemon at jacorb.org]

http://www.jacorb.org/bugzilla/show_bug.cgi?id=1027

            Bug ID: 1027
           Summary: BiDir IIOP fails when client creates a callback IOR
                    with alternate addresses
           Product: JacORB
           Version: 3.7
          Hardware: PC
                OS: All
            Status: NEW
          Severity: minor
          Priority: P5
         Component: ORB
          Assignee: jacorb-bugs at lists.spline.inf.fu-berlin.de
          Reporter: mesnierp at ociweb.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spline.inf.fu-berlin.de/pipermail/jacorb-bugs/attachments/20160210/35b41274/attachment.html>