Re: Page is being lost from Session intermittently
Thanks On Thu, Sep 2, 2021 at 3:16 PM Martin Grigorov wrote: > On Thu, Sep 2, 2021 at 3:48 PM Wayne W > 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 > > wrote: > > > > > Hi, > > > > > > On Wed, Sep 1, 2021 at 7:31 PM Wayne W > > > 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 ma
Re: Page is being lost from Session intermittently
On Thu, Sep 2, 2021 at 3:48 PM Wayne W 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 > wrote: > > > Hi, > > > > On Wed, Sep 1, 2021 at 7:31 PM Wayne W > > 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 > > > > > >
Re: Page is being lost from Session intermittently
to 2. syysk. 2021 klo 15.48 Wayne W (waynemailingli...@gmail.com) kirjoitti: > 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? > In my experience a good trick is to search from wicket source with any keywords you find from the logs, and work from there, add more debug logging where necessary. ** Martin > > Many thanks > > > > > > > On Thu, Sep 2, 2021 at 9:41 AM Martin Grigorov > wrote: > > > Hi, > > > > On Wed, Sep 1, 2021 at 7:31 PM Wayne W > > 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 > > > > > >
Re: Page is being lost from Session intermittently
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 wrote: > Hi, > > On Wed, Sep 1, 2021 at 7:31 PM Wayne W > 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 > > >
Re: Page is being lost from Session intermittently
Hi, On Wed, Sep 1, 2021 at 7:31 PM Wayne W 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 >
Re: Page is being lost from Session intermittently
Hi! Have you logged everything from the servlet container's session manager to wicket session management, to identify the logic where loss occurs? If necessary, you could compile a custom version of these from sources, to add more necessary logging, to trace where the ball drops. For example, did you try with different servlet containers if same problem occurs? Jetty, Tomcat, something else? Just to rule out the servlet container. ** Martin ke 1. syysk. 2021 klo 19.31 Wayne W (waynemailingli...@gmail.com) kirjoitti: > 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. > > 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. > > When does wicket decide to return the ajax-location header? > > It is possible this issue was happening in 7.8 but was not on our radar so > is unknown. > > Many thanks > Wayne >
Page is being lost from Session intermittently
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. 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. When does wicket decide to return the ajax-location header? It is possible this issue was happening in 7.8 but was not on our radar so is unknown. Many thanks Wayne
