943 2013-02-15 14:52:02 +0000 Misbehaviour in ORB.getRootPOA() when socket could not be created 2013-06-17 06:28:41 +0000 1 1 1 Unclassified JacORB ORB 3.1 PC Windows NT RESOLVED FIXED P2 normal --- 1 christian.bindseil jacorb-bugs jacorb oldest_to_newest 2978 0 christian.bindseil 2013-02-15 14:52:02 +0000 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. 2979 1 jacorb 2013-02-15 15:59:54 +0000 Can you provide a test case please? 2980 2 christian.bindseil 2013-02-15 16:23:03 +0000 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. 2981 3 jacorb 2013-02-15 16:45:44 +0000 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 :-) 2982 4 christian.bindseil 2013-02-18 10:02:37 +0000 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. 2983 5 408 christian.bindseil 2013-02-18 10:03:51 +0000 Created attachment 408 Modified Server.java to demonstrate the problem 2984 6 jacorb 2013-02-18 11:16:00 +0000 Thank you for the test case. Reproduced ; I'll get the fix in for the next release. 3021 7 jacorb 2013-06-17 06:28:41 +0000 Fixed with https://github.com/JacORB/JacORB/pull/54 408 2013-02-18 10:03:51 +0000 2013-02-18 10:03:51 +0000 Modified Server.java to demonstrate the problem Server.java application/octet-stream 2184 christian.bindseil cGFja2FnZSBkZW1vLnNzbDsKCmltcG9ydCBqYXZhLmlvLkZpbGU7CmltcG9ydCBqYXZhLmlvLkZp bGVXcml0ZXI7CmltcG9ydCBqYXZhLmlvLlByaW50V3JpdGVyOwoKaW1wb3J0IG9yZy5vbWcuQ09S QkEuT1JCOwppbXBvcnQgb3JnLm9tZy5Qb3J0YWJsZVNlcnZlci5QT0E7CgovKioKICogVGhpcyBp cyB0aGUgc2VydmVyIHBhcnQgb2YgdGhlIHNzbCBkZW1vLgogKgogKiBAYXV0aG9yIE5pY29sYXMg Tm9mZmtlCiAqLwoKcHVibGljIGNsYXNzIFNlcnZlcgogICAgZXh0ZW5kcyBTU0xEZW1vUE9BCnsK ICAgIC8qKgogICAgICogVGhpcyBtZXRob2QgaXMgZnJvbSB0aGUgSURMLS1pbnRlcmZhY2UuIEl0 IHByaW50cyBvdXQgdGhlCiAgICAgKiByZWNlaXZlZCBjbGllbnQgY2VydCAoaWYgYXZhaWxhYmxl KS4KICAgICAqLwogICAgcHVibGljIHZvaWQgcHJpbnRDZXJ0KCkKICAgIHsKICAgICAgICBTeXN0 ZW0ub3V0LnByaW50bG4oIltTZXJ2ZXJdIGludm9rZWQgcHJpbnRDZXJ0KCkiKTsKICAgIH0KCgog ICAgcHVibGljIHN0YXRpYyB2b2lkIG1haW4oIFN0cmluZ1tdIGFyZ3MgKSB0aHJvd3MgRXhjZXB0 aW9uCiAgICB7CiAgICAgICAgaWYoIGFyZ3MubGVuZ3RoICE9IDEgJiYgYXJncy5sZW5ndGggIT0g MikKICAgICAgICB7CiAgICAgICAgICAgIFN5c3RlbS5vdXQucHJpbnRsbiggIlVzYWdlOiBqYXZh IGRlbW8uc3NsLlNlcnZlciA8aW9yX2ZpbGU+IDxraWxsZmlsZT4iICk7CiAgICAgICAgICAgIFN5 c3RlbS5leGl0KCAtMSApOwogICAgICAgIH0KCQkKCQlTeXN0ZW0uc2V0UHJvcGVydHkoIk9BU1NM UG9ydCIsIjc3NzciKTsgLy8gV0UgV0FOVCBBTEwgU0VSVkVSUyBUTyBUQUtFIFRIRSBTQU1FIFBP UlQKCiAgICAgICAgT1JCIG9yYiA9IE9SQi5pbml0KCBhcmdzLCBudWxsICk7CgoJCVBPQSBwb2Eg PSBudWxsOwoJCXRyeSB7CgkJU3lzdGVtLm91dC5wcmludGxuKCJcblxuRmlyc3QgdHJ5Li4uXG5c biIpOwogICAgICAgIHBvYSA9IChQT0EpCiAgICAgICAgb3JiLnJlc29sdmVfaW5pdGlhbF9yZWZl cmVuY2VzKCAiUm9vdFBPQSIgKTsKCQl9IGNhdGNoIChUaHJvd2FibGUgdCkgewoJCQlTeXN0ZW0u b3V0LnByaW50bG4oIlxuXG5mYWlsZWQuLi4gdHJ5IGFnYWluXG5cbiIpOwoJCQkvLyBGT1JHRVQg VEhFIEVYQ0VQVElPTiBBTkQgVFJZIEFHQUlOCgkJCXBvYSA9IChQT0EpCgkJCW9yYi5yZXNvbHZl X2luaXRpYWxfcmVmZXJlbmNlcyggIlJvb3RQT0EiICk7CgkJCS8vIE5PVyBXRSBET04nVCBHRVQg QU4gRVhDRVBUSU9OISBUSEVSRSBXQVMgTk8gVFJZIFRPIEdFVCBUSEUgUE9SVCEKCQkJLy8gTk9X IFdFIEhBVkUgQSBQT0EgQlVUIElUIElTIE5PVCBVU0FCTEUKCQl9CgkJU3lzdGVtLm91dC5wcmlu dGxuKCJcblxuc3VjY2VlZGVkLi4uXG5cbiIpOwoJCQogICAgICAgIHBvYS50aGVfUE9BTWFuYWdl cigpLmFjdGl2YXRlKCk7CgogICAgICAgIG9yZy5vbWcuQ09SQkEuT2JqZWN0IGRlbW8gPSBwb2Eu c2VydmFudF90b19yZWZlcmVuY2UoIG5ldyBTZXJ2ZXIoKSk7CgoJCVN5c3RlbS5vdXQucHJpbnRs bigiXG5cbk5vdyB3YWl0aW5nLi4uXG5cbiIpOwoJCVRocmVhZC5zbGVlcCgxMDAwMCk7IC8vIEpV U1QgVE8gTEVUIFRIRSBTWVNURU0gV0FJVCBGT1IgVVMgVE8gU1RBUlQgVEhFIFNFQ09ORCBTRVJW RVIKCQkKICAgICAgICBQcmludFdyaXRlciBwdyA9IG5ldyBQcmludFdyaXRlciggbmV3IEZpbGVX cml0ZXIoIGFyZ3NbIDAgXSApKTsKCiAgICAgICAgLy8gcHJpbnQgc3RyaW5naWZpZWQgb2JqZWN0 IHJlZmVyZW5jZSB0byBmaWxlCiAgICAgICAgcHcucHJpbnRsbiggb3JiLm9iamVjdF90b19zdHJp bmcoIGRlbW8gKSk7CgogICAgICAgIHB3LmZsdXNoKCk7CiAgICAgICAgcHcuY2xvc2UoKTsKCiAg ICAgICAgaWYgKGFyZ3MubGVuZ3RoID09IDIpCiAgICAgICAgewogICAgICAgICAgICBGaWxlIGtp bGxGaWxlID0gbmV3IEZpbGUoYXJnc1sxXSk7CiAgICAgICAgICAgIHdoaWxlKCFraWxsRmlsZS5l eGlzdHMoKSkKICAgICAgICAgICAgewogICAgICAgICAgICAgICAgVGhyZWFkLnNsZWVwKDEwMDAp OwogICAgICAgICAgICB9CiAgICAgICAgICAgIG9yYi5zaHV0ZG93bih0cnVlKTsKICAgICAgICB9 CiAgICAgICAgZWxzZQogICAgICAgIHsKICAgICAgICAgICAgb3JiLnJ1bigpOwogICAgICAgIH0K ICAgIH0KfSAvLyBTZXJ2ZXIK