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

Bug 1009

Summary:	Client Interceptor does not handle properly second exception in a raw
Product:	JacORB	Reporter:	Serguei Kolos <Serguei.Kolos>
Component:	ORB	Assignee:	Mailinglist to track bugs <jacorb-bugs>
Status:	RESOLVED FIXED
Severity:	blocker	CC:	jacorb
Priority:	P5
Version:	3.5
Hardware:	PC
OS:	Linux
Attachments:	IDL file Client Interceptor implementation The main class Log of runs

Description Serguei Kolos 2015-05-08 12:09:32 UTC

I have the ClientRequestInterceptor implementation which implements the receive_exception function to handle restarts of remote servers. If the interceptor gets an exception it tries to find an updated reference to the remote object and throws ForwardRequest exception with that reference. The result of this procedure is different depending on the validity of the new reference:

1. If the new reference is valid (i.e. represents an existing CORBA object) everything goes fine.

2. If the new reference is invalid, (i.e. the corresponding remote server is not running) the MyClientRequestInterceptor.receive_exception function is immediately invoked again. My implementation detects that this is already a second exception received for the updated reference so it decides to give up and does a simple return. And here is the problem - after that the same MyClientRequestInterceptor.receive_exception is immediately invoked again and the original exception is never propagated to the user code. At this point my interceptor enters into an infinite recursion as there is no way out - whenever it returns it's immediately invoked again.

I need to find a solution urgently as this blocks our production system from functioning properly. If anyone could give me a hint on how to fix it I can rebuild the JacORB locally and give t a try. Any help is greatly appreciated.

Comment 1 Serguei Kolos 2015-05-08 12:15:12 UTC

I should have said that my code worked fine with the version 3.2 which we had been using for a long time. The problem appeared when we switched to the version 3.5. I have tried the version 3.6 and it has the same problem as 3.5.

Comment 2 Nick Cross 2015-05-08 12:47:12 UTC

Can you provide standalone runnable test case?

Comment 3 Serguei Kolos 2015-05-09 06:16:47 UTC

Created attachment 459 [details]
IDL file

Comment 4 Serguei Kolos 2015-05-09 06:17:15 UTC

Created attachment 460 [details]
Client Interceptor implementation

Comment 5 Serguei Kolos 2015-05-09 06:17:47 UTC

Created attachment 461 [details]
The main class

Comment 6 Serguei Kolos 2015-05-09 06:20:30 UTC

Here is a simple test case which demonstrates the problem. Actually the problem is slightly different with respect to what I have described originally. In my real application exception handling is quite complicated so I didn't recognized the actual behavior, but in the essence the problem is that the actual interceptors algorithm result in the following sequence of events:

1. The ORB tries to connect to remote server using the original object reference and fails
2. receive_exception is invoked for the first time and throws ForwardRequest with the new object reference
3. The ORB tries to connect to remote server using the new object reference and fails again
4. receive_exception is invoked for the second time and just exits
    
   At this moment I would expect the TRANSIENT exception appearing in the user code, but...

5. The ORB tries to connect to remote server using again the ORIGINAL object reference and fails again
6. receive_exception is invoked for the THRID time and simply returns
7. Only now the TRANSIENT exception appears in the user code



Here is the output produced by the attached test application
> java test.Test
WARNING Warning - unknown codeset (ASCII) - defaulting to ISO-8859-1
WARNING Warning - unknown codeset (ASCII) - defaulting to ISO-8859-1
INFO Initialising ORB with ID: 
INFO InterceptorManager started with 0 Server Interceptors, 1 Client Interceptors and 1 IOR Interceptors
Invoking test.i.f function 
INFO ClientConnectionManager: created new ClientGIOPConnection to 127.0.1.1:50525 (147c4ee)
INFO Negotiated char codeset of ISO8859_1 and wchar of UTF16
INFO Retrying to connect to 127.0.1.1:50525
INFO Retrying to connect to 127.0.1.1:50525
INFO Retrying to connect to 127.0.1.1:50525
INFO Retrying to connect to 127.0.1.1:50525
INFO Retrying to connect to 127.0.1.1:50525
receive_exception IDL:omg.org/CORBA/TRANSIENT:1.0
receive_exception IDL:omg.org/CORBA/TRANSIENT:1.0 count = 0 throw ForwardRequest
INFO ClientConnectionManager: created new ClientGIOPConnection to 127.0.1.1:34851 (1533528)
INFO Negotiated char codeset of ISO8859_1 and wchar of UTF16
INFO Retrying to connect to 127.0.1.1:34851
INFO Retrying to connect to 127.0.1.1:34851
INFO Retrying to connect to 127.0.1.1:34851
INFO Retrying to connect to 127.0.1.1:34851
INFO Retrying to connect to 127.0.1.1:34851
receive_exception IDL:omg.org/CORBA/TRANSIENT:1.0
receive_exception IDL:omg.org/CORBA/TRANSIENT:1.0 count = 1 just return
INFO ClientConnectionManager: created new ClientGIOPConnection to 127.0.1.1:50525 (14bdf68)
INFO Negotiated char codeset of ISO8859_1 and wchar of UTF16
INFO Retrying to connect to 127.0.1.1:50525
INFO Retrying to connect to 127.0.1.1:50525
INFO Retrying to connect to 127.0.1.1:50525
INFO Retrying to connect to 127.0.1.1:50525
INFO Retrying to connect to 127.0.1.1:50525
receive_exception IDL:omg.org/CORBA/TRANSIENT:1.0
receive_exception IDL:omg.org/CORBA/TRANSIENT:1.0 count = 1 just return
Got Exception: org.omg.CORBA.TRANSIENT: Retries exceeded, couldn't reconnect to 127.0.1.1:50525  vmcid: 0x0  minor code: 0  completed: No

Comment 7 Nick Cross 2015-05-10 14:41:26 UTC

Thanks for that extra detail!

Does the problem exist with 3.3 and 3.4 ?

Comment 8 Nick Cross 2015-05-11 07:17:50 UTC

Created attachment 462 [details]
Log of runs

Could I clarify something - I have run your test with both JacORB 3.2 and current HEAD (and an old 2.3.1) and am getting similar results. I have attached a log file.

Could you clarify the difference between 3.2 and later versions?

Comment 9 Serguei Kolos 2015-05-11 07:24:41 UTC

All previous versions of the JacORB (3.2, 3.3, 3.4) behave in the same way. Actually I was wrong saying that 3.2 behaved differently - that was a change in our own code which changed the behavior of our application and made me thinking that something has changed in the jacORB. I'm sorry for the confusion.

But in the end my question is whether this behavior - making another connection attempt on the original reference when the forwarded one gives TRANSIENT exception - is standard compliant or that is a bug which should be fixed.

Comment 10 Nick Cross 2015-05-15 10:28:45 UTC

Sent submitter a test via email.

Comment 11 Nick Cross 2015-05-19 13:15:02 UTC

Fixed by SHA 098124afd1bbc9befba545897d3613ceba927c13