Thanks for the replies. > > > Have you logged everything from the servlet container's session manager to > wicket session management, to identify the logic where loss occurs?
Not yet. For example, did you try with different servlet containers if same > problem occurs? Jetty, Tomcat, something else? Just to rule out the servlet > container. I don't really want to go down that road (at least yet) - the session is not lost, just the page in the session so I would not think it's the container. We've been using Tomcat for years in production. Does it fail on the first ping (after 15 minutes) or later ? No - anything from an hour to 15 hours . There does not seem to be any rhyme to it. 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. Yes to confirm we are not interacting with the application whilst the page is displayed and uploading elsewhere. NotSerializableExceptions Yes we don't have those so not that. 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, ...). Thanks for the suggestion. There is a button on the end of the upload that interacts with the page, so we would need to rethink the flow to do this. It does feel like a bodge though. Where is the Wicket code is this logic done managing the page in the session? Many thanks On Thu, Sep 2, 2021 at 9:41 AM Martin Grigorov <mgrigo...@apache.org> wrote: > Hi, > > On Wed, Sep 1, 2021 at 7:31 PM Wayne W <waynemailingli...@gmail.com> > 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 > > >
