Re: comet implementation issue
Without a doubt Jetty can do the heavy lifting, for most applications its more than adequate, like Tomcat its a first class web server. - Original Message - From: Thiago H. de Paula Figueiredo thiag...@gmail.com To: Tapestry users users@tapestry.apache.org Sent: Saturday, 29 May, 2010 17:18:12 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: comet implementation issue On Sat, 29 May 2010 07:24:59 -0300, Robin Komiwes robin.komi...@gmail.com wrote: For information, I think Jetty is powering Google App Engine. See: http://jetty.codehaus.org/jetty/ GAE does use Jetty. By the way, Jetty is an Eclipse project now: http://www.eclipse.org/jetty/ -- 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
Re: comet implementation issue
yes, you are right thread.sleep does not look like the right approach, it does not scale either. thanks - Original Message From: Thiago H. de Paula Figueiredo thiag...@gmail.com To: Tapestry users users@tapestry.apache.org Sent: Tue, 25 May, 2010 6:41:08 AM 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
Re: comet implementation issue
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
Re: comet implementation issue
For information, I think Jetty is powering Google App Engine. See: http://jetty.codehaus.org/jetty/ http://jetty.codehaus.org/jetty/ On Sat, May 29, 2010 at 8:59 AM, rajesh sukumaran rajeshs_...@yahoo.co.inwrote: 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
Re: comet implementation issue
On Sat, 29 May 2010 07:24:59 -0300, Robin Komiwes robin.komi...@gmail.com wrote: For information, I think Jetty is powering Google App Engine. See: http://jetty.codehaus.org/jetty/ GAE does use Jetty. By the way, Jetty is an Eclipse project now: http://www.eclipse.org/jetty/ -- 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
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
Re: comet implementation issue
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? - Original Message From: Thiago H. de Paula Figueiredo thiag...@gmail.com To: Tapestry users users@tapestry.apache.org Sent: Sun, 23 May, 2010 6:01:48 PM Subject: Re: comet implementation issue On Sat, 22 May 2010 19:19:01 -0300, rajesh sukumaran rajeshs_...@yahoo.co.in wrote: Hi, Hi! Once the reverse ajax script fires the change made to the TML files will not get reflected in the browser. I have to restart the web application to see the effect of a change in TML files. This is causing lot of inconvenience in the development environment. I guess the .tml file checks are only triggered when there's a request for the corresponding page. As you're using a dispatcher, this check may not be done. One trick you can do is to change something in the page class (type a space, delete it, save), as it will rebuild the internal representation of the page, including its template. --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
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
Re: comet implementation issue
On Sat, 22 May 2010 19:19:01 -0300, rajesh sukumaran rajeshs_...@yahoo.co.in wrote: Hi, Hi! Once the reverse ajax script fires the change made to the TML files will not get reflected in the browser. I have to restart the web application to see the effect of a change in TML files. This is causing lot of inconvenience in the development environment. I guess the .tml file checks are only triggered when there's a request for the corresponding page. As you're using a dispatcher, this check may not be done. One trick you can do is to change something in the page class (type a space, delete it, save), as it will rebuild the internal representation of the page, including its template. -- 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
Re: comet implementation issue
Hi, May be Tapestry is not designed to support comet but I thought of giving it a try and see what happens. The dispatcher approach does the job for me except for one thing. Once the reverse ajax script fires the change made to the TML files will not get reflected in the browser. I have to restart the web application to see the effect of a change in TML files. This is causing lot of inconvenience in the development environment. In the dispatcher based comet implementation, a request dispatcher handles all the reverse ajax calls. The dispatcher checks for new data every second and responds with a status when data is found. I used Thread.sleep(...) method to add the polling delay. Can someone please help me understand why this would prevent changes TML files from getting automatically reloaded when modified? - Original Message From: Juan Isern juanis...@gmail.com To: users@tapestry.apache.org Sent: Sun, 16 May, 2010 1:26:49 AM Subject: Re: comet implementation issue Hi Rajesh, Maybe Tapestry is not meant to do Comet for the reasons that Thiago stated. I'm implementing Comet as well but with a different approach: The Comet thing is totally handled by another tool (DWR) that's used only to notify clients that some data is available. When a notification (data is ready) comes, we perform some action or refresh a zone in the page (this time is handled 100% by Tapestry) It is true that DWR and Tapestry features overlap at some point, but I think is a good tradeoff. Regards rajeshs wrote: Thanks Thiago, The markup returned is very simple. I'll try out the dispatcher approach. BTW you are right I am using Tapestry 5.1.0.5. regards, Rajesh - Original Message From: Thiago H. de Paula Figueiredo thiag...@gmail.com To: Tapestry users users@tapestry.apache.org Sent: Wed, 12 May, 2010 5:59:12 PM Subject: Re: comet implementation issue On Wed, 12 May 2010 00:19:20 -0300, rajesh sukumaran rajeshs_...@yahoo.co.in wrote: Hi, Hi! I implemented reverse ajax component that uses long polling technique. Basically what I did was to use JQuery's jQuery.getJSON(...) method to make an ajax call using an action event URL of the component. The action event on the component spawns another event(using resourse.triggerEvent()) which is handled by the page that holds the component. The event handler in the page waits for the relevant data to be available and when it is available return a block for displaying the data. Tapestry uses a pool of pages. So, when a request takes long to complete and more requests to the same page are done, the number of page instances checked out of pool the increases until it reaches the hard limit. So, yes, Tapestry pages were not meant to use in long polling. Is the block your returning complex markup? If not, I would create a Dispatcher (that is not pooled) to handle these requests and return the information as JSON. BTW I am using Tapestry 5.0.1 with tomcat 6.0. Any help is much appreciated. 5.0.1? Wouldn't it be 5.1? 5.0.1 is almost three years old now. --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 -- View this message in context: http://old.nabble.com/comet-implementation-issue-tp28531634p28570596.html Sent from the Tapestry - User mailing list archive at Nabble.com. - 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
Re: comet implementation issue
Hi Rajesh, Maybe Tapestry is not meant to do Comet for the reasons that Thiago stated. I'm implementing Comet as well but with a different approach: The Comet thing is totally handled by another tool (DWR) that's used only to notify clients that some data is available. When a notification (data is ready) comes, we perform some action or refresh a zone in the page (this time is handled 100% by Tapestry) It is true that DWR and Tapestry features overlap at some point, but I think is a good tradeoff. Regards rajeshs wrote: Thanks Thiago, The markup returned is very simple. I'll try out the dispatcher approach. BTW you are right I am using Tapestry 5.1.0.5. regards, Rajesh - Original Message From: Thiago H. de Paula Figueiredo thiag...@gmail.com To: Tapestry users users@tapestry.apache.org Sent: Wed, 12 May, 2010 5:59:12 PM Subject: Re: comet implementation issue On Wed, 12 May 2010 00:19:20 -0300, rajesh sukumaran rajeshs_...@yahoo.co.in wrote: Hi, Hi! I implemented reverse ajax component that uses long polling technique. Basically what I did was to use JQuery's jQuery.getJSON(...) method to make an ajax call using an action event URL of the component. The action event on the component spawns another event(using resourse.triggerEvent()) which is handled by the page that holds the component. The event handler in the page waits for the relevant data to be available and when it is available return a block for displaying the data. Tapestry uses a pool of pages. So, when a request takes long to complete and more requests to the same page are done, the number of page instances checked out of pool the increases until it reaches the hard limit. So, yes, Tapestry pages were not meant to use in long polling. Is the block your returning complex markup? If not, I would create a Dispatcher (that is not pooled) to handle these requests and return the information as JSON. BTW I am using Tapestry 5.0.1 with tomcat 6.0. Any help is much appreciated. 5.0.1? Wouldn't it be 5.1? 5.0.1 is almost three years old now. --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 -- View this message in context: http://old.nabble.com/comet-implementation-issue-tp28531634p28570596.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: comet implementation issue
On Wed, 12 May 2010 00:19:20 -0300, rajesh sukumaran rajeshs_...@yahoo.co.in wrote: Hi, Hi! I implemented reverse ajax component that uses long polling technique. Basically what I did was to use JQuery's jQuery.getJSON(...) method to make an ajax call using an action event URL of the component. The action event on the component spawns another event(using resourse.triggerEvent()) which is handled by the page that holds the component. The event handler in the page waits for the relevant data to be available and when it is available return a block for displaying the data. Tapestry uses a pool of pages. So, when a request takes long to complete and more requests to the same page are done, the number of page instances checked out of pool the increases until it reaches the hard limit. So, yes, Tapestry pages were not meant to use in long polling. Is the block your returning complex markup? If not, I would create a Dispatcher (that is not pooled) to handle these requests and return the information as JSON. BTW I am using Tapestry 5.0.1 with tomcat 6.0. Any help is much appreciated. 5.0.1? Wouldn't it be 5.1? 5.0.1 is almost three years old now. -- 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
comet implementation issue
Hi, I implemented reverse ajax component that uses long polling technique. Basically what I did was to use JQuery's jQuery.getJSON(...) method to make an ajax call using an action event URL of the component. The action event on the component spawns another event(using resourse.triggerEvent()) which is handled by the page that holds the component. The event handler in the page waits for the relevant data to be available and when it is available return a block for displaying the data. The Block returned by the event handler is wrapped in a JSON object and returned. The call back method given in jQuery.getJSON(...) will render the returned block within a zone and then make the ajax call again. This seems to be working fine if the web page is used for a short period of time but if there are couple of pages opened and they are idle for sometime, I get a page pool exhausted exception. I can adjust tapestry.page-pool.hard-limit but that will only delay the error for sometime but eventually the page pool will be exhausted. There is a delay of 3 sec for the callback method to invoke the ajax call after getting back the result. Is there anything inherent in the tapestry framework that would prevent reverse ajax from or working or am I doing something wrong? BTW I am using Tapestry 5.0.1 with tomcat 6.0. Any help is much appreciated. Regards Rajesh Sukumaran - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
