We are using relative timeouts with interceptors. On the logs timeouts seem to be reached but on reality they don't. Analysis of the problem: We are using RELATIVE_REQ_TIMEOUT_POLICY_TYPE policy by code (Orb.create_policy() method). Within interceptors we call another corba services. For instance we call the jacorb naming service, calling the resolve method on _NamingContextStub (JacORB IDL compiler V 3.2). This has the effect to call the Delegate.request() method with key "interceptor_call" on the thread context and to set clearCurrentContext attribute to false. A main error is that, clearCurrentContext attribute is never set to true later (and clearCurrentContext should be an attribute of the current thread), and as Delegate is a singleton class, some independant calls of request method by other class in another threads should not clear the thread context on invoke_internal methods (and time end resquet infomations). Then on new call of request method, the request end time still exists on the thread context and is not replaced by a new one computed. So with ellapsed time, because these request end times are never removed or replaced, finally we get allways exceptions on line 2209.
Can you provide a standalone compilable test case?
Created attachment 406 [details] test case Problem rises when we use same Delegate class after interceptor call and we do some calls on the same thread.
Created attachment 407 [details] test case A compilation error was present on last one attachment.
Created attachment 409 [details] patch attachment This patch is a proposal correction for 940. I submited this correction within zecorsaire/JacORB branch too.
Have been unable to reliably reproduce a problem with the attached test case. Please elaborate what it is supposed to show.
Downgrading priority until submitter can clarify the problem.
Applied a possible fix in SHA 842e2eaf6fb25c446063acce894b2c01f50f1945