cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CXF-5417) Support optional JAX-RS 2.0 ConnectionCallback
Date Thu, 16 Jan 2014 12:47:22 GMT

    [ 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)

Mime
View raw message