Sorry I meant DWR, not DRM ;-)
I believe the easy case is the one I solved, and shouldn't require any
additional markup.
- The user is interacting with the form,
- but @incremental isn't set,
- and the form controls themselves don't happen to require any DWR
interactions,
- so they don't send anything
- so the Chiba session doesn't know the user is there.
Therefore, eventually it times out.
So I propose a simple change in the behavior of the Flux JavaScript:
- The user is interacting with the form,
- but @incremental isn't set,
- and the form controls themselves don't happen to require any DWR
interactions,
- so the onfocus/onblur/onclick/onkeydown handlers on the form controls
check the time of the last DWR action
- and if the last DWR interaction was more than a minute ago, it sends a
keepalive.
- so the Chiba session *knows* the user is there.
Therefore, it doesn't time out.
This doesn't fix timeouts for the StandardServlet (non-Flux).
Leigh.
-----Original Message-----
From: joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx
[mailto:joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx]
Sent: Monday, December 18, 2006 4:22 PM
To: Klotz, Leigh
Cc: Adam Retter;
chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
Subject: Re: [Chiba-developer] timing issuesin
XFormsSessionManager/DefaultXFormsSessionManager
Klotz, Leigh wrote:
> We found that typing in a textarea could lead to session timeout, so
we
> put in a ping feature every minute or so as long as there is activity
on
> controls. @incremental satisfies it already. Probably the check
should
> have been done on most recent DRM call rather than at the ping and
event
> level, to have the optimal elimination of unnecessary pings.
Leigh,
yes, your use case has been heart and accepted as a general problem and
i've searched for generalizing an approach to such situations.
I've come up with several thoughts/ideas:
- first, we've implemented a 'pulse' feature for any form by adding a
<chiba:keepalive pulse="900"/>
element as first child under the root of the document. This allows to
add a ping to every form that might use it. The problem with this
approach is that it effectively disables server-side session management
and should be used with caution. This way a forms session would never
expire unless the user leaves in a defined way.
- second, Scott brought up the serialization topic again. If Chiba
XFormsSessions could be persisted after their timeout has happened and
deserialized when the user comes back then the problem of forms timing
out would become pointless. This is a larger change though Scott has
done some nice groundworks in the right direction.
- third i've thought about adding an chiba element to allow the author
to set the XFormsSession timeout per form. Different forms have very
different usage situations and a global timeout for every form might not
be appropriate. Together with the second point (so you can steer how
long your form lives before you've to take the cost of
(de)serialization) this looks like the most promising solution to me.
But what exactly do you mean by 'the check should have been done on most
recent DRM call ..."? Of course i'm interested in further options and
ideas to address this issue.
>
> Without some sort of ping feature, users working on forms with big
text
> areas lose their work and are unhappy.
>
> -----Original Message-----
> From:
> chiba-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> [mailto:chiba-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx]
> On Behalf Of
> Joern Turner
> Sent: Friday, December 15, 2006 1:39 PM
> To: Adam Retter
> Cc: chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> Subject: Re: [Chiba-developer] timing issuesin
> XFormsSessionManager/DefaultXFormsSessionManager
>
> Adam Retter wrote:
>> 1) XFomsSessionManager.setTimeout() the parameter is named
> milliseconds,
>> but the javadoc says seconds - which is it?
> millis
>
>> 2) XFormsSessionManager.setInterval() the parameter is not named and
>> there is no javadoc, is this seconds or milliseconds?
>>
>> 3) DefaultXFormsSessionManager.DEFAULT_TIMEOUT is set to 5000, with
> the
>> comment that its 5 minutes, however if this is in milliseconds that
>> would be 5 seconds, if its in seconds it should be 300 not 5000.
> ok, should be fixed
>
>> 4) DefaultXFormsSessionManager.interval is set as 1500, the parameter
> of
>> DefaultXFormsSessionManager.setInterval() implies that this is in
>> milliseconds. So this would be 1.5 seconds, this seems very short?
> right. This value might still be present from testing. This feature
> actually is not very stable. Though working i didn't intend to
> communicate it's existence ;) since the whole issue has been
clarified.
>
> The context here is the requirement to have sessions that don't expire
> because of long intervals between values updates through the user.
This
> pulse feature was one attempt to solve that but it does not convince
me
> yet. The better solution here would be to have persistent sessions
that
> are persisted when there's risk to loose data through session expiry.
>
> To cut it short if there are not strong arguments to keep the pulse
> feature we'll probably remove it again.
>> 5) ChibaServlet.createXFormsSession() line 443:
>> manager.setTimeout(1000 * 30); // 1 minute session lifetime
>> Assuming that setTimeout() should be set in milliseconds, this set's
> it
>> to 30 seconds, not 1 minute as the comment describes.
>>
>> I would be happy to tidy up and fix these issues is someone can
> clarify
>> whats what...
>>
>> Thanks
>>
>>
>
>
>
------------------------------------------------------------------------
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
share
> your
> opinions on IT & business topics through brief surveys - and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> _______________________________________________
> Chiba-developer mailing list
> Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/chiba-developer
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
|