Hi,
I think you are right. Although the http 202 response is written back
to the response by the calling thread before this thread going into
the block and therefore the client should not be blocked as it can
read the http 202 response, the calling thread itself may get blocked
(not being able to come out of the wait until the other thread
finishes processing the rest of the chain). I am not sure why this 20
msec wait code is added there. The comment in the code says
//wait a few milliseconds for the background
thread to start processing
//Mostly just to make an attempt at keeping
the ordering of the
//messages coming in from a client. Not
guaranteed though.
maybe, we should try to resolve this elsewhere and not use wait(20) here.
regards, aki
2011/8/19 xuhb <x...@tongtech.com>:
> Maybe it is becuase before chain.wait() return, the sync of chain will be
> re-locked, so it will block untill chain.resume() finished;
>
> ----- Original Message -----
> From: "xuhb" <x...@tongtech.com>
> To: <users@cxf.apache.org>
> Sent: Friday, August 19, 2011 1:39 PM
> Subject: Re: A mysteriously deadlock of CXF OnewayProcessorInterceptor
>
>
>> Sorry, I foget post the issue link:
>>
>> https://issues.apache.org/jira/browse/CXF-3750
>>
>> ----- Original Message -----
>> From: "xuhb" <x...@tongtech.com>
>> To: <users@cxf.apache.org>
>> Sent: Friday, August 19, 2011 1:34 PM
>> Subject: A mysteriously deadlock of CXF OnewayProcessorInterceptor
>>
>>
>>> Hi:
>>> Recently when I am checking/testing CXF , there is a mysteriously
>>> deadlock of CXF Oneway Process; Normally CXF engine will invoke the one
>>> way bussiness logical asynchronized ,, so the servlet handle will finished
>>> and return back to servlet engine immediately;
>>>
>>> But sometime, I noticed that the servlet handle(JettyHTTPHandler) at
>>> server side doesn't return back to servlet engine(Jetty) immediately , it
>>> will waiting until the asynchrouse business logical finished;
>>> After dig source of CXF, I find it 's relate to
>>> OnewayProcessorInterceptor;But until now I can only show when will the
>>> deadlock occurs, but I still can not explain why;
>>>
>>> Following is details:
>>> OnewayProcessInterceptor.handleMessage{
>>> synchronized (chain) {
>>> message.getExchange().get(Bus.class).getExtension(WorkQueueManager.class)
>>> .getAutomaticWorkQueue().execute(new Runnable() {
>>> public void run() {
>>> synchronized (chain) {
>>> System.out.println("--notify all");
>>> chain.notifyAll();
>>> }
>>>
>>> chain.resume(); //if chain.resume is called before chain.wait finished
>>> , the dead lock will occurs; It seems as chain.resume is synchronized, so
>>> it will relock on chain object, so the chain.wait() will deadlocked (... I
>>> feel confused for this, because jdk doesn't say so...) ;After chain.resume
>>> finished, locking on chain is released, deadlock of chain.wait() is also
>>> released; but I don't think this is problem of CXF , maybe it's jdk's
>>> problem ?? I feels confused;
>>> }
>>> });
>>> System.out.println("--wait begin");
>>> chain.wait(20);
>>> System.out.println("--wait end");
>>> }
>>> }
>>> syncrhonized PhaseInterceptorChain.resume(){
>>> System.out.println("--api chain resume");
>>> ...
>>> }
>>>
>>> if the execute sequence as following, every thing is ok. there is no dead
>>> lock;
>>> chain.wait enter
>>> chian.notify invoked
>>> chain.wait return;
>>> chain.resume(); //resume also synchronzed on chain object;
>>>
>>> if the execute sequence as following , dead lock will occurs:
>>> chain.wait enter
>>> chain.notify
>>> chain.resume// ..now waiting on chain will blocked until chain.resume
>>> finished(release sync on chain)
>>> chain.wait return;
>>>
>>> following dump on console indicate the above sequence:
>>>
>>> No DeadLock dump :
>>> --wait begin
>>> --notify all
>>> --wait end
>>> --api chain resume
>>> product service begin Fri Aug 19 12:10:28 CST 2011 //a lone time(10
>>> seconds) one way business logical begin
>>> product service end Fri Aug 19 12:10:38 CST 2011 .//a lone time(10
>>> seconds) one way business logical end;
>>>
>>>
>>> DeadLock Dump:
>>> --wait begin
>>> --notify all
>>> --api chain resume
>>> product service begin Fri Aug 19 12:10:40 CST 2011
>>> product service end Fri Aug 19 12:10:50 CST 2011
>>> --wait end
>>>
>>>
>>> Until now I am not sure if problem is CXF's or JDK's, or something which I
>>> don't know cause such a deadlock;
>>> I also wrote a simple program to simulate the execute sequnce which
>>> causeddead lock in CXF, but the simple program never dead lock;
>>>
>>> I tried CXF 2.3.3 version && Jetty transport && (JDK1.5_22 || JDK 1.6_17)
>>> && Windows XP system;
>>>
>>> I also post this question as a JIRA issue:
>>>
