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.
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.
Can you provide standalone runnable test case?
Created attachment 459 [details] IDL file
Created attachment 460 [details] Client Interceptor implementation
Created attachment 461 [details] The main class
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
Thanks for that extra detail! Does the problem exist with 3.3 and 3.4 ?
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?
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.
Sent submitter a test via email.
Fixed by SHA 098124afd1bbc9befba545897d3613ceba927c13