[
https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15630982#comment-15630982
]
manuel barzi commented on WICKET-6177:
--------------------------------------
hi guys,
i've been reviewing this issue a bit and i find out that there is already a
good async impl for data storage, in which the default construction (by
default-page-manager-provider) wraps the (sync)-disk-data-store with
async-data-store. this last already works with concurrency on data storing,
managing entries tracked by session-id and page-id.
my projection is: ok, why not applying the same strategy on page-store. keeping
the current (sync)-defaul-page-store being wrapped by an async-page-store
managing concurrency in a similar way to what async-data-store already does.
just my first thoughts i wanted to share with you, an open to discussion if you
feel like to share too.
> 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.4#6332)
