We have to work with fixed TCP-ports, configured with the OASSLPort property. The start of the first instance of our software works correctly. If you try to start another instance on the same machine, the socket can't be created - that's ok because the first instance already owns this port. You get an exception. But if you try again to get the RootPOA, then you get a RootPOA (which isn't working) instead of an exception as with the first attempt. Afterwards the System does not see the difference between a working POA and a POA without proper Socket, so every request on the specified port reaches the first instance of our software, while the second instance doesn't know that it can't be called. The reason can be found in ORB.getRootPOA(). The whole content of the method will be executed only when rootpoa-classmember is null. Then the member is assigned and in a try-catch-block the creation of the socket is tried. If it fails, the exception is catched and another exception is thrown - but the member contains already the POA which isn't configured yet. If you catch the thrown exception and call the method getRootPOA() again, then the if-statement evaluates to false and the unconfigured POA is returned. The calling code works with it assuming it is reachable on the socket, but it isn't. In my opinion the method shouldn't deliver non-working POAs. It should throw an exception every time I try to get an POA on an port, which isn't free. Every time, not only the first time. Perhaps there is a correllation to bug 886 which is about a problem reaching the second client on the same machine.
Can you provide a test case please?
I don't have an explicit testcase, because I debugged our application. But what we do is the following: 1) When our client starts, it has to provide a SSL-socket for the appserver to allow it to call the client actively, so the client does: 2) Calling ORB.init(...) to obtain an ORB-instance 3) Calling resolve_initial_references("root.poa") on that ORB 4) If we get an exception from that method, we display an error-popup to the user 5) The user can click ok and try again to log in => step 3 is performed again on the same ORB-instance from first attempt => now the exception isn't thrown and we get a POA on which we work => The user gets logged in, but the client has an uninitialized POA without socket. The client isn't reachable, the application doesn't work correctly.
If you could provide a test case by adapting one of the existing test cases or by adapting the JacORB demo code that would be really helpful :-)
Ok, I modified the SSL-Demo-Code. I will attach the new Server.java here. But some instructions first: 1) Replace the Server.java with my version. 2) We do not need a client, deactivate it bei adding System.exit(0) as first line of the Main-method in Client.java 3) Make a copy of the whole SSL-demo directory, because we need two servers 4) open a console in each of the directories 5) run the demo in the first console 6) if "now waiting" appears, start the demo from second console The first instance is not interesting for us, it does what it has to do. The second instance will struggle in its first attempt to get the socket, because I configured both instances to use the same port (7777). Thats right. But then it tries again on the same ORB-object to get the rootPOA - but now we don't get an exception, but a poa which has not socket. The rest of the program works on it without realizing, the poa is dead. Hint: the logged Stacktrace is sometimes printed out at the wrong place. Simply look at the line numbers. The exception corresponds to the first attempt.
Created attachment 408 [details] Modified Server.java to demonstrate the problem
Thank you for the test case. Reproduced ; I'll get the fix in for the next release.
Fixed with https://github.com/JacORB/JacORB/pull/54