[jira] [Commented] (WICKET-6177) Blocking page serialization

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ 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)