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
