[
https://issues.apache.org/jira/browse/CXF-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874664#comment-13874664
]
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: 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)
