Read only archive ; use https://github.com/JacORB/JacORB/issues for new issues
Bug 1007 - Server connecting to multiple clients simultaneously sometimes re-uses a connection for more than one client
Summary: Server connecting to multiple clients simultaneously sometimes re-uses a conn...
Status: RESOLVED FIXED
Alias: None
Product: JacORB
Classification: Unclassified
Component: ORB (show other bugs)
Version: 3.5
Hardware: Sun Solaris
: P5 blocker
Assignee: Mailinglist to track bugs
URL:
Depends on:
Blocks:
 
Reported: 2015-03-19 20:07 UTC by Eric Stout
Modified: 2015-05-12 16:40 UTC (History)
1 user (show)

See Also:


Attachments
Test IDL, Java sources, class files, run scripts, and sample output (67.56 KB, application/zip)
2015-03-19 20:07 UTC, Eric Stout
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Stout 2015-03-19 20:07:05 UTC
Created attachment 458 [details]
Test IDL, Java sources, class files, run scripts, and sample output

When we attempted to upgrade from JacORB 3.4 to JacORB 3.6 (version selector didn't offer 3.6 as an option), we encountered a situation as follows:

1. Multiple clients (roughly 10) register themselves with a server via an IDL-defined method
2. The server later tries to call all of the clients for the first time simultaneously, using multiple threads
3. Some of the clients receive multiple calls, while some receive none.

This occurred with the server running on a pretty high-powered Sun Solaris host (8 cores, each 8x hyperthreaded, I think).

I have distilled this into the attached test case, which appears to successfully reproduce the problem on a similar Sun Solaris host, using both Java 1.7.0u13 and Java 1.8.0u25.  I was not able to reproduce the problem running the same test on either Linux or Windows hosts that were available to me.

See the README file in the attached zip for more information about configuring and running the test.
Comment 1 Nick Cross 2015-05-12 16:40:36 UTC
Thanks to a considerable amount of testing from Eric we have successfully narrowed down the problem to a single SHA change and identified the problem.

Committed with 7a02b594a4f4609d05ee94990b18ba178b3c88d7