It seems this issue has been discussed 7 years ago:
http://markmail.org/message/y5gfntpzqesavyif
On Wed, Sep 16, 2020 at 6:53 PM Martijn Dashorst <martijn.dasho...@gmail.com>
wrote:
> 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
>
