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. "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...
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.
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.
Thanks.
WBR,
Alexey.
>
> Matt
>
>
> On 3 September 2012 10:51, Matthew Swift <matthew.swift_at_gmail.com
> <mailto:matthew.swift_at_gmail.com>> wrote:
>
>
>
> On 31 August 2012 22:36, Ryan Lubke <ryan.lubke_at_oracle.com
> <mailto:ryan.lubke_at_oracle.com>> wrote:
>
>
> We'll need to look into this for sure. Would you mind logging
> an issue to keep track of this one?
>
>
>
> No problem. Here it is: http://java.net/jira/browse/GRIZZLY-1325
>
> Matt
>
>