[
https://issues.apache.org/jira/browse/WICKET-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197003#comment-13197003
]
Arne Baganz commented on WICKET-4374:
-------------------------------------
Looking at the stacktrace, this does not seem to be a Wicket issue anymore,
because
"org.eclipse.jetty.server.session.AbstractSession.unbindValue(AbstractSession.java:486)"
unbinds the session (I´m using jetty-distribution-8.0.4.v20111024 in
conjunction with jetty-nosql-memcached-kryo-0.2.0-SNAPSHOT).
> IDataStore#removeData(String sessionId) is called when the session should not
> have expired
> ------------------------------------------------------------------------------------------
>
> Key: WICKET-4374
> URL: https://issues.apache.org/jira/browse/WICKET-4374
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.4
> Environment: Debian 6.0.2
> Reporter: Arne Baganz
> Labels: IDataStore, wicket
> Attachments: clustered-stack.log
>
>
> I´m running Wicket in a clustered setup (1 loadbalancer with non-sticky
> sessions, 2 servers running the webapp, the sessions are stored in memcache).
> I´m using a custom IDataStore relying on EhCache and I´m wondering about
> IDataStore#removeData(String sessionId) being called quite often (wicket
> seems to assume the session to be expired), even image resources call that
> method. But the session should not be expired (at least I think it should not
> have), because after IDataStore#removeData(String sessionId) has been called,
> the webapp still tries to access pages from that very same session via
> IDataStore#getData(String sessionId, int id) and tries to store pages via
> IDataStore#storeData(String sessionId, int id, byte[] data). So in order to
> keep my webapp working, I do not do anything in my implementation of
> IDataStore#removeData(String sessionId) anymore, because it would break
> AJAX-requests (the page could not be found in the store, because it had been
> wiped via IDataStore#removeData(String sessionId) and the URL gets rewritten
> with a fallback containing the notorious page id version after the quesion
> mark, i.e. http://www.mypage.com/myfolder/myfile-11.html?0, which is not a
> fitting response to the AJAX-request).
> Unfortunately, I do not see an easy way to provide a quickstart, which
> reproduces the problem. Even if I could provide a quickstart, it would maybe
> be heavily dependent on my setup as described above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
