[
https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15862618#comment-15862618
]
ASF GitHub Bot commented on WICKET-6177:
----------------------------------------
GitHub user manuelbarzi opened a pull request:
https://github.com/apache/wicket/pull/212
WICKET-6177 Blocking page serialization
from https://issues.apache.org/jira/browse/WICKET-6177
**AsyncPageStore** adds the capability to provide an asynchronous page
storing by wrapping the original sync page store (e.g. DefaultPageStore) and
handling store requests in a queue and storing pages in worker thread which
makes use of the original store. The number of pages to be managed
asynchronously is defined by a capacity, provided by estimation which should be
done on each specific application where applied.
The aim of AsyncPageStore is to unblock page requests when serialization
process takes 'too long', giving the user the sensation of 'slow web'. This
could happen in applications that for any reason delay on backing up pages by
means of the current default wicket store.
It adds the chance to manage a preset number of pages asynchronously,
defined by the 'capacity', and in case that limit is exceeded by requests, it
just works as the original sync page store, by simply delegating work on it
until the queue is released and space is done to handle pages in asynchronous
way again.
It acts in a way like saying "let's handle storing of pages asynchronously
for an estimated number of them in 'normal conditions', and in case there is an
excess of pages to store (peak of requests), that is, exceeding async store
'capacity', then let's just work as normally.
**AsyncPageStoreTest** provides initial on/off cases with the scenarios in
which async page store works in 'normal conditions' (not exceeding capacity),
and the opposite (arriving at a point of exceeding that capacity).
original code is already 'gutted' in a **quickstart** for inspection and
testing in https://github.com/manuelbarzi/wicket-async-page-store
for further details on this projection, just following the first link above.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/manuelbarzi/wicket master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/wicket/pull/212.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #212
----
commit 2ffd587dea4c5e1edec0853f35a9b5761e391917
Author: manuelbarzi <[email protected]>
Date: 2017-02-12T01:23:40Z
WICKET-6177 Blocking page serialization
----
> Blocking page serialization
> ---------------------------
>
> Key: WICKET-6177
> URL: https://issues.apache.org/jira/browse/WICKET-6177
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 7.4.0
> Environment: any
> Reporter: Martin Makundi
> Labels: serialization
> Attachments: 6177.tgz, Wicket_Quickstart_7.zip
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> We have a performance issue with our Wicket app, page serialization causes
> inconvenience to user because PageStoreManager.storeTouchedPages() blocks the
> request until pageSerializer.serialize(page) has been handled.
> Could this be solved by serializing the page in a separate thread and let the
> request complete?
> The problem we have is that user is making quick small ajax modifications to
> the page but serialization + network latency makes the delay very
> inconvenient. If serialization could be done in separate thread, user would
> feel only the network delay which is bearable.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
