Dominik Bieliński created WICKET-6384:
-----------------------------------------
Summary: Current page is serialized in case of multiple ajax
requests on previous page
Key: WICKET-6384
URL: https://issues.apache.org/jira/browse/WICKET-6384
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 7.7.0
Reporter: Dominik Bieliński
Attachments: demo.rar
We have multiple pages that each contains multiple (>10) components that are
scheduling DB queries to a thread pool. Each component is using
AbstractAjaxTimerBehavior to check whether or not the data has been already
fetched with very low timer interval (30 miliseconds). The issue is that under
the presence of MANY ajax requests (almost every possible milisecond), if the
user navigates to some other page, that new page is serialized instantly -
after new page is created, there is usually 1 or 2 requests from old page still
passing through. I created simple spring boot project to demonstrate what I
mean. The flow is as below:
1. Start on HomePage with just 1 component with AbstractAjaxTimerBehavior
2. Click on TestPage button to move to TestPage with >10 such components
3. Before most components are finished fetching data, navigate to HomePage
again by clicking HomePage button.
4. The component on HomePage will now never finish loading, because I think it
has been serialized and deserialized just after creation (thus the reference to
Provider variable has changed, which means that originally created thread will
never update the correct object) - just after new page is created, there is
usually one more request coming from old page that probably involves
serialization of new page.
You can check System.out logs which clearly show what's happening when
switching from TestPage to HomePage.
The problem is resolved by increasing timer interval of updating to, for
instance, 200 miliseconds. However I don't think interval itself is the issue
here, because in theory you could have hundreds of such components and thus
further increase of interval would be needed to avoid the issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)