You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Pavol M (Jira)" <ji...@apache.org> on 2021/02/19 18:39:00 UTC

[jira] [Updated] (WICKET-6869) StalePageException does not refresh page

     [ https://issues.apache.org/jira/browse/WICKET-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pavol M updated WICKET-6869:
----------------------------
    Attachment: wicket_8.9.0.zip
                wicket_8.11.0.zip

> StalePageException does not refresh page
> ----------------------------------------
>
>                 Key: WICKET-6869
>                 URL: https://issues.apache.org/jira/browse/WICKET-6869
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 8.9.0, 8.11.0
>            Reporter: Pavol M
>            Priority: Major
>         Attachments: wicket_8.11.0.zip, wicket_8.9.0.zip
>
>
> After migration from version 7.4.0 to 8.9.0 we realized, that in some scenarios _StalePageException_ does not refresh entire page, but is displayed on the page when working with multiple tabs/windows.
> When debugging and comparing with version 7.4.0, I would say, that problem is in lazy initialization of _PageProvider.provision_ class member, which did not exist in 7.4.0 (attributes were not wrapped in _provision_, but placed directly in _PageProvider_).
> {code:java}
> private Provision getProvision()
> 	{
> 		if (provision == null)
> 		{
> 			provision = new Provision().resolve();
> 		}
> 		return provision;
> 	}
> {code}
> The problem with that is calling _resolve()_ method within assigning new _Provision_ to _PageProvider.provision_. If _resolve()_ method throws _StalePageException_ then _PageProvider.provision_ remains null and later calls to _getProvisison()_ repeats the same flow and throws _StalePageException_ again. _Resolve()_ method sets _Provision.page_ attribute before throwing _StalePageException_, but _page_ attribute cannot be used later, because it is wrapped in created _Provision_, which is never assigned to _PageProvider.provision_.
> _PageProvider.getProvisison()_ is often called by request cycle and whether page is refreshed or exception is displayed, depends on where in request cycle _StalePageException_ is thrown:
>  * _resolveRequestHandler_ - refresh (depends on what request mapper is used - some does not call _PageProvider.getProvisison()_, like _PageInstanceMapper_, and processing continues to execute handler)
>  * _execute handler_ - ready to handle _StalePageException_.
>  * _detach_ - not ready to handle _StalePageException_ - exception is bubbled up and displayed on page.
> Whether _StalePageException_ is thrown or not during detach phase depends on the content of _RequestHandlerExecutor.inactiveRequestHandlers_ - for example, if _resolveRequestHandler()_ throws _StalePageException_, then _inactiveRequestHandleres_ contains only one _RenderPageRequestHandler_ (responsible for redirection/refresh), if not, then there are two handlers - original for processing request (e.g. _ListenerRequestHandler_) and _RenderPageRequestHandler_ for redirection/refresh. Then _detach()_ is called on every handler in _RequestHandlerExecutor.inactiveRequestHandlers_ and if there is also original one (with _pageProvider_ with unitiliazed provision), then _StalePageException_ is thrown again (because of _PageLogData_ creation calls _PageProvider.getProvisison()_ and tries to initialize provision again).
>  
> Ok, that's for 8.9.0. A little different story is for 8.11.0. Some changes have been made meanwhile - detaching catches and only logs exception instead of rethrowing exception: [https://github.com/apache/wicket/commit/e5cd09ba8c1c02f213b1e47bbe9dff0e626120ea]
> The consequence in 8.11.0 is the page is refreshed (instead of showing exception on page) if StalePageException happens, but there is still ERROR message in the log:
> {noformat}
> [qtp598446861-30] ERROR org.apache.wicket.request.cycle.RequestCycle - Error detaching RequestCycle
> org.apache.wicket.core.request.mapper.StalePageException: A request to page '[Page class = com.mycompany.Page, id = 1, render count = 4]' has been made with stale 'renderCount'. The page will be re-rendered.
> {noformat}
> It has been "fixed" by coincidence, I would say, and still there is an unwanted ERROR message in the log which should not be there because of StalePageException (operation guys report every ERROR in the log). It would be better to fix the real cause of the problem - inappropriate lazy initializaion of _PageProvider.provision_.
>  
> Attached quickstarts for 8.9.0 and 8.11.0:
>  * run src/test/java/Start.java
>  * open [http://localhost:8080|http://localhost:8080/] and click on Start and then on Continue
>  * then copy url and open it in another tab/window and then click on ajaxLink on both tabs/windows and look for ERROR in a log (8.11.0) or on page itself (8.9.0)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)