Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Not A Problem
-
1.5.4
-
None
-
Debian 6.0.2
Description
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.