On 05/03/2025 19:19, François Rajotte wrote:
Hi Christopher,
Thanks for your comments.
Regarding the behavior of the non-container thread when an async
request gets cancelled, I don't really care exactly how it's handled.
Currently, my strategy is to let it finish if it had already started
processing when the request got cancelled. Or abort processing if the
request got cancelled before processing began.
It's the first case that's giving me headaches.
Using a shared object that handles coordination between the two worlds
certainly makes things clearer from an architectural perspective.
However, I still feel like there's a fundamental issue here, no matter
how the coordination is designed.
When the onComplete signal is received, I feel compelled to NOT return
from the method until I can be certain that my application will no
longer use HTTP request/response objects.
Is that the first indication you have that you need to take action?
The AsyncStateMachine should be taking care of this for you. Provided
that every individual call to ServletOutputStream that performs (or may
perform) any sort of write (print(), write(), flush(), close()) is
proceeded by a call to isReady() that returns true or is in response to
a call to WriteListener.onWritePossible() then by the time onComplete()
is called there shouldn't be anything writing to the response.
There is a similar pattern for request but I'm just focusing on response
for clarity.
If something goes wrong (timeout, client drops the connection etc) then
what should happen is that the write throws an exception or isReady()
returns false, the application stops writing to the response at that
point, Tomcat starts the error handling process and (eventually) the
application sees a call to onComplete().
Async error handling is non-trivial. It is certainly possible that we've
missed some edge cases.
If you have a test case (as simple as possible, ideally in a similar
form to the Tomcat unit tests) that shows some misbehaviour in error
handling we'd be happy to take a look.
The current unit tests may provide some inspiration:
https://github.com/apache/tomcat/blob/main/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.java
Mark
I can forward that signal to
the coordinator, but I must still wait for the "all clear" response.
Otherwise, as soon as the onComplete method returns, the container
tomcat can (and will!) recycle the HTTP request/response objects that
the non-container thread may still be referencing/using.
If the non-container thread isn't trying to write the response out at
that exact moment, then it's a trivial case and I can just discard the
HTTP request/response objects and return immediately.
But if the non-container thread is actively writing the response out,
then I should wait for the non-container thread to complete
processing. The non-container thread may already be executing
tomcat/container code, so aborting it at the application level is
pretty much impossible to do reliably.
Thanks again for your valuable insight,
Regards,
François
On Tue, Mar 4, 2025 at 2:43 PM Christopher Schultz
wrote:
François,
On 3/4/25 10:32 AM, François Rajotte wrote:
Hi,
I'm looking for advice on how to properly synchronize asynchronous
servlets that use the Java servlet 3.0 async APIs.
Especially, I'm trying to avoid having the servlet experience
IllegalStateExceptions when accessing HttpServletRequest and
HttpServletResponse objects that tomcat has recycled.
The theory I'm working with is that:
The servlet is accessing the HttpServletRequest and
HttpServletResponse objects from non-container threads. For example,
we can assume that an asynchronous operation has completed on some
thread and we want to send the response.
At any time, tomcat may decide to "complete" the request and recycle
the HttpRequest and HttpResponse objects. For example, the socket
could be disconnected or timed out. Tomcat notifies the servlet that
this is happening by calling the AsyncListener.onComplete method.
The non-container thread may be accessing the HttpServletRequest and
HttpServletResponse objects while Tomcat is about to recycle the
objects. So it seems that some sort of synchronization is required at
the servlet level to avoid accessing recycled objects.
The strategy I have implemented is to acquire a lock at the servlet
level when processing the AsyncListener.onComplete callback and also
when accessing the HttpServletRequest and HttpServletResponse objects
from non-container threads. That way, we can be sure that the
non-container thread will never access recycled objects.
However, I've noticed that implementing synchronization at the servlet
level introduces deadlocks between application locks and internal
tomcat locks.
This is exactly what I'd expect, given the explanation above.
Be advised, I'm not an expert at servlet async. I'm only looking at this
from an architectural perspective, here.
First, if Tomcat were still "allowed" to
