[
https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873999#comment-15873999
]
ASF GitHub Bot commented on WICKET-6177:
----------------------------------------
Github user mmakundi commented on the issue:
https://github.com/apache/wicket/pull/212
Thanks @manuelbarzi and Some findings:
1. I would remove the (non-Javadoc) and instead format those with
start-prefix /** like true javadoc and remove extra empty lines in the javadoc
2. All in all check for formatting and extra lines etc.
3. In case entries.offer fails, entryMap.remove is called before
pageStore.storePage. If we assume pageStore.storePage is slow, maybe it would
be good idea to postpone remove so that a new requiest during
pageStore.storePage can use the in-memory reference? Similar to what is
happening in PageSavingRunnable.run? Also this will make a great re-usable
method:
storePageAndRemoveFromMap(...) {
log.debug("Saving asynchronously: {}...", entry);
pageStore.storePage(sessionId, page);
entryMap.remove(getKey(entry));
}
4. Same as in (3.) to catch (InterruptedException e) {
log.error(e.getMessage(), e);; storePageAndRemoveFromMap(...); }
5. Please junit-test if any conflict occur if unbind(sessionId) is called
while there are entries in the queue for that session.
6. Please add tests also for borderline racing cases such as same instance
is returned for new request arriving before storing is complete.
7. I would rename AsyncPageStore -> AsynchronousPageStore for clarity and
symmetry (symmetric naming with AsynchronousDataStore),
8. Please propose a patch also into DefaultPageManagerProvider such that
new AsyncPageStore(super.newPageStore(dataStore), 100); would be the default
pagestore for wicket when dataStore.canBeAsynchronous()==true. Similar way that
AsynchronousDataStore is default.
> 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)
