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] [Commented] (CXF-5417) Support optional JAX-RS 2.0 ConnectionCallback
Date Mon, 13 Jan 2014 12:25:51 GMT

    [ https://issues.apache.org/jira/browse/CXF-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13869449#comment-13869449
] 

Sergey Beryozkin commented on CXF-5417:
---------------------------------------

Hi Andriy

Thanks for your analysis, it's been helpful. I've checked some resources as well.

I think the obvious fact is that people who would like to write effective asynchronous applications
are keen to ensure the thread doing some work for the already disconnected client does not
spend another 1/5/etc seconds - especially if a lot of clients are there and the percentage
of the disconnected ones is bigger.

I can see the people go at some length to write the code doing the heart-beat messages with
keep-alive, etc, as in
http://stackoverflow.com/questions/12085235/servlet-3-async-context-how-to-do-asynchronous-writes

So the good thing about ConnectionCallback is that JAX-RS 2.0 developers will register it
and that is it, CXF will do the rest, the solution can not be perfect, and may be not guaranteed
to work 100%, I agree :-), but I think in case of CXF it should be straightforward to implement.
This would also be of help to users working directly with the CXF Continuations API.
 
The other thing is that implementing it would help to keep some users with CXF JAX-RS. The
way it often works, due to the fact we have 3+ JAX-RS implementations, is that users can migrate
to the implementation where a given feature is available - so if we have CXF JAX-RS devs doing
a pure portable async code and keen to optimize then they can be tempted to migrate, so in
the end it is in our interests to implement it.

I'd like to propose to start with Servlet3Continuation.class, I can then do the same with
JettyContinuationWrapper and we can ignore JMSContinuation. So:

1. Add CXF ConnectionCallback interface - will be the same as JAX-RS one, single method only.
2. in Servlet3Continuation constructor:
{code:java}
private ConnectionCallback connectionCallback;
private Timer timer;
// constructor:
connectionCallback = message.getExchange().get(ConnectionCallback.class);
if (connectionCallback != null) {
    // init timer and start a basic timer task which will send a keep-alive say every 0.5
sec (we can later configure this timeout)
    // and callback into connectionCallback in case of IO exception; all of it can be done
if the continuation has not been reset/completed, i.e, if AsyncResponse is not null
}
{code} 
3. Servlet3Continuation.reset method will stop the timer if it is not null 

IMHO it is worth doing it. I'm happy to continue from here but may be you'd like to try it
? We can test it with deploying a basic JAX-RS 2.0 application to Tomcat where AsyncResponse
is saved into some map and then it is removed on a client disconnect. I think I have an existing
test project somewhere I can update it and attach it here

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