[jira] [Resolved] (WICKET-4374) IDataStore#removeData(String sessionId) is called when the session should not have expired

["Martin Grigorov (Resolved) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov resolved WICKET-4374.
-------------------------------------

    Resolution: Not A Problem

True.
You have to report this in different issue tracker.
                
> 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