You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Emond Papegaaij (JIRA)" <ji...@apache.org> on 2015/07/07 09:52:05 UTC

[jira] [Reopened] (WICKET-5933) Avoid serialization of untouched page after ajax request

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

Emond Papegaaij reopened WICKET-5933:
-------------------------------------

This change breaks Wicket very hard. You cannot rely on the page being marked dirty via Wicket. It is too easy to make a page dirty in other ways. For example, the attached quickstart increments a counter on every ajax click. Without the touchPage call, the page is never marked dirty, and thus never serialized.

To see the issue:
 - click the link several times
 - change the url to localhost:8080/?1 to switch to page 1
 - change the url to localhost:8080/?2 to switch to page 2
 - change the url to localhost:8080/?0 to switch back to page 0 and notice the counter not being shown at all (the page is back to its initial state)

> Avoid serialization of untouched page after ajax request
> --------------------------------------------------------
>
>                 Key: WICKET-5933
>                 URL: https://issues.apache.org/jira/browse/WICKET-5933
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 6.19.0, 7.0.0-M6
>            Reporter: Fridolin Jackstadt
>            Assignee: Andrea Del Bene
>             Fix For: 7.0.0, 6.21.0
>
>         Attachments: dirtycheck.tar.gz, wicket-5933.patch, wicket-touch.zip
>
>
> We run into a disc and cpu bottleneck on a wicket page with 10000+ users, that uses ajax updates via polling (AjaxSelfUpdatingTimerBehavior). 
> The result of our investigation is that page store needs about 10ms for serialization, while the framework serializes the same data again and again. 
> Our application doesn't touch the page, but the AbstractPageManager does: 
> {noformat}
> IManageablePage page = getRequestAdapter().getPage(id); 
> if (page != null) 
> { 
>         getRequestAdapter().touch(page); 
> }
> {noformat}
> Therefore the requested page is always touched, but we couldn't figure out why. If it's possbile not to touch the page here (in some cases) that would solve the problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)