[SERVLET_SPEC-41] Clarify the limitations on using the request and response from an application thread Created: 04/Jun/12  Updated: 22/Aug/14

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rstoyanchev Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Section 2.3.3.4 of the Servlet 3.0 spec gives this advice on thread safety with regards to using the request and response objects in an async scenario:

"... they should either only be used within the scope of the request handling thread or the application must ensure that access to the request and response objects are thread safe."

This makes it clear they're not thread safe but also gives the impression that as long as access to these objects is synchronized, they can be used. However, in this servlet-spec user discussion, Greg Wilkins suggests there are a number of request methods that should probably never be used from an async thread including the context path, servlet path, path info, request URI, getting a RequestDispatcher, accessing the session (and possibly others) since their values may change.

Not surprisingly the behavior of Servlet containers varies. The scenario mentioned by Greg actually works in Tomcat and Glassfish potentially leading one to believe it's portable code. Even if one didn't intend on switching containers or didn't care about writing portable code, it's still not clear if the request and response can be used reliably or if they just happen to work in some scenarios.

The spec should make it clear what parts of the request and response should not be used from an application thread in an async scenario.



 Comments   
Comment by gregwilkins [ 06/Jun/12 ]

Note that just because tomcat and glassfish return non null values from these methods does not mean that they are "working".

In an environment where a request can be dispatched to one context, suspended by another context and then handled by yet another context, it is entirely undefined what values should be returned to an asynchronous thread calling any method dependant on the current context.

Jetty does return values to these methods depending on what context they are currently dispatched to, so if an async thread calls these methods before the original dispatch has returned, they will give non null value. If the request is not currently dispatched to a context, then these methods return their initial settings (contextPath==null, servletPath==null, pathInfo==requestedURI).

I think that only the request attributes should be asynchronously accessible (and my preference is to have an accessor method for these on AsyncContext).

Comment by rstoyanchev [ 19/Jul/12 ]

Greg, I am certainly not in a position to say if the values returned from the request in Glassfish and Tomcat after a call to startAsync work in general. On the contrary, I stated it's not clear if the request can be used reliably in that scenario and asked for clarification.

From the point of view of a Servlet API user, there is an AsyncContext and it provides access to the request and response. With no further indication in the spec and the Javadoc, it's not obvious that as many attributes and operations are to be avoided altogether.

I think that only the request attributes should be asynchronously accessible (and my preference is to have an accessor method for these on AsyncContext).

Do I understand correctly all other parts of the request should not be accessible?

Comment by gregwilkins [ 22/Aug/14 ]

definite agree that using the request methods asychronously is not reliable.

I'm not sure that access should be prohibited, but the javadoc should at least point out that the values returned may change (due to dispatches) and that the memory barriers for such changes are undefined.

Generated at Sat Aug 01 02:22:36 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.