[
https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15829593#comment-15829593
]
manuel barzi commented on WICKET-6177:
--------------------------------------
hi [~mgrigorov]
those waiting times are not for serialisation itself, but for the blocking
queue that temporary catches the page entries as they are requested to be
stored: 30ms timeout when adding an entry into de queue, and 1000ms timeout
when retrieving an entry from the queue. the former is used when requesting an
async store of a page, just to add it to the queue (BlockingQueue.offer(...)),
and the latter is used when retrieving that page entry from the queue
(BlockingQueue.poll(...)) to proceed to serialisation by means of the wrapped
and original sync store.
there is only one worker thread in charge of polling those entries from the
queue and use the original sync page store to serialise the queued pages. this
is where the wrapper async page store decouples the process of serialisation,
calling the original sync page store in that thread.
so there are two sides here: the producing of those page entries in that queue,
and the consuming of them in the worker thread. both operations over the
blocking queue require a timeout to exactly avoid the async page store to be
blocked if the queue cannot respond better than those times.
in case and entry cannot be queued, then the async page store would just
delegate the task to the original sync page store. that is, the async page
store would just work in a sync manner if the timeout is reached. it's like
saying "let's try to save this page asynchronously, but if the queue is
overloaded, then cannot wait for it, let's proceed with the traditional
synchronous page store". that's it.
and in case an entry cannot be un-queued, then the worker thread would just
retry a poll a immediately after, until it finally reaches to retrieve an entry
for synchronously storing it, that is, using the original sync store inside it
to finally serialise the page.
i hope these explanation could provide a more clear picture of the projection,
otherwise let me know, please ,)
> 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)
