Hi Joe, That ClosedChannelException appears to support your conclusion that requests are being issued by the browser but blocking forever in the server. That exception is saying that there is an http connection open between browser and server at shutdown time (or at least the server thinks there is).
Looks to me like somewhere within Trinidad's AJAX/PPR code on the server a request thread is blocking waiting for a lock that never comes free... If you send a "kill -3" signal to a JVM a list of all threads (with stacktrace) is generated. It might be interesting to do that, and see where the threads currently are. Any sitting inside trinidad or jsf lib code when there *should* be no pending requests would be useful data.. Regards, Simon Joe Rossi schrieb: > Sorry for being unclear. I'm pretty sure the issue is nothing to do > with Tomahawk - I simply tried a later version of Tomahawk "just in > case". The issue appears as soon as I plug in a version of Trinidad > after 1.2.2 so I'm pretty sure it's something to do with Trinidad. > > One other data point - it looks like my jetty server is throwing the > following exception on shutdown when the error occurs (i.e. the > exception does not occur with Trinidad 1.2.2): > > java.nio.channels.ClosedChannelException > at sun.nio.ch.ServerSocketChannelImpl.accept(Unknown Source) > at > org.mortbay.jetty.nio.SelectChannelConnector$1.acceptChannel(SelectChannelConnector.java:75) > at > org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:485) > at > org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:168) > at > org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124) > at > org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:514) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) > > thanks > Joe. > > > > ------------------------------------------------------------------------ > CC: [email protected]; [EMAIL PROTECTED] > From: [EMAIL PROTECTED] > To: [email protected] > Subject: Re: [TRINIDAD] Dialog Framework behaving strange since > Trinidad 1.2.3 > Date: Wed, 21 May 2008 06:32:30 -0600 > > So let me get this strainght? You are seeing this issue with > tomahawk as well? That leads me to believe that it's not a > Trinidad issue. > > On May 21, 2008, at 4:34 AM, Joe Rossi <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > We're using MyFaces 1.2.2 - I've tried 1.2.3 and there's no > difference. We're also using Tomahawk 1.1.5 and Facelets > 1.1.13. I've tried Tomahawk 1.1.6 and Facelets 1.1.14 and, > again, no difference. > > thanks > Joe. > > > > > > ------------------------------------------------------------------------ > CC: [email protected] > <mailto:[email protected]>; [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > To: [email protected] <mailto:[email protected]> > Subject: Re: [TRINIDAD] Dialog Framework behaving strange > since Trinidad 1.2.3 > Date: Wed, 21 May 2008 00:06:03 -0600 > > Sounds strangely like a server issue. What JSF version > are you using? > > On May 20, 2008, at 11:14 PM, Joe Rossi > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > Unfortunately it is still a problem in 1.2.7. Any > clues as to what's happening or how to track down the > problem? > > many thanks > Joe > > > > > ------------------------------------------------------------------------ > > Date: Tue, 20 May 2008 16:47:13 -0600 > > From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > To: [email protected] > <mailto:[email protected]> > > CC: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > Subject: Re: [TRINIDAD] Dialog Framework behaving > strange since Trinidad 1.2.3 > > > > Joe, is this a problem in Trinidad 1.2.7? > > > > Scott > > > > Joe Rossi wrote: > > > Harald - I'm not sure whether you solved your > problem, but I've > > > finally come back to check this out again. Here's > what I've found over > > > the last couple of days with my particular test case: > > > > > > Just as a reminder the scenario I have is an > intermittent problem > > > after a lightweight dialog has been launched and > closed *and*if the > > > closure of the dialog results in a PPR refresh to > a component on the > > > underlying page. Some additional observations: > > > > > > - After the dialog returns I cannot click on any > further command links > > > for exactly 8 seconds > > > - The expected PPR refresh does not occur > > > - Using Firefox Tamper Data plugin I can see that > there are POSTs to > > > the server which do not complete. Tamper Data > reports them as > > > remaining with status 'Pending' > > > - After debugging trinidad's javascript I notice > that all the above > > > problems occur because the function > _pprStopBlocking() is not being > > > called in the same way as in 1.2.2. In 1.2.2 PPR > triggers an ajax call > > > to the server, the ajax call completes fine, the > javascript function > > > TrXMLRequest.__onReadyStateChange reaches the > ready state and at that > > > point the ppr response is correctly consumed on > the client and > > > _pprStopBlocking() is called. On 1.2.3 the > javascript function > > > TrXMLRequest.__onReadyStateChange never reaches > the ready state and so > > > the downstream actions of consuming the ppr > response and calling > > > _pprStopBlocking() are not correctly done. > > > - Note that in the error condition, > _pprStopBlocking is eventually > > > called by a separate javascript thread which is > kicked off as part of > > > the initial ppr processing in _pprStartBlocking(). > The timeout value > > > on this thread is exactly 8 seconds which explains > the first symptom > > > described above. > > > > > > So, it appears that the underlying cause is the > ppr request not > > > completing. > > > > > > I've diffed the 1.2.2 and 1.2.3 source code and > there's nothing which > > > looks like a directly obvious cause. Can anyone > help, or at least give > > > some pointers on how to work out why the ppr > request is not completing? > > > > > > thanks > > > Joe. > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > Date: Mon, 18 Feb 2008 13:02:57 +0100 > > > From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > CC: [email protected] > <mailto:[email protected]> > > > Subject: Re: [TRINIDAD] Dialog Framework behaving > strange since > > > Trinidad 1.2.3 > > > > > > Hi Joe, > > > > > > unfortunately I didn't get any response from the > list, although I > > > tried it two times. > > > I opened a bug report in jira but did not get any > comment on that. > > > Maybe I find some time to do a diff between 1.2.2 > and 1.2.3 to > > > find out what changes have been made that could > cause this behaviour. > > > > > > Joe Rossi schrieb: > > > > > > Harald (anyone) - did you work out what's > happening here? I > > > think I'm hitting something similar. > > > > > > We've been successfully using 1.2.2 for a few > months, but > > > wanted to move up to 1.2.5 in order to consume a > couple of bug > > > fixes that we need. However, a number of our > Selenium UI tests > > > failed because of clicks on command links not > responding after > > > dialogs had been displayed. > > > > > > I've spent a bit of time trying to work out what's > happening > > > (not very successfully). The only observations I > have made are: > > > > > > - The problem is intermittent but it only seems to > occur after > > > a lightweight dialog has been launched and closed > *and*if the > > > closure of the dialog results in a PPR refresh to > a component > > > on the underlying page > > > - With firebug I can observe a javascript error > occurring when > > > the problem reproduces: _callChained is not defined > > > DebugCommon1_2_5.js line 8408. Also, firebug seems > to indicate > > > that there is a POST to the server which has no > response > > > (though admittedly I'm not sure whether this is > correct or > > > relevant?) > > > - I have tested Firefox and IE - it only seems to > reproduce in > > > Firefox > > > - I've tested 1.2.3 up to 1.2.5 and the problem > reproduces in > > > all these versions (other issues are currently > preventing > > > testing of 1.2.6). Hence, it does seem like > something that was > > > introduced in 1.2.3. > > > > > > Any clues anyone? > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > Messenger's gone Mobile! Get it now! > > > > <http://clk.atdmt.com/UKM/go/msnnkmgl0010000001ukm/direct/01/> > > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------ > Get fish-slapping on Messenger! > > > ------------------------------------------------------------------------ > Messenger's gone Mobile! Get it now! > <http://clk.atdmt.com/UKM/go/msnnkmgl0010000001ukm/direct/01/>
