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


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


Reply via email to