cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@googlemail.com>
Subject Re: A mysteriously deadlock of CXF OnewayProcessorInterceptor
Date Wed, 24 Aug 2011 11:57:59 GMT
2011/8/22 Daniel Kulp <dkulp@apache.org>:
> On Monday, August 22, 2011 10:26:36 AM Aki Yoshida wrote:
>> Hi Dan,
>> I was confused about the original intention of this wait(20) code. I
>> didn't understand why it was important to wait 20msec and let the
>> executor thread start instead of not waiting. The comment in the code
>> says the intention is to try to keep the ordering of the messages from
>> the client. But I had an impression that this code would not be
>> helping in this matter. So I initially thought that we could just get
>> rid of this wait to avoid the reported blocking situation. If keeping
>> the ordering is important, shouldn't we introduce this mechanism
>> optionally instead of trying to put this in there implicitly?
>
> Basically, if a client proxy sends a one-way request, and then immediately
> follows it up with a two-way request, we were seeing (even in our unit tests)
> where, in most situations, the two-way would get dispatched into the impl
> before the one-way.   While perfectly valid, this was kind of confusing to
> users.  Thus we added a very short wait there to make sure the runnable has
> been started on a thread which usually allows it to proceed something closer
> to in order.  If the queue is full or all threads are busy, the wait will
> timeout and the one-way will get there eventually, but in most cases this
> works fairly well.
>
> Basically, it's a "best effort, but no guarantees".  If they need to make sure
> it's there in order, they would need two ways or use WS-RM.

Thanks for the explanation. I am sorry to hear that some people are
not happy when a oneway call gets passed by a later invoked req-resp
call. I personally think we could get rid of this wait(20) to make a
oneway call more efficient.

If someone wants to keep the invocation ordering of oneway and
req-resp calls from a single client and while keeping it as it is and
simple, could he also use the USE_ORIGINAL_THREAD option of this
interceptor or was this option intended to be a workaround for the
ordering problem?

thanks.

regards, aki
>
> Dan
>
>
>
>>
>> Thanks.
>> regards, aki
>>
>> 2011/8/19 Daniel Kulp <dkulp@apache.org>:
>> > On Friday, August 19, 2011 2:32:03 PM xuhb wrote:
>> >> Maybe it is becuase before chain.wait() return, the sync of chain
>> >>  will be re-locked, so it will block untill chain.resume() finished;
>> >
>> > Thanks for the test case.   There definitely is an issue here.   At this
>> > point, the thread has already synchronized on the chain (due to the
>> > doIntercept method on the PhaseInterceptorChain being synchronized).
>> >  Thus, some of the synchronized blocks in there don't look correct.
>> > If I create a simple:
>> >
>> > final Object lock = new Object();
>> >
>> > in there, then that problem goes away.
>> >
>> > That said, I hit another couple of issues with your testcase as well
>> > that I'm looking into.  :-(
>> >
>> > Dan
>> >
>> >> ----- Original Message -----
>> >> From: "xuhb" <xuhb@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" <xuhb@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(WorkQueueManag
>> >> >> er.cla ss)
>> >
>> >  .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:
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org
>> > http://dankulp.com/blog
>> > Talend - http://www.talend.com
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>

Mime
View raw message