Thanks On Thu, Sep 2, 2021 at 3:16 PM Martin Grigorov <mgrigo...@apache.org> wrote:
> 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 > > > > > > > > > >
