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 <mgrigo...@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 <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 > >
