Hi Alexey,
On 3 September 2012 17:34, Oleksiy Stashok <oleksiy.stashok_at_oracle.com>wrote:
> Hi Matt,
>
>
> On 09/03/2012 04:02 PM, Matthew Swift wrote:
>
> I've just added a comment as well based on my interpretation of the 3.0
> Servlet spec. It looks like Grizzly is behaving according to the spec, but
> I fail to see how I, as a user of the servlet API, can reliably avoid
> "non-deterministic behavior" as a result of request/response recycling
> since timeouts always cause the request to be completed. Honestly, unless
> I'm missing something (which wouldn't be the first time ;-)), I suspect
> that the Servlet API is broken w.r.t timeouts. What do you think?
>
> I have to agree w/ you, timeout logic is not defined well, and I'm not
> even sure if it can be :(
>
> The problem is caused by fact, that once you initiate asynchronous
> Request/Response processing - it becomes your responsibility to complete
> async processing properly.
>
Right, and if it is my responsibility to complete async processing
properly, then it should *not* be the responsibility of the container to
blow away the request/response objects that I am using. It should be my
responsibility to handle the notification and then tell the container when
I have completed (usually asynchronously w.r.t. the async context
listener). As it stands, I have to take the rather onerous approach you
describe in (2) below - synchronize every call to methods in
HttpServletRequest.* and HttpServletResponse.* as well as the async context
listener. This is even more frustrating because the extra synchronization
is redundant in the case where the container doesn't support asynchronous
processing (e.g. Servlet 2.5).
Oh well. There's obviously not much point in moaning since this is all part
of the Servlet spec and nothing to do with Grizzly :-)
> "Timeout" notifications are coming from container asynchronously, at that
> time container doesn't have any idea about the Request/Response processing
> state (because now you're responsible for them :)), that's why all these
> collisions may occur, when you try to complete async Request/Response
> processing and timeout notification comes...
>
>
Agreed.
> What I can suggest is:
>
> 1) We can change the default timeout value in Grizzly servlet container to
> become NEVER_TIMEOUT instead of 30s, so timeout and processing collision
> will not occur unexpectedly.
>
I have done this anyway from within the Servlet using
AsyncContext.setTimeout() as a temporary workaround. If Servlet 3.0 does
not recommend a default timeout then it might be a good idea disable the
timeout mechanism by default. Then again, disabling it by default makes it
less likely that Servlet developers will test the code against timeouts
(like I did inadvertently!).
> 2) You can register timeout listener and synchronize it w/ asynchronous
> request/response processing logic. It might be a proper fix from servlet
> spec. point of view, but I have to check if existing implementation will
> handle this properly.
>
>
This is the only solution I could think of as well. The existing Grizzly
code does seem to handle this properly as far as I can see.
Cheers and thanks for your help,
Matt