If the servlet 3.1 async WriteListener is registered on the correct context but on a container thread other than the one that spanwed the request (or maybe even if on same thread but after context.end is called), then WriteListener#onWritePossible is never called. This was originally reported https://www.mail-archive.com/users@tomcat.apache.org/msg124043.html and repeated asked again by me at https://mail.google.com/mail/u/0/#inbox/KtbxLxGcBcrfltMWNvZcJHFJLdbkfFWJdq. Our scenario involves RestEasy and many layers, but we're 99% sure we are experiencing the same issue Violeta reported. From what I can tell her test is also a pretty good reproducer. I could make a few tweaks, but if it's good enough, I don't want to change it.
Violeta's test can be found at https://github.com/apache/tomcat/blob/714236af3458f030ec598660fa5fa886cd63dbd0/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java#L934
This is caused by the fact that the logic identifies this as a container thread, which is not enough in that edge case. Basically there is a need to dispatch if the thread is not the original request thread, which is now hard to identify (I cannot immediately think of a good way) and I don't think this is going to be fixed. If this wontfix resolution is validated, then the issue will be documented in the known issues (it pretty much has been for the past 6 years as the test case was there and ignored).
Created attachment 38138 [details] Patch The idea is to try to identify the original processing thread better. Unless I missed something, this is only useful for the Servlet container.
Hi Remy, I am currently working on a workaround in our code, but I don't want to continue that if a fix is near. Honestly, I was curious if you could do something like you are proposing here, but I simply don't know enough about the codebase to know if you truly needed to be off a container thread (as opposed to just the originating thread). Regardless, where do you stand on adding this to the 9.0.x (and other) branches? Any take on when a 9.0.x release could happen with this fix? Many thanks for working on this!
Once reviewed and validated (if needed), a fix like this one is almost always applied to all branches.
Hey Remy. Thanks. No pressure or anything, just curious if you have _any_ idea on when this could be released. Based on your release notes, it looks like you tend to cut a release every month. Do you see big hurdles for this hitting the next release? Is there any way we can help with those hurdles? Of course, we can run our battery of tests, but I'm not sure how much confidence that would give you on this relatively core change.
(In reply to Remy Maucherat from comment #5) > Once reviewed and validated (if needed), a fix like this one is almost > always applied to all branches. LGTM. My only thought is how many of the other container thread checks really should be converted to this new request thread check.
(In reply to Mark Thomas from comment #7) > (In reply to Remy Maucherat from comment #5) > > Once reviewed and validated (if needed), a fix like this one is almost > > always applied to all branches. > > LGTM. > > My only thought is how many of the other container thread checks really > should be converted to this new request thread check. Not sure. When upgrading, there's no async context, so the calls there should be ok. Not certain about the async state machine used through the Servlet container. The scenario from the test is clearly the most common use (and I don't consider it to be a great idea ;) ).
The fix will be in 10.1.0-M9, 10.0.15, 9.0.57 and 8.5.74.
Thanks!