Created attachment 466 [details] demo that demonstrate the suspicious behaviour I stumbled in another unexpected behaviour while isolating the problem reported in Bug 1011 . Instead of making 2 or more calls inside the send_request interception point, just make 1 more call that is also going to receive an exception and resolve it through a forward_request. In this case I noticed that there is an extra send_request call and the previous one apparently is not completed (does not arrives in server side). Let me try to make myself clear with an example: [client] [server] ---- calls A() ----> <---- NO_PERMISSION (op = A) ---- receive_exception: do forward_request( op = A ) ---- calls A() ----> ---- send_request( op = A ) ----> ---- calls B() ----> <---- NO_PERMISSION (op = B) ---- receive_exception: do forward_request( op = B ) ---- calls B() ----> <---- successful reply (op = B) ---- --- complete the send_request( op = A) ---> // "apparently this completed send_request does not arrives to the server" // why ??? // an extra call is sent. Why?? ---- calls A() ----> <---- successful reply (op = A) ----
Through the provided demo this can we noticed by the following prints: send_request: canIComeIn canIComeIn -> secret = Any wrong secret receive_exception: canIComeIn send_request: canIComeIn send_request: itsMe itsMe -> secret = Any wrong secret receive_exception: itsMe send_request: itsMe itsMe -> secret = This is truly the real one! canIComeIn -> secret = This is truly the real one! // this print below is the extra call send_request: canIComeIn canIComeIn -> secret = This is truly the real one!
Hugo - would it be possible to verify current git head to ensure that it is fixed there?
Will test it and get back to you as soon as possible.
I've already informed this on the jacorb-dev list, but just for the record i'll duplicate the info: this bug was not fixed by the current git head. I submitted a pull request to reproduce it.
Here's the deal with the extra call. In the regression test ExtraCall case, the itsMe operation gets a NO_PERMISSION which triggers the forward. This causes the Delegate to rebind, closing the existing connection and making a new one. The itsMe call completes allowing the original canIComeIn request to proceed. At this point, the Delegate throws a RemarshalException from within _invoke_internal because the connection it expected to use no longer exists. So I will adjust the regression test to use all three scenarios but I think this issue is resolved.
with commit b1c67af0d4efb973e76aa2dcbce593b4eecef3d9 the regression test fits the behavior of the Delegate which is correct given the connection manager's closure of unbound connections. It may be possible to continue caching otherwise unbound connections for some time but that will involve reworking the giop connection manager.