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. Dan > > Thanks. > regards, aki > > 2011/8/19 Daniel Kulp <[email protected]>: > > 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" <[email protected]> > >> To: <[email protected]> > >> 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" <[email protected]> > >> > To: <[email protected]> > >> > 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 > > [email protected] > > http://dankulp.com/blog > > Talend - http://www.talend.com -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
