You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by rajesh sukumaran <ra...@yahoo.co.in> on 2010/05/12 05:19:20 UTC
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: comet implementation issue
Posted by rajesh sukumaran <ra...@yahoo.co.in>.
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 <th...@gmail.com>
To: Tapestry users <us...@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 <ra...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: comet implementation issue
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 24 May 2010 21:45:16 -0300, rajesh sukumaran
<ra...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: comet implementation issue
Posted by rajesh sukumaran <ra...@yahoo.co.in>.
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 <th...@gmail.com>
To: Tapestry users <us...@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 <ra...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: comet implementation issue
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Sat, 22 May 2010 19:19:01 -0300, rajesh sukumaran
<ra...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: comet implementation issue
Posted by rajesh sukumaran <ra...@yahoo.co.in>.
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 <ju...@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 <th...@gmail.com>
> To: Tapestry users <us...@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
> <ra...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: comet implementation issue
Posted by Juan Isern <ju...@gmail.com>.
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 <th...@gmail.com>
> To: Tapestry users <us...@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
> <ra...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: comet implementation issue
Posted by rajesh sukumaran <ra...@yahoo.co.in>.
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 <th...@gmail.com>
To: Tapestry users <us...@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 <ra...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: comet implementation issue
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 12 May 2010 00:19:20 -0300, rajesh sukumaran
<ra...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org