Created attachment 453 [details] Debug log I have a simple multithreaded client to singlethreaded server test that works fine from JacORB 2.4 - 3.3 which started throwing COMM_FAILUREs at me starting with JacORB 3.4 (but also in 3.5). The test implements a trivial client for the following IDL: interface Foo { string get_string(in long tid); }; The server creates and activates a single servant and executes ORB#run in the main thread. The client resolves the servant reference, starts 2 threads and calls the servant's get_string() method 10 times in each thread. The client uses DII and the server DSI. When running this with either JacORB 3.4 or 3.5 at a certain point in the iterations COMM_FAILUREs appear. Detailed logging seems to suggest connections are being unexpectedly closed at some point. Attached a debug log of a fairly typical testrun. Any ideas why this may have started happening from JacORB 3.4?
Hi, Would you be able to supply your test case please? Related tickets would be bug 986, bug 967 and bug 975
I'll try to put together a Java test shortly. My current test environment is not using Java directly. Instead I use jR2CORBA which is a JRuby CORBA implementation using JacORB as underlying ORB implementation. In the meantime I tested with the suggested workaround from the related tickets you mentioned but that only resulted in some sort of unending failure loop. Attaching a sample of the resulting debug log.
Created attachment 454 [details] Looping failure after jacorb.connection.client.disconnect_after_systemexception workaround
That loop matches the problem I think from bug 967. Could you adapt a unit test from https://github.com/JacORB/JacORB/tree/master/test/regression/src/test/java/org/jacorb/test/dii to replicate the issue?
Created attachment 455 [details] Patched regression test with multithreaded testcase Please find attached a (very) simple testcase which reliably triggers the COMM_FAILURE as I encountered it. I simply updated the standard regression test commenting out all exisiting tests and adding a new one running two threads performing 10 requests each. In my environment each time I run this test one of the threads will reliably fail with a COMM_FAILURE at some point.
Fixed by SHA 4343aeb31a7ba80c44280ffa7857e249eb4734f4