[jetty-users] Threading model (was Re: Jetty 12 schedule?_

["Cantor, Scott" <cantor.2@xxxxxxx>]

    >    It's a general anti-pattern to hold onto, use, reference a
    > HttpServletRequest or HttpServletResponse object outside of the
    > dispatch from the container.

One more question about this I guess...

Is it fair to assume that the only way a request could possibly cross threads like that is if there's also an actually explicit entry point into one's application logic by which the container is actually invoking a standard interface that is defined to accept the HttpServletRequest/Response?

In other words, I take your point that people can build code that leverages various advanced async/etc. features in the servlet spec, and we don't necessarily know that's happening, but it has to *be* some explicit invocation of a container technology that in turn is going to call back in with the "proper" servlet request/response, right?

Otherwise how could one ever know which instance of the request/response interfaces to act on?

All we do is implement servlets (or make use of them) that accept a servlet dispatch call in and respond out. Nothing else in our design implements any servlet APIs that can accept a request/response in a different way.

So it's difficult to understand how we could possibly be passed in a different instance than the original one the servlet dispatch received since there's nowhere for it to occur.

That's why we've struggled to grasp what the risk is as this has come up at times.

I fully appreciate that you're speaking from a container/generality perspective here and that in the general case what you're saying is obviously true. And yes, it's an anti-pattern because it makes assumptions that aren't generally true. I'm strongly suspecting they are, however, still true for us (and frankly for the vast majority of traditional apps that just implement Servlet).

Basically it feels like for this to break, something has to call an API that also involves passing in a callback interface that itself has to receive the request/response back.

-- Scott