cxf-issues mailing list archives

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

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

Andriy Redko edited comment on CXF-5417 at 1/16/14 1:52 AM:
------------------------------------------------------------

Hi Sergey

I have very interesting (but discouraging) results to share. The experiment I have done is
dirty and quick change in Servlet3ContinuationProvider to understand how far we can go. It's
the very same approach you mentioned in the previous comment and takes place in Servlet3Continuation
class:
{code:java}
executorService.schedule( new Runnable() {                
                @Override
                public void run() {
                    try {
                        if( isPending ) {
                            context.getResponse().getOutputStream().println();
                            context.getResponse().getOutputStream().flush();
                        }
                    } catch( IOException ex ) {
                        ex.printStackTrace();
                    }
                }
            }, 5, TimeUnit.SECONDS );
{code}

Surprisingly, I have never received an exception knowing for sure client disconnects abruptly
(but the code is called and works for sure, I can see newlines in responses). Reason - class
org.eclipse.jetty.server.HttpOutput. It turns out, not always IOException(s) are allowed to
escape it. Specifically, as I understood, when disconnect/abort is being detected, it triggers
the sequence (from write / flush) to close the socket and the last call in this sequence is
HttpOutput.close() method: it consumes an exception without re-throwing it.

Not sure we can make ConnectionCallback feature working without looking deeply into Jetty
internals. 
What do you think?

Thanks.
Andriy


was (Author: reta):
Hi Sergey

I have very interesting (but discouraging) results to share. The experiment I have done is
dirty and quick change in Servlet3ContinuationProvider to understand how far we can go. It's
the very same approach you mentioned in the previous comment and takes place in Servlet3Continuation
class:
{code:java}
executorService.schedule( new Runnable() {                
                @Override
                public void run() {
                    try {
                        if( isPending ) {
                            context.getResponse().getOutputStream().println();
                            context.getResponse().getOutputStream().flush();
                        }
                    } catch( IOException ex ) {
                        ex.printStackTrace();
                    }
                }
            }, 5, TimeUnit.SECONDS );
{code:java}

Surprisingly, I have never received an exception knowing for sure client disconnects abruptly
(but the code is called and works for sure, I can see newlines in responses). Reason - class
org.eclipse.jetty.server.HttpOutput. It turns out, not always IOException(s) are allowed to
escape it. Specifically, as I understood, when disconnect/abort is being detected, it triggers
the sequence (from write / flush) to close the socket and the last call in this sequence is
HttpOutput.close() method: it consumes an exception without re-throwing it.

Not sure we can make ConnectionCallback feature working without looking deeply into Jetty
internals. 
What do you think?

Thanks.
Andriy

> 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