Read only archive ; use https://github.com/JacORB/JacORB/issues for new issues
Bug 848 - multiple profiles not handled correctly
Summary: multiple profiles not handled correctly
Status: RESOLVED FIXED
Alias: None
Product: JacORB
Classification: Unclassified
Component: ORB (show other bugs)
Version: 2.3.0 beta 2
Hardware: All All
: P2 major
Assignee: André Spiegel
URL:
Depends on:
Blocks:
 
Reported: 2008-12-17 18:17 UTC by ciju john
Modified: 2014-10-12 16:29 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ciju john 2008-12-17 18:17:10 UTC
Given a multiple profile IOR JacORB only uses the first profile. e.g.

) Create a multi-profile object IOR using TAO:
   ./server -orbendpoint iiop://oci1176.ociweb.com:12345/hostname_in_ior=mosquito.ociweb.com -orbendpoint iiop://oci1176.ociweb.com:12346 -ORBUseSharedProfile 0
  The first profile has a dummy host name, but the second profile is valid.

) Run JacORB client:
   [simple_corba] jaco -classpath generated_java:$CLASSPATH Client -f -n 1
[jacorb.orb.print_ver] INFO :
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        JacORB V 2.3.0, www.jacorb.org
        (C) The JacORB project 17-Feb-2007
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IOR:000000000000000F49444C3A4D79546573743A312E3000000000000200000000000000840101022A140000006D6F73717569746F2E6F63697765622E636F6D0039302A2A2B00000014010F004E53500000000001000000526F6F74504F410070657273697374000000000001000000010000002A020000000000000008000000012A2A2A004F41540100000018000000012A2A2A010001000100000001000105090101000000000000000000000000840101022A130000006F6369313137362E6F63697765622E636F6D002A3A302A2A2B00000014010F004E53500000000001000000526F6F74504F410070657273697374000000000001000000010000002A020000000000000008000000012A2A2A004F41540100000018000000012A2A2A0100010001000000010001050901010000000000

org.omg.CORBA.TRANSIENT: Retries exceeded, couldn't reconnect to 10.201.200.127:12345
        at org.jacorb.orb.iiop.ClientIIOPConnection.connect(ClientIIOPConnection.java:214)
        at org.jacorb.orb.giop.GIOPConnection.sendMessage(GIOPConnection.java:936)
        at org.jacorb.orb.giop.GIOPConnection.sendRequest(GIOPConnection.java:902)
        at org.jacorb.orb.giop.ClientConnection.sendRequest(ClientConnection.java:291)
        at org.jacorb.orb.giop.ClientConnection.sendRequest(ClientConnection.java:272)
        at org.jacorb.orb.Delegate.invoke_internal(Delegate.java:1033)
        at org.jacorb.orb.Delegate.invoke(Delegate.java:939)
        at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:80)
        at _MyTestStub.ping(_MyTestStub.java:167)
        at Client.main(Client.java:197)

Client doesn't attempt to resolve the second profile. I doubt my usage is wrong. My Client attempts narrow twice before giving up.

Ciju
Comment 1 André Spiegel 2008-12-17 19:34:10 UTC
This feature is regularly tested in the JacORB regression suite, and appears to work fine.  It relies on TAG_ALTERNATE_IIOP_ADDRESS, as per the spec.

Please have a look at AlternateIIOPAddressTest and specifically the IIOPAddressInterceptor in test/regression/src, package org.jacorb.test.orb.

Maybe that can clarify the intended usage.  If you still believe there's a bug in how JacORB handles this, please let us know.
Comment 2 ciju john 2008-12-17 19:45:19 UTC
(In reply to comment #1)
> This feature is regularly tested in the JacORB regression suite, and appears to
> work fine.  It relies on TAG_ALTERNATE_IIOP_ADDRESS, as per the spec.

TAG_ALTERNATE_IIOP_ADDRESS is different from multi-profile IOR. With TAG_ALTERNATE_IIOP_ADDRESS only an alternate address can be specified. You will need multi-prfoles to specify different transport protocols. e.g. iiop & ssliop. The IOR in my example

IOR:000000000000000F49444C3A4D79546573743A312E3000000000000200000000000000840101022A140000006D6F73717569746F2E6F63697765622E636F6D0039302A2A2B00000014010F004E53500000000001000000526F6F74504F410070657273697374000000000001000000010000002A020000000000000008000000012A2A2A004F41540100000018000000012A2A2A010001000100000001000105090101000000000000000000000000840101022A130000006F6369313137362E6F63697765622E636F6D002A3A302A2A2B00000014010F004E53500000000001000000526F6F74504F410070657273697374000000000001000000010000002A020000000000000008000000012A2A2A004F41540100000018000000012A2A2A0100010001000000010001050901010000000000

or
corbaloc:iiop:$NAME_SERVICE_COMPUTER_1:$NAME_SERVICE_PORT,:$NAME_SERVICE_COMPUTER_2:$NAME_SERVICE_PORT/NameService

should generate two profiles not a single profile with an TAG_ALTERNATE_IIOP_ADDRESS. At least thats my understanding.

> 
> Please have a look at AlternateIIOPAddressTest and specifically the
> IIOPAddressInterceptor in test/regression/src, package org.jacorb.test.orb.
> 
> Maybe that can clarify the intended usage.  If you still believe there's a bug
> in how JacORB handles this, please let us know.

I will take a look at the example. Let me know what you think on my above comment.

Ciju

> 

Comment 3 André Spiegel 2008-12-17 21:47:33 UTC
I haven't looked at this code in quite a while (although I initially wrote it), but here's the result of a brief walk-through.

When an IOR contains multiple profiles, JacORB uses the ProfileSelector class (configurable) to decide which profile to use for establishing a connection.  The DefaultProfileSelector simply chooses the first profile for which a transport implementation is available.

Within the chosen profile, alternate addresses (TAG_ALTERNATE_IIOP_ADDRESS) are tried in order until one succeeds in making a connection.  There is never any attempt to try other profiles from the same IOR after the initial decision.

I believe that JacORB is interpreting the spec correctly here; there is no provision for multiple profiles of the same protocol type in a single IOR.  Some ORBs may in fact work that way, but I believe they are in violation of the spec.

But I have not checked this with the spec right now.  I will do as soon as time permits.
Comment 4 ciju john 2008-12-17 22:38:39 UTC
(In reply to comment #3)
> I haven't looked at this code in quite a while (although I initially wrote it),
> but here's the result of a brief walk-through.
> 
> When an IOR contains multiple profiles, JacORB uses the ProfileSelector class
> (configurable) to decide which profile to use for establishing a connection. 
> The DefaultProfileSelector simply chooses the first profile for which a
> transport implementation is available.

right.

> 
> Within the chosen profile, alternate addresses (TAG_ALTERNATE_IIOP_ADDRESS) are
> tried in order until one succeeds in making a connection.  There is never any
> attempt to try other profiles from the same IOR after the initial decision.

Thats sounds wrong. As an example server IOR has ssliop & iiop profiles. The ssliop connection attempt fails due to configuration. The client should try the iiop profile next, but that never happens in the current implementation. Secondary profiles are rendered useless.

> 
> I believe that JacORB is interpreting the spec correctly here; there is no
> provision for multiple profiles of the same protocol type in a single IOR. 
> Some ORBs may in fact work that way, but I believe they are in violation of the
> spec.

spec 3.0.1 in section 13.6.7 (Profile and Component Composition in IORs) has this:

<quote>
4. Unless otherwise specified in the definition of a particular profile, multiple profiles
   with the same profile tag may be included in an IOR.
</quote>

I think JacORB needs to handle secondary profile, be it be the same protocol or a different one.

Ciju

> 
> But I have not checked this with the spec right now.  I will do as soon as time
> permits.
> 

Comment 5 Nick Cross 2011-10-04 09:32:01 UTC
*** Bug 908 has been marked as a duplicate of this bug. ***
Comment 6 Nick Cross 2011-11-10 21:10:58 UTC
Downgrading priority after discussion with Phil Mesnier.
Comment 7 Nick Cross 2014-10-12 16:29:02 UTC
Fixed by Phil by SHA a45ad1a784a70b4186128249d00268bffd28535a / c6570906b3fa05a4afa420033188b428ccce612c