a4j:poll and allowing Session Timeout

[zenig]

I have looked on the web and this forum for the following answer without luck.

I am using a4j:polling in an application with a frequent interval of 1 minute and with a http session timeout of 15 minutes.  On these pages that contain the a4j:polling, the http session doesn't expire.  From my research, this is as designed.

What are the ways around this?  I want to be able to refresh datatables that are frequently updated by all users (like a worklist) while maintaining the http session timeout if the end-user does not click on an action.

Do I have to manually build a timeout layer to handle this?  Any ideas?

[zenig]

BTW: I am using Seam 3.3.1 GA and Richfaces 3.3.3.

[zenig]

These are the options I can think of:

1. Build a session timout bean.  When a use clicks a action, update the session timeout bean.  On every web-page, I will need to a4j:poll this session bean every minute and if the (current timestamp - last activity) > 15 min, then expire session and redirect to login page.  This would require a lot of code dispersed throught the application since every click needs to update the "last activity" property of this bean.
2. See if I can extend a listener and/or use a observation framework.  For every request that isn't AJAX, update a session timeout bean.  Again, a4j:polling every minute on every page, if the session bean's (current timestamp - last activity) > 15 min, then expire session and redirect to login page.

Neither of these seem to be good options.  There must be an easier way!

[liuliu]

hi,

Did you try a4j:push? I remember it did what you want.

liu

[zenig]

I have researched the a4j:push originally and found a post stating it will also keep the session alive, but only when there is an event that is pushed.  The worklist that we have will be updated by users consistently therefore each event will reset the session timeout (much more frequently than the session timeout value).

I just found this on the web: http://relation.to/Bloggers/UsingRichFacesPushAndDataTableAjaxKeysForPartialTablesUpdates referring to the a4j:push.  It stated that this is an active bug in RF 3.3.3 though it doesn't mention the a4j:push tag.  Here is the created JIRA: https://jira.jboss.org/browse/RF-8876.

If this behavior is either as designed or turns out to be a bug, what is the easiest way to build my own session timeout layer?  I presume a session bean to hold the timeout properties and either implementing a listener or extend a component that will reset the timeout.  I don't want to call a method on the timeout bean for every user action!  This may be a better question on the Seam forum for different ways to accomplish this.

[ilya_shaikovsky]

minor about push event.. actually the session resume after the event - look normal in general as it's real event on some update data or performing some actions according to messages. It restores session for processing and it will be kept for sure in that case./

About the issue - that issue seems really specic. At first it could be caused by some Seam filters, also partially the problems described in issue - browser and server specific.

So push should fits your needs in future when we will resolve  that issue in 4.x

[zenig]

I am using RF 3.3.3, Seam 2.2.0 GA, and Glassfish 2.1.1.  Tested from Internet Explorer 8.0.

Here are my filters from web.xml:

<filter>
    <filter-name>Seam Filter</filter-name>
    <filter-class>org.jboss.seam.servlet.SeamFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>Seam Filter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

I want to make sure I am clear on the current behavior and the behavior in RF 4.x.  Let me verify:

• a4j:poll should reset the session timeout
• a4j:push should NOT reset the session timeout, except there is a bug that will be fixed in RF 4.x

Since a4j:poll and a4j:push reset the session timeout in RF 3.3.3, I'll need to search for an alternative method of exipiring a session until I can use a4j:push in RF 4.x.  Is this correct?

[ilya_shaikovsky]

Accordint to my tests - expiration occurs fine if not using seam. So you could check the Filters which instantiated by Seam Filter (it adds RF filter, logging filter and so on to chain) to check which of them performs unnesessary call to Session (which prevents expiration) and disable it.