[
https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15927861#comment-15927861
]
ASF GitHub Bot commented on WICKET-6177:
----------------------------------------
Github user 1nside0ut commented on the issue:
https://github.com/apache/wicket/pull/212
hi @mmakundi
"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));
}"
entryMap is not supposed to be used as "backup mem", there's already one
queue for that (entries). it's not by mistake that map-removal is located
before synchronous store call for the same thread (not the worker). the reason
is simple: if before try-to-queue a page fails, or it simply takes to long
(offer), then that would mean app mem / process is in trouble, "no space /
speed for that", so there's not point on keeping that ref attached to map
(occupying) while synchronous storing ("slow" storing, as you say) if it has
already been stated a fail on trying to manage it in queue (mem). using map as
"a backup for when queuing fails" would just false the mechanism, imposing a
mem kept at a non-optimal point for that.
on the other hand, regarding the worker thread that "asynchronously" stores
the page, the case is the opposite. every single page that has achieved to
enter the queue before (that is, offer succeeded), has already got the
privilege to being kept in mem while not being entirely stored, so being
removed from map after that.
queue protects itself from accepting or not new entries depending on env
conditions, but outside it logic should act in coherence to it.
> 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)
