I don't see any problem, other than that users can interact with the page
while the server is still processing the previous request.
Some pages (from co-workers, never my own pages) detach very slowly and
serialize for long due to very large component trees that need to be
processed.
I don't see a way other than letting the requests wait until the detaching
and serializing have been done though.
Martijn
On Wed, Sep 16, 2020 at 4:56 PM Emond Papegaaij <emond.papega...@gmail.com>
wrote:
> Hi all,
>
> After a suggestion in WICKET-6702, I decided to have a look at where
> request processing is blocked from the perspective of the browser. I
> put a breakpoint in JavaSerializer, clicked on a link, and noticed
> that the browser was indeed blocked by my breakpoint. When stepping
> out, the new page was displayed as soon as I hit webResponse.flush()
> in this part in WicketFilter:
>
> if (requestCycle.processRequestAndDetach()) {
> webResponse.flush();
> }
>
> It almost seems too easy to change this to (disregarding the exception
> handling for simplicity):
>
> if (requestCycle.processRequest()) {
> webResponse.flush();
> }
> requestCycle.detach();
>
> I did it nonetheless, and my first smoke tests didn't show any
> problems. The browser is no longer blocked while pages are being
> detached and serialized. Naturally, the request thread is still busy,
> so server resources are not freed earlier. Also, the page lock is
> still held, causing fast subsequent requests to be blocked while the
> first is being finished. But this is as expected. What do you think?
> Can this be changed in Wicket 9 or could this have nasty unforeseen
> consequences? I've created a ticket for this with my experiment on a
> branch:
> https://issues.apache.org/jira/browse/WICKET-6831 . Do note that I did
> not yet update AbstractUpgradeFilter, which should also be done if we
> want to proceed with this.
>
> Best regards,
> Emond
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
