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

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Not A Problem
• Affects Version/s: 1.5.4
• Component/s: wicket
• Labels: IDataStore wicket
• Environment: Debian 6.0.2
• Assignee: Unassigned
• Reporter: Arne Baganz
• Created: 31/Jan/12 15:24
• Updated: 31/Jan/12 16:38
• Resolved: 31/Jan/12 16:38

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.