You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Joe Rossi <je...@hotmail.co.uk> on 2008/05/20 22:06:09 UTC
RE: [TRINIDAD] Dialog Framework behaving strange since Trinidad
1.2.3
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: harald@elkfilm.de
To: jeross@hotmail.co.uk
CC: users@myfaces.apache.org
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?
_________________________________________________________________
http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/
Re: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3
Posted by Scott O'Bryan <da...@gmail.com>.
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: darkarena@gmail.com
> > To: users@myfaces.apache.org
> > Subject: Re: [TRINIDAD] Dialog Framework behaving strange since
> Trinidad 1.2.3
> > Date: Wed, 21 May 2008 07:19:33 -0600
> > CC: users@myfaces.apache.org
> >
> > 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, "simon.kitching@chello.at"
> <simon.kitching@chello.at
> > > 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: users@myfaces.apache.org; harald@elkfilm.de
> > >> From: darkarena@gmail.com
> > >> To: users@myfaces.apache.org
> > >> 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 <jeross@hotmail.co.uk
> > >> <ma...@hotmail.co.uk>> 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: users@myfaces.apache.org
> > >> <ma...@myfaces.apache.org>; harald@elkfilm.de
> > >> <ma...@elkfilm.de>
> > >> From: darkarena@gmail.com <ma...@gmail.com>
> > >> To: users@myfaces.apache.org <mailto:users@myfaces.apache.org
> > >> >
> > >> 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
> > >> <jeross@hotmail.co.uk <ma...@hotmail.co.uk>>
> > >> 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: darkarena@gmail.com <ma...@gmail.com>
> > >>> To: users@myfaces.apache.org
> > >> <ma...@myfaces.apache.org>
> > >>> CC: harald@elkfilm.de <ma...@elkfilm.de>
> > >>> 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: harald@elkfilm.de <ma...@elkfilm.de>
> > >>>> To: jeross@hotmail.co.uk <ma...@hotmail.co.uk>
> > >>>> CC: users@myfaces.apache.org
> > >> <ma...@myfaces.apache.org>
> > >>>> 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/>
RE: [TRINIDAD] Dialog Framework behaving strange since Trinidad
1.2.3
Posted by Joe Rossi <je...@hotmail.co.uk>.
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: darkarena@gmail.com
> To: users@myfaces.apache.org
> Subject: Re: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3
> Date: Wed, 21 May 2008 07:19:33 -0600
> CC: users@myfaces.apache.org
>
> 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, "simon.kitching@chello.at" <simon.kitching@chello.at
> > 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: users@myfaces.apache.org; harald@elkfilm.de
> >> From: darkarena@gmail.com
> >> To: users@myfaces.apache.org
> >> 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 <jeross@hotmail.co.uk
> >> <ma...@hotmail.co.uk>> 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: users@myfaces.apache.org
> >> <ma...@myfaces.apache.org>; harald@elkfilm.de
> >> <ma...@elkfilm.de>
> >> From: darkarena@gmail.com <ma...@gmail.com>
> >> To: users@myfaces.apache.org <mailto:users@myfaces.apache.org
> >> >
> >> 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
> >> <jeross@hotmail.co.uk <ma...@hotmail.co.uk>>
> >> 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: darkarena@gmail.com <ma...@gmail.com>
> >>> To: users@myfaces.apache.org
> >> <ma...@myfaces.apache.org>
> >>> CC: harald@elkfilm.de <ma...@elkfilm.de>
> >>> 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: harald@elkfilm.de <ma...@elkfilm.de>
> >>>> To: jeross@hotmail.co.uk <ma...@hotmail.co.uk>
> >>>> CC: users@myfaces.apache.org
> >> <ma...@myfaces.apache.org>
> >>>> 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/
Re: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3
Posted by Scott O'Bryan <da...@gmail.com>.
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, "simon.kitching@chello.at" <simon.kitching@chello.at
> 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: users@myfaces.apache.org; harald@elkfilm.de
>> From: darkarena@gmail.com
>> To: users@myfaces.apache.org
>> 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 <jeross@hotmail.co.uk
>> <ma...@hotmail.co.uk>> 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: users@myfaces.apache.org
>> <ma...@myfaces.apache.org>; harald@elkfilm.de
>> <ma...@elkfilm.de>
>> From: darkarena@gmail.com <ma...@gmail.com>
>> To: users@myfaces.apache.org <mailto:users@myfaces.apache.org
>> >
>> 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
>> <jeross@hotmail.co.uk <ma...@hotmail.co.uk>>
>> 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: darkarena@gmail.com <ma...@gmail.com>
>>> To: users@myfaces.apache.org
>> <ma...@myfaces.apache.org>
>>> CC: harald@elkfilm.de <ma...@elkfilm.de>
>>> 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: harald@elkfilm.de <ma...@elkfilm.de>
>>>> To: jeross@hotmail.co.uk <ma...@hotmail.co.uk>
>>>> CC: users@myfaces.apache.org
>> <ma...@myfaces.apache.org>
>>>> 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/>
>
Re: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3
Posted by "simon.kitching@chello.at" <si...@chello.at>.
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: users@myfaces.apache.org; harald@elkfilm.de
> From: darkarena@gmail.com
> To: users@myfaces.apache.org
> 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 <jeross@hotmail.co.uk
> <ma...@hotmail.co.uk>> 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: users@myfaces.apache.org
> <ma...@myfaces.apache.org>; harald@elkfilm.de
> <ma...@elkfilm.de>
> From: darkarena@gmail.com <ma...@gmail.com>
> To: users@myfaces.apache.org <ma...@myfaces.apache.org>
> 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
> <jeross@hotmail.co.uk <ma...@hotmail.co.uk>> 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: darkarena@gmail.com <ma...@gmail.com>
> > To: users@myfaces.apache.org
> <ma...@myfaces.apache.org>
> > CC: harald@elkfilm.de <ma...@elkfilm.de>
> > 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: harald@elkfilm.de <ma...@elkfilm.de>
> > > To: jeross@hotmail.co.uk <ma...@hotmail.co.uk>
> > > CC: users@myfaces.apache.org
> <ma...@myfaces.apache.org>
> > > 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/>
RE: [TRINIDAD] Dialog Framework behaving strange since Trinidad
1.2.3
Posted by Joe Rossi <je...@hotmail.co.uk>.
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: users@myfaces.apache.org; harald@elkfilm.de
From: darkarena@gmail.com
To: users@myfaces.apache.org
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 <je...@hotmail.co.uk> 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: users@myfaces.apache.org; harald@elkfilm.de
From: darkarena@gmail.com
To: users@myfaces.apache.org
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 <je...@hotmail.co.uk> 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: darkarena@gmail.com
> To: users@myfaces.apache.org
> CC: harald@elkfilm.de
> 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: harald@elkfilm.de
> > To: jeross@hotmail.co.uk
> > CC: users@myfaces.apache.org
> > 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!
_________________________________________________________________
http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/
Re: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3
Posted by Scott O'Bryan <da...@gmail.com>.
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 <je...@hotmail.co.uk> 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: users@myfaces.apache.org; harald@elkfilm.de
> From: darkarena@gmail.com
> To: users@myfaces.apache.org
> 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 <je...@hotmail.co.uk> 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: darkarena@gmail.com
> > To: users@myfaces.apache.org
> > CC: harald@elkfilm.de
> > 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: harald@elkfilm.de
> > > To: jeross@hotmail.co.uk
> > > CC: users@myfaces.apache.org
> > > 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!
RE: [TRINIDAD] Dialog Framework behaving strange since Trinidad
1.2.3
Posted by Joe Rossi <je...@hotmail.co.uk>.
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: users@myfaces.apache.org; harald@elkfilm.de
From: darkarena@gmail.com
To: users@myfaces.apache.org
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 <je...@hotmail.co.uk> 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: darkarena@gmail.com
> To: users@myfaces.apache.org
> CC: harald@elkfilm.de
> 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: harald@elkfilm.de
> > To: jeross@hotmail.co.uk
> > CC: users@myfaces.apache.org
> > 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/>
>
_________________________________________________________________
http://clk.atdmt.com/UKM/go/msnnkmgl0010000009ukm/direct/01/
Re: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3
Posted by Scott O'Bryan <da...@gmail.com>.
Sounds strangely like a server issue. What JSF version are you using?
On May 20, 2008, at 11:14 PM, Joe Rossi <je...@hotmail.co.uk> 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: darkarena@gmail.com
> > To: users@myfaces.apache.org
> > CC: harald@elkfilm.de
> > 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: harald@elkfilm.de
> > > To: jeross@hotmail.co.uk
> > > CC: users@myfaces.apache.org
> > > 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/>
> >
>
RE: [TRINIDAD] Dialog Framework behaving strange since Trinidad
1.2.3
Posted by Joe Rossi <je...@hotmail.co.uk>.
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: darkarena@gmail.com
> To: users@myfaces.apache.org
> CC: harald@elkfilm.de
> 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: harald@elkfilm.de
> > To: jeross@hotmail.co.uk
> > CC: users@myfaces.apache.org
> > 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/>
>
_________________________________________________________________
http://clk.atdmt.com/UKM/go/msnnkmgl0010000002ukm/direct/01/
Re: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3
Posted by Scott O'Bryan <da...@gmail.com>.
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: harald@elkfilm.de
> To: jeross@hotmail.co.uk
> CC: users@myfaces.apache.org
> 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/>