Skip to main content

[JIRA] Commented: (SERVLET_SPEC-41) Clarify the limitations on using the request and response from an application thread

  • From: "gregwilkins (JIRA)" <jira-no-reply@...>
  • To: issues@...
  • Subject: [JIRA] Commented: (SERVLET_SPEC-41) Clarify the limitations on using the request and response from an application thread
  • Date: Wed, 6 Jun 2012 13:21:55 +0000 (GMT+00:00)
  • Auto-submitted: auto-generated


    [ 
http://java.net/jira/browse/SERVLET_SPEC-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340985#action_340985
 ] 

gregwilkins commented on SERVLET_SPEC-41:
-----------------------------------------

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).


> Clarify the limitations on using the request and response from an 
> application thread
> ------------------------------------------------------------------------------------
>
>                 Key: SERVLET_SPEC-41
>                 URL: http://java.net/jira/browse/SERVLET_SPEC-41
>             Project: servlet-spec
>          Issue Type: Bug
>            Reporter: rstoyanchev
>
> {{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|http://java.net/projects/servlet-spec/lists/users/archive/2012-05/message/10],
>  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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[JIRA] Created: (SERVLET_SPEC-41) Clarify the limitations on using the request and response from an application thread

rstoyanchev (JIRA) 06/04/2012

[JIRA] Commented: (SERVLET_SPEC-41) Clarify the limitations on using the request and response from an application thread

gregwilkins (JIRA) 06/06/2012
 
 
Close
loading
Please Confirm
Close