Re: [TRINIDAD] Dialog Framework behaving strange since Trinidad 1.2.3

Wed, 21 May 2008 06:20:28 -0700

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/>
























					Reply via email to