jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: Subject: [81-ClarifyThreadRequirementsOnInit] DISCUSSION

From: Stuart Douglas <sdouglas_at_redhat.com>
Date: Wed, 22 Mar 2017 09:11:04 +1100

I think we should go with Option Container, it would very much
surprise me if any containers did not already do this.

In practice the code that stops service() being called before init()
is complete should be a sufficient memory barrier to make sure that
the changes in init() are visible. Off the top of my head I can't
think of a way to implement this such that the changes are not
guaranteed to be visible without also opening up the possibility of
init() and service() being active at the same time.

Stuart

On Wed, Mar 22, 2017 at 8:32 AM, Edward Burns <edward.burns_at_oracle.com> wrote:
> Hello Volunteers,
>
> Background
> ==========
>
> This old issues is in our list of low hanging fruit so I thought I'd try
> to resolve it. The reporter factually points out that the current
> specification for Servlet#init() says nothing about "visibility" as
> discussed in section 17.4.5 of the JLS. The reporter requests we say
> something here.
>
> Consider this code:
>
> public class MyServlet extends Servlet {
> ServletConfig config = null;
>
> public void init(ServletConfig config) {
> this.config = config;
> }
>
> public void doGet() {
> // do something with config.
> }
> }
>
> Lots of code out there does this, but the fact that it works is a bit
> sketchy.
>
> This issue is asking for clarification of the safety of doing the above.
> We have three options, none of them very appealing.
>
> Option WONTFIX:
>
> We simply punt on this issue and mark it as WONTFIX.
>
> Option ServletAuthor:
>
> I propose we take the easy way out here and add the following text to
> Servlet#init():
>
> Note that containers are not obligated to invoke the Servlet#init()
> method on the same thread that may be used for any subsequent
> invocations of request handling methods on the same Servlet. Therefore,
> care must be taken to ensure the proper visibility expectations are
> maintained. The results are unspecified if these measures are not taken.
>
> And the following sentence after the sentence in 2.3.3.1. New text in
> **.
>
> 2.3.3.1 Multithreading Issues
>
> A servlet container may send concurrent requests through the service
> method of the servlet. To handle the requests, the Servlet Developer
> must make adequate provisions for concurrent processing with multiple
> threads in the service method. **The Servlet Developer must also make
> adequate provisions for the visibility, in the service() method of
> data passed to Servlet.init(), per the Java Memory Model.**
>
> Option Container:
>
> We modify the spec to require the container to ensure the visibility
> requirements are met.
>
> I propose we take the easy way out here and add the following text to
> Servlet#init():
>
> Containers must ensure that the ServletConfig object passed to
> Servlet.init() is visible, per the Java Memory Model, to the service
> method (and any convenience methods thereof).
>
> ACTION: Please weigh in on this by close of business Friday 24 March
> 2017. In the absence of any discussion, we'll go with option
> ServletAuthor.
>
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 5 business days until JavaLand 2017
> | 23 business days until planned start of Servlet 4.0 Public Review