Yes it's very possible something happened client side. :) Whew, you
were beginning to worry me. This has been working for us and I was not
looking forward to diagnosing the issue. :)
Joe Rossi wrote:
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
<https://issues.apache.org/jira/browse/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/>
> >
------------------------------------------------------------------------
Get fish-slapping on Messenger! Play Now
<http://clk.atdmt.com/UKM/go/msnnkmgl0010000008ukm/direct/01/>
