Thanks for the inputs Peter. 
I had done some research on the ill effects of reverse AJAX but the advantages 
of having the feature outweighed its disadvantage.  My idea of Jetty was that 
of a light weight embeddable HTTP server which can be used for unit testing or 
in situations where high load is not expected. Are you suggesting that jetty 
can be used for some heavy lifting? 

regards,
Rajesh



----- Original Message ----
From: "p.stavrini...@albourne.com" <p.stavrini...@albourne.com>
To: Tapestry users <users@tapestry.apache.org>
Sent: Tue, 25 May, 2010 1:27:43 PM
Subject: Re: comet implementation issue


Using a dispatcher may prevent the pool becoming exhausted, but that just 
shifts the real problem elsewhere... DWR's long poling technique places a huge 
load on web servers, it is a pretty nasty hack on the HTTP protocol, which is 
not really a Tapestry problem as such. long poling won't play nice with many 
web servers, some browsers, but especially not proxies (i.e.: Apache in front 
of Tomcat), if you do use it then you should expect the unexpected and do loads 
of testing. I recommend you try Jetty if you are not already, as it handles 
reverse AJAX better than other web servers, Jetty 6 supports continuations, 
which will reduce traffic and prevent the page pool becoming exhausted... it is 
the most robust and reliable solution available for HTTP keep alives (to the 
best of my knowledge anyway). 

I tested DWR for a while, and whilst I was impressed, the extra load, latency 
and some of the reliability issues were too much of a trade off to use for my 
production environment.

regards,
Peter


----- Original Message -----
From: "Thiago H. de Paula Figueiredo" <thiag...@gmail.com>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Tuesday, 25 May, 2010 04:11:08 GMT +02:00 Athens, Beirut, Bucharest, 
Istanbul
Subject: Re: comet implementation issue

On Mon, 24 May 2010 21:45:16 -0300, rajesh sukumaran  
<rajeshs_...@yahoo.co.in> wrote:

> This behavior is not limited to the reverse ajax call but it is seen  
> with all the pages. It is as if the polling for page change stops with  
> the reverse ajax call. Can a Thread.sleep(...) in a dispatcher cause the  
> page change polling to stop?

I'm not sure, but that's possible. Instead of using Thread.sleep(), which  
has the potential of causing a deadlock, try using wait() and notifyAll()  
instead.

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to