[
https://issues.apache.org/jira/browse/CXF-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13873325#comment-13873325
]
Sergey Beryozkin edited comment on CXF-5417 at 1/16/14 12:47 PM:
-----------------------------------------------------------------
Hi Andriy
I've checked Jersey docs, here is what I've found:
"As some async requests may take long time to process the client may decide to
terminate it's connection
to the server (1) *before the response has been resumed* or (2) *before it has
been fully written to the client*. To deal
with these use cases a ConnectionCallback can be used. This callback will be
executed only if the
connection was prematurely terminated or lost *while the response is being
written to the back client.*"
(1) & (2) are added by me. It is a bit of a surprise to me as I'm not sure what
is the practical point of it, given that the callback is activated as per the
text above only when the data are actually being written back. Dealing with (1)
would be the main reason why the callback can be used, for (2) - not much point
really but may be some applications would need to know if the response was
delivered...
So yeah, lets try Tomcat first - if that works then we can say our *real*
client-disconnect support works on Tomcat only;
And then I can also play a bit later with the idea of adding the keep alive
pings to the client-server exchange and get it supported in CXF,
Cheers, Sergey
was (Author: sergey_beryozkin):
Hi Andriy
I've checked Jersey docs, here is what I've found:
"As some async requests may take long time to process the client may decide to
terminate it's connection
to the server (1) *before the response has been resumed* or (2) *before it has
been fully written to the client*. To deal
with these use cases a ConnectionCallback can be used. This callback will be
executed only if the
connection was prematurely terminated or lost *while the response is being
written to the back client.*"
(1) & (2) are added by me. It is a bit of a surprise to me as I'm not sure what
is the practical point of it, given that the callback is activated as per the
text above only when the data are actually written back. Dealing (1) would be
the main reason why the callback can be used, for (2) - not much point really
but may be some applications would need to know if the response was delivered...
So yeah, lets try Tomcat first - if that works then we can say our *real*
client-disconnect support works on Tomcat only;
And then I can also play a bit later with the idea of adding the keep alive
pings to the client-server exchange and get it supported in CXF,
Cheers, Sergey
> Support optional JAX-RS 2.0 ConnectionCallback
> ----------------------------------------------
>
> Key: CXF-5417
> URL: https://issues.apache.org/jira/browse/CXF-5417
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS, Transports
> Reporter: Sergey Beryozkin
> Priority: Minor
>
> https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/container/ConnectionCallback.html
> lets JAX-RS 2.0 applications receive the notifications when a given client
> has disconnected.
> We can probably build something on top of the Jetty-specific connector and
> also enhance CXF Continuation API.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
