You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2017/11/16 15:58:05 UTC
[Bug 61768] New: Processor for async requests are recycled before
complete is called on AsyncContext
https://bz.apache.org/bugzilla/show_bug.cgi?id=61768
Bug ID: 61768
Summary: Processor for async requests are recycled before
complete is called on AsyncContext
Product: Tomcat 8
Version: 8.5.20
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: herbert.wespi@swisscom.com
Target Milestone: ----
Our Product offers different REST APIs based on jax-rs 2.1 and Jersey 2.26.
We are facing Problems with asynchronous Requests (using
javax.ws.rs.sse.SseEventSink) and the Recycling of Processors
(org.apache.coyote.http11.Http11Processor).
The SSE Endpoints are asynchronous and kept open for a long time.
If the async Context is completed on Server Side, then it works as expected.
But when a Client closes the Connection on Client Side, then the Processor is
recycled and put to the recycled Processors:
org.apache.coyote.AbstractProtocol.ConnectionHandler.release
The asynchronous Thread is still running and will try to write to the Response.
Because the processor (incl. request and Response object) is recycled it will
be reused by another request (synchron or asynchron).
Jersey itself uses the javax.servlet.AsyncContext only to complete once it is
finished, but it does NOT use the getResponse Method. Instead the original
Response is used. This leads to a concurrent use of the very same Response.
We observed different failures because of this (Empty or truncated Responses or
missing reponse headers)
As a Workaround we had to disable the processor pool in the connector:
processorCache="0"
With this Workaround the Problem is not happening anymore.
The proposed fix would be to release asynchronous processors only back to the
poll if they asynchronous processing is completed.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 61768] Processor for async requests are recycled before
complete is called on AsyncContext
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61768
--- Comment #4 from Herbert Wespi <he...@swisscom.com> ---
Thanks Mark for the clarification. I see your point. Jersey does not register
any listener to AsyncContext. I will try to adress it then with the Jersey
Project.
As an application developers, it would be nice if the two reference
implementations (servlet and jax-rs) would just work well together out of the
box ;-)
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 61768] Processor for async requests are recycled before
complete is called on AsyncContext
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61768
--- Comment #3 from Mark Thomas <ma...@apache.org> ---
(In reply to Herbert Wespi from comment #2)
> ... then the request object
> remains valid until complete method on AsyncContext is called. ...
complete is called when the I/O error occurs. If the app/framework doesn't call
it during error handling that is a further error and the container will ensure
complete is called.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 61768] Processor for async requests are recycled before
complete is called on AsyncContext
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61768
--- Comment #2 from Herbert Wespi <he...@swisscom.com> ---
I do have a different point of view here.
I also thought in the beginning, that it is the fault of the Jersey Framework,
because if I would implement an asynchronous request myself, it would be easy
to get it work for tomcat.
However, if I read corretly the chapter 5.6 of the Servlet 3.0 Specification,
then it looks like that the application/Framework is allowed to use the
response object as long as complete on AsyncContext is not called.
5.6 Lifetime of the Response Object
Each response object is valid only within the scope of a servlet’s service
method,
or within the scope of a filter’s doFilter method, unless the associated
request
object has asynchronous processing enabled for the component. If asynchronous
processing on the associated request is started, then the request object
remains valid
until complete method on AsyncContext is called. Containers commonly recycle
response objects in order to avoid the performance overhead of response object
creation. The developer must be aware that maintaining references to response
objects for which startAsync on the corresponding request has not been called,
outside the scope described above may lead to non-deterministic behavior.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 61768] Processor for async requests are recycled before
complete is called on AsyncContext
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61768
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
The first time an attempt is made to perform I/O after the client disconnects
then the following will happen:
- The code attempting to perform the I/O will see an I/O exception
If one or more AsyncListeners are configured:
- Tomcat will call the onError event for any registered AsyncListeners.
It is expected that one of those listeners will complete the AsycnContext.
If no listeners are configured:
- Tomcat will complete the AsyncContext
Tomcat will then go on to recycle the various objects used for the request
since processing of that request is now complete.
If the application/framework needs to perform clean-up if an error occurs then
it is the responsibility of the application/framework to register the
appropriate listener(s) and perform that clean-up in response to an error.
If there is a scenario where an I/O error occurs and Tomcat does not trigger
the async error handling then that would be a Tomcat bug. However, that is not
the case here. That the processor has been recycled means that Tomcat has
triggered the async error handling.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org