I think I may have stumbled onto the cause. It appears that it's down to the version of Firefox on the browser. Using 2.0.0.12 I experience the problem, but with 2.0.0.13 or 2.0.0.14 it seems to work fine.
The firefox release notes mention some changes in 2.0.0.13 which fixed javascript memory corruptions so I wonder whether Trinidad 1.2.3 introduced javascript changes which triggered the problem in Firefox 2.0.0.12 ?? Anyway, I think we're now ok to proceed with Trinidad 1.2.7. I've updated JIRA issue TRINIDAD-875 (which I think is this same issue) to describe the potential cause. J. > From: [EMAIL PROTECTED] > To: [email protected] > Subject: Re: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3 > Date: Wed, 21 May 2008 07:19:33 -0600 > CC: [email protected] > > A place you might also want to start debugging is in the Trinidad > Filter. The trinidad filter handles the "return from dialog" logic. > Around the 1.2.3 - 1.2.4 timeframe I moved most of the filter logic to > the Trinidad Configurator system. It's possible somthing in your app > is reacting negatively to that change. > > AMAF, I thing the only real logic in the filter is there to manually > run the configurators and handle dialogs. > > On May 21, 2008, at 7:04 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED] > > wrote: > > > 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/> > > _________________________________________________________________ http://clk.atdmt.com/UKM/go/msnnkmgl0010000009ukm/direct/01/
