Hi, On Wed, Sep 1, 2021 at 7:31 PM Wayne W <[email protected]> wrote:
> Hello there, > > We recently upgraded from Wicket 7.8.0 to 9.4.0 . We are experiencing > intermittent pages that are being lost from the session. > > I can reproduce in production but it takes time and is random. We have a > page where some files can be uploaded to another microservice from the > webpage via an API. We have an AbstractDefaultAjaxBehavior in the page > which gets called every 15 minutes to keep the session alive. This has > always worked well. > > I can reproduce by uploading a very large file which can take say 4 hours, > during this time I do not touch the page, or open any other tabs. The only > interaction during this process is the AbstractDefaultAjaxBehavior being > called every 15 minutes to keep the session alive. We see that > intermittently the page cannot be found in the session and wicket > automatically recreates the page again. This coming from the call to > the AbstractDefaultAjaxBehavior - we see in the HTTP response headers that > wicket adds 'ajax-location: /the-page-we-are-on' and the wicket ajax JS > does a redirect to recreate the page. > Does it fail on the first ping (after 15 minutes) or later ? > > This kills the upload obviously as the page is refreshed. > > What could be causing this and where can I look in the code to understand > when wicket decides to eject the page from the session? FYI we have > setMaxSizePerSession > set at 10MB. > Wicket overwrites the oldest page(s) in the disk store if there are many interactions with other pages. If you don't do anything (e.g. in another tab) with the application then Wicket should not overwrite/remove the disk store for your session. > > When does wicket decide to return the ajax-location header? > Wicket does that when it needs to trigger a redirect in an Ajax response. The Ajax request cannot find the page instance for some reason and (by default) Wicket creates a new instance of the same page class and tells the browser to move to it. > > It is possible this issue was happening in 7.8 but was not on our radar so > is unknown. > Most of the time when a page cannot be found in the disk store is because there was a problem with its serialization, i.e. it was not stored on the disk at all. But in this case you should see some NotSerializableExceptions in the server logs. As a workaround you may do your ping to a Wicket Resource, or another servlet. This will be enough to keep the http session without the extra logic done in Wicket Ajax requests (resolve a page, resolve the component in the tree, execute the callback method, ...). > > Many thanks > Wayne >
