You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Emond Papegaaij <em...@gmail.com> on 2020/09/16 14:56:19 UTC
Flush request before detach
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
Re: Flush request before detach
Posted by Emond Papegaaij <em...@gmail.com>.
Indeed, I still remembered that Martijn was working on this years ago,
but he didn't remember anymore :)
It seems we didn't come to a real conclusion back then. I did not
notice the problems Martijn had with the client waiting for the
connection to be closed. Chrome immediately displayed the new page
right after flush. I tested mostly with bookmarkable links to stateful
pages, so a click would lead to 2 requests: render page to buffer ->
redirect -> fetch result. I had a breakpoint in the serializer, to
keep the first request open indefinitely, and was able to navigate
through our application.
Next week I want to give it some more testing, to see how well it
works in our application when put under stress.
Best regards,
Emond
On Fri, Sep 18, 2020 at 12:27 PM Martin Grigorov <mg...@apache.org> wrote:
>
> 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 <ma...@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.papegaaij@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
> >
Re: Flush request before detach
Posted by Martin Grigorov <mg...@apache.org>.
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 <ma...@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.papegaaij@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
>
Re: Flush request before detach
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <em...@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