Uploaded image for project: 'Wicket'
  1. Wicket
  2. WICKET-4374

IDataStore#removeData(String sessionId) is called when the session should not have expired

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Not A Problem
    • Affects Version/s: 1.5.4
    • Fix Version/s: None
    • Component/s: wicket
    • Labels:
    • Environment:
      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              aws1032 Arne Baganz

              Dates

              • Created:
                Updated:
                Resolved:

                Issue deployment