Hi Matt,
sorry for possible delays, the mailing list didn't work for the last
couple of days...
On 10/05/2012 07:26 PM, Matthew Swift wrote:
> I've been thinking about this some more... thoughts below:
>
> On 5 October 2012 18:19, Matthew Swift <matthew.swift_at_gmail.com
> <mailto:matthew.swift_at_gmail.com>> wrote:
>
> [...]
>
> The call to resp.isCommitted() is the one triggering the
> exception, which seems a little harsh! How can it ever return true
> since, when a response is committed, I get an exception instead?
>
>
> This has to be a bug, I'm pretty sure of that. There's no point in
> having the method if it's going to never return true. Let me know if
> you agree, and I'll raise an issue in JIRA for it.
Is it easy to reproduce this issue?
Response.isCommited() has to return true, if response headers have been
sent to a client; or false otherwise.
The exception you reported might occur when you call isCommited after
response has been resumed, is it the case?
We can definitely implement a switch to allow/disallow Request/Response
recycling, it shouldn't be a problem at all... it may have some perf.
impact, cause Request/Response objects are relatively expensive, but we
can definitely try and double check that.
> At the moment I'm having to be really careful about how I use
> these APIs. In particular, I have to be super careful not to try
> and accidentally complete a response more than once (the sort of
> thing that is pretty easy to do when unrolling the stack through
> try...finally blocks. In addition, I've had to be really careful
> to avoid accidentally closing the response's output stream after
> the response has completed since this causes an NPE (remembering
> that the stream may be closed automatically by other wrapper
> layers like Jackson). In fact I would go say this is definitely a
> bug - close() is usually idempotent and robust against multiple
> invocations.
>
>
> Regardless of what you guys do to make Grizzly servlet support more
> forgiving, I still need to code as defensively as possible because
> other containers may not be as forgiving. It's a shame that the
> Servlet API spec is, from what I have seen, poorly defined in this
> respect - the only hint I've seen in the Servlet javadoc which
> indicates they you can only complete a response once is in the doc for
> sendError.
Yes, sendError is designed like that and you're properly trying to check
the status using isCommited.
Thanks.
WBR,
Alexey.
>
> Matt
>