Hi Matt,
we disabled async timeout by default.
And thank you for the feedback! :)
Thanks.
WBR,
Alexey.
On 09/04/2012 10:58 AM, Matthew Swift wrote:
> Hi Alexey,
>
> On 3 September 2012 17:34, Oleksiy Stashok <oleksiy.stashok_at_oracle.com
> <mailto: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
>