On May 12, 2013, at 1:28 AM, Bill Burke <bburke_at_redhat.com> wrote:
> From the javadoc:
>
> * Called when the invocation was successfully completed. Note that this does
> * not necessarily mean the response has bean fully read, which depends on the
> * parameterized invocation callback response type.
> * <p>
> * Once this invocation callback method returns, the underlying {_at_link javax.ws.rs.core.Response}
> * instance will be automatically closed by the runtime.
> * </p>
> *
> * @param response response data.
> */
> public void completed(RESPONSE response);
>
>
> What does "Note this does not mecessarily mean the response has been fully read."?
E.g. If your callback accepts InputStream or Response, implementations do not need to read the whole response into a buffer before invoking the callback.
>
> One of the TCK tests assumes that completed() is called pretty much immediately after the request is sent over the wire and before even one byte is sent back to the client socket.
Weird. Can you ping us off-line about the details?
> Am I correct in assuming Jersey calls completed() before even a status type is sent back to the client?
No.
> So, if the server side processing of the rqeuest is blocked for any amount of time, completed() will be called pretty much immediately for Jersey?
No.
> The TCK shouldn't assume this behavior. For one, the request certainly isn't completed if a status hasn't been sent back to the client yet.
Let's work offline. I'm getting curious myself.
Marek
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com