Major Description
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).
private Provision getProvision() { if (provision == null) { provision = new Provision().resolve(); } return provision; }
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:
[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.
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 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)