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]> 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]; [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 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]> 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]
> To: [email protected]
> CC: [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]
> > To: [EMAIL PROTECTED]
> > CC: [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!
_________________________________________________________________
http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/
