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
