Read only archive ; use https://github.com/JacORB/JacORB/issues for new issues

Bug 1012

Summary:	Missed send_request while completing a forward request
Product:	JacORB	Reporter:	Hugo Roenick <hroenick>
Component:	ORB	Assignee:	Mailinglist to track bugs <jacorb-bugs>
Status:	RESOLVED FIXED
Severity:	major	CC:	hroenick, jacorb, mesnierp, vgpinheiro
Priority:	P5
Version:	3.6.1
Hardware:	PC
OS:	All
Attachments:	demo that demonstrate the suspicious behaviour

Description Hugo Roenick 2015-07-08 13:56:25 UTC

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) ----

Comment 1 Hugo Roenick 2015-07-08 13:56:46 UTC

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!

Comment 2 Nick Cross 2015-07-31 09:24:28 UTC

Hugo - would it be possible to verify current git head to ensure that it is fixed there?

Comment 3 Hugo Roenick 2015-08-03 05:32:48 UTC

Will test it and get back to you as soon as possible.

Comment 4 Vinicius Pinheiro 2015-08-19 14:48:05 UTC

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.

Comment 5 Phil Mesnier 2015-10-01 17:18:30 UTC

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.

Comment 6 Phil Mesnier 2015-10-22 04:41:22 UTC

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.