Bug 3909 - AMI replies handled differently depending on ORB initialization order
Summary: AMI replies handled differently depending on ORB initialization order
Status: NEW
Alias: None
Product: TAO
Classification: Unclassified
Component: AMI (show other bugs)
Version: 1.8.2
Hardware: All All
: P3 normal
Assignee: DOC Center Support List (internal)
URL:
Depends on:
Blocks:
 
Reported: 2010-10-06 15:59 CDT by Chris Cleeland
Modified: 2010-10-07 09:34 CDT (History)
0 users

See Also:

Attachments
Test case that replicates the issue. (27.29 KB, application/x-gzip)
2010-10-06 15:59 CDT, Chris Cleeland 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cleeland 2010-10-06 15:59:11 CDT 
Created attachment 1319 [details]
Test case that replicates the issue.

In the course of trying to reproduce a problem experienced at a customer site, I began modifying the PortableInterceptors/AMI test to be like customer code.  While I was not able to reproduce the customer's issue, I stumbled on to anomalous behavior with regard to processing of AMI replies.

What I found is that if the client is using AMI, and creates two ORBs ("orb1" and "orb2", for example) and creates them in that order, but does all the Object activations in orb2, the replies do not come back through orb2.

However, if the order of ORB creation is reversed, replies come back through orb2.

Unfortunately, the customer has chosen not to pursue any further investigation or resolution, so I don't have much license to dig into it, but it does seem worthwhile to at least log the issue into bugzilla since I've gotten this far.

To reproduce the problem, build the attached code.  It will produce three executables: server, client_otherorbfirst, and client_otherorblast.

Run the server, then run client_otherorbfirst.  This is the failing case.

Run the server, then run client_otherorblast.  This case behaves just as a single-ORB would.
Comment 1 Johnny Willemsen 2010-10-07 01:52:46 CDT 
Chris, would it be possible that you add the test program to svn head and enable it in the test suite? Than we can at least see that it fails on svn head, maybe somewhere in the future other changes are than made that resolve this bug
Comment 2 Chris Cleeland 2010-10-07 09:34:00 CDT 
I will try to find the time to turn this back into a test that can run in an automated fashion, but it might take some time to get that done.  FWIW, this was tested against svn head that was relatively current immediately before I filed the bug (r92026 according to my workspace).

There may well be a bug in my test, too, so it might be beneficial for another set of eyes to check out the code to insure nothing blatantly stupid is being done in there.  Most of the code is identical to the original test from which this was derived.  I believe that I only changed the client code.