On Thu, Sep 2, 2021 at 3:48 PM Wayne W <waynemailingli...@gmail.com> wrote:
> 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? > https://github.com/apache/wicket/blob/d1b17b53b3141082c038f4721836488cb38f9083/wicket-core/src/main/java/org/apache/wicket/core/request/handler/PageProvider.java#L401 > > 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 > > > > > >
