You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Kris Schneider <ks...@gmail.com> on 2005/10/18 15:36:22 UTC
Public API for keeping a continuation alive?
Here's the usage scenario: We want a client-side timer to display a
warning when a user's session is about to expire. This is especially
important for forms that have unsaved data. Obviously, it's easy
enough to send an arbitrary request to the app to keep the HTTP
session alive, but how can the same effect be accomplished for a
continuation? Assuming we have the continuation's id, is there any
form of a public API available to "ping" the continuation so that it
doesn't expire? If it's of any consequence, we have configured the
continuations manager to use session-bound continuations.
Thanks for any info.
--
Kris Schneider <ma...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Public API for keeping a continuation alive?
Posted by Sylvain Wallez <sy...@apache.org>.
Kris Schneider wrote:
> On 10/18/05, Sylvain Wallez <sy...@apache.org> wrote:
>
>> I would be interesting IMO to have a "PingContinuationAction" that can
>> be called using an Ajax request for long-running forms. I'll add this to
>> the Ajax block.
>>
>
> +1. But there's going to need to be some additonal support in the core
> flow impl to allow an action to actually update the continuation's
> last acces time, right?
>
No, it's already there. Calling WebContinuation.getContinuation() (which
gets the "native" continuation object) updates the last access time.
This action will be in the new Ajax block in 2.1.8
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Public API for keeping a continuation alive?
Posted by Kris Schneider <ks...@gmail.com>.
On 10/18/05, Sylvain Wallez <sy...@apache.org> wrote:
> Reinhard Poetz wrote:
> > Kris Schneider wrote:
> >> Here's the usage scenario: We want a client-side timer to display a
> >> warning when a user's session is about to expire. This is especially
> >> important for forms that have unsaved data. Obviously, it's easy
> >> enough to send an arbitrary request to the app to keep the HTTP
> >> session alive, but how can the same effect be accomplished for a
> >> continuation? Assuming we have the continuation's id, is there any
> >> form of a public API available to "ping" the continuation so that it
> >> doesn't expire?
> >
> > No
>
> I would be interesting IMO to have a "PingContinuationAction" that can
> be called using an Ajax request for long-running forms. I'll add this to
> the Ajax block.
+1. But there's going to need to be some additonal support in the core
flow impl to allow an action to actually update the continuation's
last acces time, right?
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://people.apache.org/~sylvain http://www.anyware-tech.com
> Apache Software Foundation Member Research & Technology Director
--
Kris Schneider <ma...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Public API for keeping a continuation alive?
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Kris Schneider wrote:
>> Here's the usage scenario: We want a client-side timer to display a
>> warning when a user's session is about to expire. This is especially
>> important for forms that have unsaved data. Obviously, it's easy
>> enough to send an arbitrary request to the app to keep the HTTP
>> session alive, but how can the same effect be accomplished for a
>> continuation? Assuming we have the continuation's id, is there any
>> form of a public API available to "ping" the continuation so that it
>> doesn't expire?
>
> No
I would be interesting IMO to have a "PingContinuationAction" that can
be called using an Ajax request for long-running forms. I'll add this to
the Ajax block.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Public API for keeping a continuation alive?
Posted by Reinhard Poetz <re...@apache.org>.
Kris Schneider wrote:
> On 10/18/05, Reinhard Poetz <re...@apache.org> wrote:
>
>>Kris Schneider wrote:
>>
>>>Reinhard,
>>
>>>>Several weeks ago I refactored the ContinuationsManagerImpl so that it is easily
>>>>extensible and you can use your own expiration strategies by simply overriding
>>>>the "expireContinuations" method. Over the next weeks I will work on them -
>>>>maybe this is helpful for you too.
>>>
>>>
>>>Any idea if those changes are compatible with 2.1.7? Because of some
>>>concurrency issues with 2.1.7's ContinuationsManagerImpl (I haven't
>>>submitted the bug yet), I'm already using a "custom" version. If your
>>>changes will work with 2.1.7, I might as well use that as a base
>>>instead.
>>
>>I had to change the visibility of some methods from "private" to "protected" and
>>I also split up one method into smaller ones that can be overriden too.
>>My changes will be part of the upcoming 2.1.8 release.
>>
>>If you want to get your bugfix included into 2.1.8 you should provide the patch
>>very soon so that the chance is high(er) that it is applied in time. Of course
>>we have to verify in some way that the patch doesn't make things worse which
>>could be a problem as code freeze starts on Friday 21st. In every case this
>>needs to be discussed on cocoon-dev.
>
>
> I probably need to wait on posting a fix since I don't think I've
> addressed all the issues. Is the plan to release 2.1.8 from the trunk
> or the BRANCH_2_1_X? It looks like your version (rev. 293111) is in
> the trunk but there's a "newer" version (rev. 312605) in the branch.
> Any suggestions on which one to take? Thanks.
Cocoon 2.1.8 will be released from BRANCH_2_1_X. The version in trunk is
slightly different as the instrumentation code has been removed, otherwise it
should be the same.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Public API for keeping a continuation alive?
Posted by Kris Schneider <ks...@gmail.com>.
On 10/18/05, Kris Schneider <ks...@gmail.com> wrote:
> On 10/18/05, Reinhard Poetz <re...@apache.org> wrote:
> > Kris Schneider wrote:
> > > Reinhard,
> >
> > >>Several weeks ago I refactored the ContinuationsManagerImpl so that it is easily
> > >>extensible and you can use your own expiration strategies by simply overriding
> > >>the "expireContinuations" method. Over the next weeks I will work on them -
> > >>maybe this is helpful for you too.
> > >
> > >
> > > Any idea if those changes are compatible with 2.1.7? Because of some
> > > concurrency issues with 2.1.7's ContinuationsManagerImpl (I haven't
> > > submitted the bug yet), I'm already using a "custom" version. If your
> > > changes will work with 2.1.7, I might as well use that as a base
> > > instead.
> >
> > I had to change the visibility of some methods from "private" to "protected" and
> > I also split up one method into smaller ones that can be overriden too.
> > My changes will be part of the upcoming 2.1.8 release.
> >
> > If you want to get your bugfix included into 2.1.8 you should provide the patch
> > very soon so that the chance is high(er) that it is applied in time. Of course
> > we have to verify in some way that the patch doesn't make things worse which
> > could be a problem as code freeze starts on Friday 21st. In every case this
> > needs to be discussed on cocoon-dev.
>
> I probably need to wait on posting a fix since I don't think I've
> addressed all the issues. Is the plan to release 2.1.8 from the trunk
> or the BRANCH_2_1_X? It looks like your version (rev. 293111) is in
> the trunk but there's a "newer" version (rev. 312605) in the branch.
> Any suggestions on which one to take? Thanks.
Looked a little bit harder at the repo and it sems like BRANCH_2_1_X
is the way to go...
> > --
> > Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
> >
> > {Software Engineering, Open Source, Web Applications, Apache Cocoon}
> >
> > web(log): http://www.poetz.cc
> > --------------------------------------------------------------------
>
>
> --
> Kris Schneider <ma...@gmail.com>
--
Kris Schneider <ma...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Public API for keeping a continuation alive?
Posted by Kris Schneider <ks...@gmail.com>.
On 10/18/05, Reinhard Poetz <re...@apache.org> wrote:
> Kris Schneider wrote:
> > Reinhard,
>
> >>Several weeks ago I refactored the ContinuationsManagerImpl so that it is easily
> >>extensible and you can use your own expiration strategies by simply overriding
> >>the "expireContinuations" method. Over the next weeks I will work on them -
> >>maybe this is helpful for you too.
> >
> >
> > Any idea if those changes are compatible with 2.1.7? Because of some
> > concurrency issues with 2.1.7's ContinuationsManagerImpl (I haven't
> > submitted the bug yet), I'm already using a "custom" version. If your
> > changes will work with 2.1.7, I might as well use that as a base
> > instead.
>
> I had to change the visibility of some methods from "private" to "protected" and
> I also split up one method into smaller ones that can be overriden too.
> My changes will be part of the upcoming 2.1.8 release.
>
> If you want to get your bugfix included into 2.1.8 you should provide the patch
> very soon so that the chance is high(er) that it is applied in time. Of course
> we have to verify in some way that the patch doesn't make things worse which
> could be a problem as code freeze starts on Friday 21st. In every case this
> needs to be discussed on cocoon-dev.
I probably need to wait on posting a fix since I don't think I've
addressed all the issues. Is the plan to release 2.1.8 from the trunk
or the BRANCH_2_1_X? It looks like your version (rev. 293111) is in
the trunk but there's a "newer" version (rev. 312605) in the branch.
Any suggestions on which one to take? Thanks.
> --
> Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
>
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
>
> web(log): http://www.poetz.cc
> --------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
--
Kris Schneider <ma...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Public API for keeping a continuation alive?
Posted by Reinhard Poetz <re...@apache.org>.
Kris Schneider wrote:
> Reinhard,
>>Several weeks ago I refactored the ContinuationsManagerImpl so that it is easily
>>extensible and you can use your own expiration strategies by simply overriding
>>the "expireContinuations" method. Over the next weeks I will work on them -
>>maybe this is helpful for you too.
>
>
> Any idea if those changes are compatible with 2.1.7? Because of some
> concurrency issues with 2.1.7's ContinuationsManagerImpl (I haven't
> submitted the bug yet), I'm already using a "custom" version. If your
> changes will work with 2.1.7, I might as well use that as a base
> instead.
I had to change the visibility of some methods from "private" to "protected" and
I also split up one method into smaller ones that can be overriden too.
My changes will be part of the upcoming 2.1.8 release.
If you want to get your bugfix included into 2.1.8 you should provide the patch
very soon so that the chance is high(er) that it is applied in time. Of course
we have to verify in some way that the patch doesn't make things worse which
could be a problem as code freeze starts on Friday 21st. In every case this
needs to be discussed on cocoon-dev.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Public API for keeping a continuation alive?
Posted by Kris Schneider <ks...@gmail.com>.
Reinhard,
Thanks for the feedback, see inline.
On 10/18/05, Reinhard Poetz <re...@apache.org> wrote:
> Kris Schneider wrote:
> > Here's the usage scenario: We want a client-side timer to display a
> > warning when a user's session is about to expire. This is especially
> > important for forms that have unsaved data. Obviously, it's easy
> > enough to send an arbitrary request to the app to keep the HTTP
> > session alive, but how can the same effect be accomplished for a
> > continuation? Assuming we have the continuation's id, is there any
> > form of a public API available to "ping" the continuation so that it
> > doesn't expire?
>
> No
>
> > If it's of any consequence, we have configured the
> > continuations manager to use session-bound continuations.
> >
> > Thanks for any info.
>
> Binding the continuations has the benefit of getting them invalidated
> automatically when the session expires. If the continuation expires before the
> session expires, it will be removed at this point (and doesn't wait for the
> session to become invalid).
Right, we decided to bind to the session for exactly that benefit. The
issue is being able to simply update a continuation's last access time
via a request.
> Several weeks ago I refactored the ContinuationsManagerImpl so that it is easily
> extensible and you can use your own expiration strategies by simply overriding
> the "expireContinuations" method. Over the next weeks I will work on them -
> maybe this is helpful for you too.
Any idea if those changes are compatible with 2.1.7? Because of some
concurrency issues with 2.1.7's ContinuationsManagerImpl (I haven't
submitted the bug yet), I'm already using a "custom" version. If your
changes will work with 2.1.7, I might as well use that as a base
instead.
> --
> Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
>
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
>
> web(log): http://www.poetz.cc
> --------------------------------------------------------------------
--
Kris Schneider <ma...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Public API for keeping a continuation alive?
Posted by Reinhard Poetz <re...@apache.org>.
Kris Schneider wrote:
> Here's the usage scenario: We want a client-side timer to display a
> warning when a user's session is about to expire. This is especially
> important for forms that have unsaved data. Obviously, it's easy
> enough to send an arbitrary request to the app to keep the HTTP
> session alive, but how can the same effect be accomplished for a
> continuation? Assuming we have the continuation's id, is there any
> form of a public API available to "ping" the continuation so that it
> doesn't expire?
No
> If it's of any consequence, we have configured the
> continuations manager to use session-bound continuations.
>
> Thanks for any info.
Binding the continuations has the benefit of getting them invalidated
automatically when the session expires. If the continuation expires before the
session expires, it will be removed at this point (and doesn't wait for the
session to become invalid).
Several weeks ago I refactored the ContinuationsManagerImpl so that it is easily
extensible and you can use your own expiration strategies by simply overriding
the "expireContinuations" method. Over the next weeks I will work on them -
maybe this is helpful for you too.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org