You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Ron Gavlin (JIRA)" <ji...@apache.org> on 2008/09/30 17:37:46 UTC

[jira] Created: (CXF-1835) Use Jetty Continuations to support an asynchronous HTTP API

Use Jetty Continuations to support an asynchronous HTTP API
-----------------------------------------------------------

                 Key: CXF-1835
                 URL: https://issues.apache.org/jira/browse/CXF-1835
             Project: CXF
          Issue Type: Improvement
          Components: Transports
    Affects Versions: 2.1.2, 2.0.8
            Reporter: Ron Gavlin


Use Jetty Continuations to support an asynchronous HTTP API. See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Beryozkin resolved CXF-1835.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 2.2
                   2.1.4
                   2.0.10

> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>            Assignee: Sergey Beryozkin
>             Fix For: 2.0.10, 2.1.4, 2.2
>
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Ron Gavlin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642347#action_12642347 ] 

Ron Gavlin commented on CXF-1835:
---------------------------------

Would it be appropriate to offer a boolean synchronous flag that is true by default? When set to false, this alternate async behavior would be enabled. 

I agree that CXF should be optimized for the typical use case where low latency is of utmost importance. When CXF is used as a binding component in SMX, the servicemix implementation tends to be an integration process which is longer running. So, allocating one thread per request is not scalable. So, I would think the typical SMX use case would want the synchronous flag set to false. Offering this alternate behavior would seem useful when CXF is used as an SMX JBI Consumer. Does that make sense?

/Ron

> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (CXF-1835) Support asynchronous client using HTTP transport

Posted by "Ron Gavlin (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Gavlin updated CXF-1835:
----------------------------

    Description: CXF client should support asynchronous HTTP transport. See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.  (was: Use Jetty Continuations to support an asynchronous HTTP API. See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.)
        Summary: Support asynchronous client using HTTP transport  (was: Use Jetty Continuations to support an asynchronous HTTP API)

> Support asynchronous client using HTTP transport
> ------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> CXF client should support asynchronous HTTP transport. See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647268#action_12647268 ] 

Sergey Beryozkin commented on CXF-1835:
---------------------------------------

CXF currently can not do non-blocking continuations overt HTTPS.

Ron : is supporting continuations over HTTPS a priority ?



> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Ron Gavlin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642246#action_12642246 ] 

Ron Gavlin commented on CXF-1835:
---------------------------------

Hi Dan,

Take a look at the process() method in http://fisheye6.atlassian.com/browse/~raw,r=702812/servicemix/components/bindings/servicemix-http/trunk/src/main/java/org/apache/servicemix/http/endpoints/HttpConsumerEndpoint.java. This SMX class uses Jetty Continuations to provide async HTTP support. I would think the CXF server code might use a similar technique. 

Let me know what you think.

Regards,

/Ron

> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642438#action_12642438 ] 

Sergey Beryozkin commented on CXF-1835:
---------------------------------------

Hi Ron

So we have this picture

SMX CXF BC <--> CXF runtime <-->  - user code

SMX CXF BC receives the request (on the Jetty thread) and delegates to CXF, cxf invokes the server code.

Where continuation.suspend() will originate from ? From SMX BC ? 


> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Ron Gavlin (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Gavlin updated CXF-1835:
----------------------------

    Description: 
Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.

See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

  was:CXF client should support asynchronous HTTP transport. See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

        Summary: Use Jetty Continuations to implement asynchronous HTTP processing  (was: Support asynchronous client using HTTP transport)

> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642409#action_12642409 ] 

Sergey Beryozkin commented on CXF-1835:
---------------------------------------

Ron, just would like to clarify :

Are you thinking of doing explicit continuations in the application code and expect CXF support handling continuation.suspend() done from the application code ( like Dan described above ) ?

Or you're only after ensuring that when CXF is used as a SMX BC, it releases Jetty threads asap for them to do some other SMX work ? We reckon that it might work (with explicit configuration involved) but as Dan said, it would simply lead to replacing a Jetty thread with an internal CXF thread and thus, as far as the resource consumption is concerned, it's not obvious what will be gained in the end ? 





> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642228#action_12642228 ] 

Daniel Kulp commented on CXF-1835:
----------------------------------


Ron,

Can I get your insight into how you think this should work?   I've been chatting with Sergey a bit this week about this trying to figure out what it would mean to support the continuations and how it would work, where the "create continuation" call would be put, how the resume occurs, etc....   

On the server side, everything is assumed to be completely synchronous.     We take the request, parse to JAXB or other, find the method, call it, take the response and write it back.   This all neatly fits on a single thread.    So, the question is, how is this changed in order for continuations to fit in there and what advantage would it give us?



> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642450#action_12642450 ] 

Freeman Fang commented on CXF-1835:
-----------------------------------

Hi Sergey,

It should be CXF runtime -> SMX BC. Basically, smx bc are sets of cxf interceptors. It receive the request from cxf transport.
After recieve  soap messge  from the cxf http/jms transport, serveral interceptor (also cxf concept interceptor) exist in smx code base transform the soap message to jbi message, and then we have a JbiInvokerInterceptor, which not really do some invocation, but just send the jbi message to the NMR (servicemix Normalized message router). the import code is here
               if (CxfBcConsumer.this.isSynchronous()
                        && !CxfBcConsumer.this.isOneway) {
                    context.getDeliveryChannel().sendSync(exchange,
                            timeout);
                    process(exchange);
                } else {
                     synchronized (CxfBcConsumer.this.messages.get(exchange.getExchangeId())) {
                         context.getDeliveryChannel().send(exchange);
                         CxfBcConsumer.this.messages.get(exchange.getExchangeId()).wait(timeout);
                     }

                }
So you can see if its asynchronous way,  we use context.getDeliveryChannel().send(exchange); this is a nonblock invocation, but after that, currently we have to block here until we get response from the NMR, otherwise the Interceptor chain will return without get correct response. What we actully want is we can suspend the interceptorchain during  waiting response from NMR, and resume the interceptorchain gracefully when the response is arriving. For http transport, the jetty continuation may be a choice, similiar issue should be taken into account when use jms transport. 

Thanks
Freeman

> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Ron Gavlin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647445#action_12647445 ] 

Ron Gavlin commented on CXF-1835:
---------------------------------

Hi Sergey,

Done per your request.

/Ron

> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Ron Gavlin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647307#action_12647307 ] 

Ron Gavlin commented on CXF-1835:
---------------------------------

Hi Sergey,

I am interested in asynchronous server-side processing in general, including the following transports in priority order: jms, http, https. Originally, I referenced the http transport in the title of this JIRA because I assumed the async jms transport was already available. After discovering that was not the case, I wasn't exactly sure how I should proceed. Should this JIRA be re-titled to encompass a generic solution for all transports? Or should I create separate tickets for the jms transport work and the https transport work? What do you think?

/Ron

> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642442#action_12642442 ] 

Sergey Beryozkin commented on CXF-1835:
---------------------------------------

Or is it actually 

CXF runtime -> SMX BC ? If so then I'm starting to understand. So then it would be up to CXF how to handle cont.suspend() along the lines of what Dan said...

> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Ron Gavlin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644270#action_12644270 ] 

Ron Gavlin commented on CXF-1835:
---------------------------------

See nabble thread http://www.nabble.com/Jetty-Continuations-in-CXF-td20150028.html#a20212532 for additional discussion regarding this issue.

> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Ron Gavlin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642434#action_12642434 ] 

Ron Gavlin commented on CXF-1835:
---------------------------------

Hi,

Because the CXF server is inherently synchronous, I think it is only reasonable for the SMX-CXF-BC "JBI Consumer" to function as "application code" in this context. The SMX BC that "wraps" CXF would do explicit continuations and expect CXF to support handling continuation.suspend().

/Ron

> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Beryozkin reassigned CXF-1835:
-------------------------------------

    Assignee: Sergey Beryozkin

> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>            Assignee: Sergey Beryozkin
>             Fix For: 2.0.10, 2.1.4, 2.2
>
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642356#action_12642356 ] 

Daniel Kulp commented on CXF-1835:
----------------------------------


The issue is that I don't see how this would change anything in CXF.   Basically, we would have to create the exchange and put it on our workqueue and create the continuation.   The Jetty thread would be released back to Jetty, but that single request would still consume the workqueue thread.   It doesn't change anything other than moving it from the Jetty thread to a thread on the workqueue.  



> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647317#action_12647317 ] 

Sergey Beryozkin commented on CXF-1835:
---------------------------------------

Hi Ron

I'd prefer going with 3 separate tasks. They might end up being solved in one merge, not sure. Most lilkely http & jms will be tackled in one go and then https one can be handled seperately as the work to be done for https, after the http task has been completed, will have nothing to do with continuations per se but with replacing a SSLSocketChannel and given that https one is the last in the priority queue I guess it can be tackled a bit later.

So may be you can crate a master task, and have this JIRA as the first task, and then create 2 more jiras, one for JMS and one for HTTPS ?

Cheers, Sergey

> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642259#action_12642259 ] 

Daniel Kulp commented on CXF-1835:
----------------------------------

Ron,

Doing it that way is exactly what we DON'T want to do in CXF as it completely breaks streaming.   It works fine for something like ServiceMix as servicemix doesn't make any attempt to stream data, especially on the response side.   It also forces thread context switches for each invokation which is also not something we want the overhead of  95% of the time.



> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-1835) Use Jetty Continuations to implement asynchronous HTTP processing

Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642361#action_12642361 ] 

Daniel Kulp commented on CXF-1835:
----------------------------------

THAT all said, here is something I wrote to Sergey the other day about this:

First, I'd like to know when and how the continuation would be triggered.   
I'm assuming this is something that would be done inside the server skel or 
similar, right?   Basically, their code would start some long running thing 
(like maybe make a async call to another service) and then wants to 
call "suspend" to create the continuation thing, right?

What would happen currently is the suspend causes the exception to be thrown.   
In CXF, that would get wrapped in a fault, sent up to the 
PhaseInterceptorChain where it's caught, and then the fault chain started and 
a soap fault returned.   Obviously not what is wanted here.   Thus, something 
would need to be done to allow the "suspend" exception thing to propogate up, 
but without taking a jetty dependency into the core.

Now, if the above can be figured out, the next problem arises:  when 
the "trigger" to wake up the continuation occurs (like the async response 
comes in), the destination is then called again.   Currently, that would 
setup a new chain, create a new message, re-call the invoke, etc...    Since 
the input stream would have been consumed already, that really won't work.

Basically, as part of the creating the continuation, we would need to "pause" 
the PhaseInterceptorChain and save the message/exchange.   On resume, we need 
to make sure we use the same PIC/message/exchange and kind of pick up where 
we left off.   That's actually not easy either.   In this case, the 
interceptor that would have been currently executing is the 
ServiceInvokerInterceptor which would be calling the Invoker instance.   All 
of those invoker types would need to be updated to handle the "resume" case.    
The JAX-WS invokers are the really tricky ones as they store stuff on the 
stack.   Those would be lost on the exception.   

Basically, to do this "right", we'd need to audit pretty much everything to 
make sure nothing is stored on the stack and is "resumable".   Once that is 
done, the rest is relatively easy.   We can add a listener to the 
PhaseInterceptorChain that would get notified when pause/resume is called.   
In the user code, they would just get the PIC and cause "pause" on it and 
either return or throw and exception or something.  (likely just return null)   
The HTTP transport, when the chain returns, would check if the chain 
was "paused" or "complete".   If "paused", it would register a the listener 
and then do the suspend thing.    When the user wants the resume, they would 
call resume on the PIC which would trigger the listener which would then call 
the resume on the jetty continuation.    The JMS transport and such could 
also be updated to do something smart in the same situation.

The main amount of work is in auditing the entire code path and interceptors 
for stack variables that would need to move into being stored on the message.   
We could easily have a "Message.RESUMED" flag on the message so they could 
determine that later, but they would need to make sure any data they would 
need later is stored on the message and then queryied from there.


> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
>                 Key: CXF-1835
>                 URL: https://issues.apache.org/jira/browse/CXF-1835
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.8, 2.1.2
>            Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing. This is a request to use Jetty Continuations to implement this functionality.
> See https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039 for feedback by Willem Jiang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.