cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <>
Subject [jira] [Commented] (CXF-5417) Support optional JAX-RS 2.0 ConnectionCallback
Date Fri, 17 Jan 2014 11:08:19 GMT


Sergey Beryozkin commented on CXF-5417:

Hi Andriy

It is a very good progress, confirming that both containers can actually report back an error.

That said, it does appear to me that we can't avoid requiring a client to support a decoupled
channel for the idea of the keep-alive pings to actually work. As such I would like to propose
to temp stop pursuing this idea, I'd like to experiment later on with what realistically can
be done at WebClient or HttpConduit level. I think that if we actually managed to report more
or less immediately about the dis-connected clients then it would be a worthy feature, but
it all seems a bit too complex for the kind of a problem that is being addressed. 

What I'd like to propose is to get some basic support for it, i.e, callback in case of IO
exceptions at the time of the actual write to the client. I guess that would be similar to
what Jersey does with it, but also prepare some base for the possible support of the keep-alive
pings later on. It will likely do well for CXF Continuations anyway: right now, every Continuation
instance is reset() in case of the data being returned successfully, but if we have a disconnected
client case then the Continuation will not be reset.

As such I'd like to propose:
1. Make sure Continuation is aware that a failure at write time has occurred. Right now, AbstractHttpDestination
has invokeComplete method which invokes on ContinuationProvider but it is not called in cases
of exceptions, I guess a Fault handler will also need to call it  in case of unchecked exceptions.

2 Not sure though how to make an actual exception available to ContinuationProvider. Its complete()
method is new and is unlikely to be used by any of the application code, so we can update
it to "complete(Throwable)", and we can also update Continuation.reset() to Continuation.reset(Throwable)
or add a new method, but I don't think any of the application code uses Continuation.reset
- that can be a 3.0 Migration issue if needed.

Dan - does updating ContinuationProvider.complete() and Continuation.reset() signatures sounds
reasonable ?

3. Next Servlet3Continuation will reset itself, then check if it is IOException (where a container
specific exception name introduced as a message contextual property is used to check if it
is a disconnect related error) and if we have a callback registered then call on it. 

However before doing 2 and 3, can you please try 1. only (make sure AbstractHttpDestination.invoke()
Fault handler also calls on invokeComplete() when the server fails to write a proper response
) and check if "Servlet3Continuation.onError(AsyncEvent event);" is called after a client
disconnect ? That would be the simplest solution really

Thanks, Sergey 


> Support optional JAX-RS 2.0 ConnectionCallback
> ----------------------------------------------
>                 Key: CXF-5417
>                 URL:
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-RS, Transports
>            Reporter: Sergey Beryozkin
>            Priority: Minor
> 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

View raw message