[
https://issues.apache.org/jira/browse/WICKET-6384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030209#comment-16030209
]
Sven Meier commented on WICKET-6384:
------------------------------------
Yes, this is how I would do it:
You see that there isn't any problem with serialization any longer.
I don't think you have to keep all data in memory: You could load that
information lazily from where ever you have stored it.
Regarding housekeeping of calculations and their identifiers: Don't let the
timer remove the identifier, let the background processing do it - see attached
class.
> 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
> Assignee: Sven Meier
> Attachments: demo_2.rar, 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)
