cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: Jetty Continuations in CXF
Date Fri, 24 Oct 2008 13:46:14 GMT
Btw, is the JMS transport able to not block a thread too ?  Given the
very nature of JMS, this should be even more feasible than for HTTP.

On Fri, Oct 24, 2008 at 3:42 PM, Daniel Kulp <dkulp@apache.org> wrote:
> On Friday 24 October 2008 9:27:01 am Sergey Beryozkin wrote:
>> Dan, here're some comments :
>>
>> 1. "something would need to be done to allow the "suspend" exception thing
>> to propogate up, but without taking a jetty dependency into the core."
>>
>> I guess the basic thing we can do is to check the class name of the
>> exception (like exception.getClass().equals("JettyException")), and if it
>> matches the expected name then we can wrap up this exception in a
>> SuspendedFault exception, to be recognized by the rest of CXF runtime
>
> No.   We don't want that.   Whatever we do should work for other transports as
> well like JMS.  Thus, this shouldn't be tied to jetty continuations directly.
>
> Most likely, we could add a "suspend()" method to PhaseInterceptorChain that
> would do something very similar and throw a "SuspendException" or something
> in the same package as PhaseInterceptorChain.   That would get propogated
> back to the JettyDestination that could then call the jetty things.   The JMS
> transport could just catch it and more or less ignore it.    We'd then have
> to add a "resume()" method to the chain which would call back onto a listener
> that the transport provides.   Jetty would just call the jetty resume stuff.
> JMS would probably put a runnable on the workqueue to restart the chain.
>
> Also, suspend() would need to check if there is a listener.  If not, it should
> not throw the exception.   Thus, the servlet transport and CORBA stuff that
> couldn't do this would pretty much just ignore it.
>
> Basically, this needs to be done in such a way that it CAN work for the
> non-jetty cases.   However, it also needs to be done in a way that doesn't
> affect existing transports.
>
> Dan
>
>>
>> 2. Now, if the above can be figured out, the next problem arises: when
>> the "trigger" to wake up the continuation occurs
>>
>> I think we can can do in JettyDestination omething similar to what is done
>> in SMX. When getting a SuspendedFault exception, we can extract from it the
>> original continuation instance or else we can do
>> ContinuationSupport.getContinuation(request) which should return us the
>> instance. At this point we can use it as a ket to store the current
>> exchange plus all the other info we may need.
>>
>> When the user/application code does continuation.resume(), the Jetty thread
>> will come back and we will use the
>> ContinuationSupport.getContinuation(request) to get us the active
>> continuation and use it to extract the suspended exchange and proceed from
>> there, say we'll call PhaseInterceptorPhase.resume(), etc, something along
>> the lines you suggested
>>
>>
>> 3. 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.
>>
>> Yea - probably can be the quite challenging
>>
>>
>> Thoughts ?
>>
>> Cheers, Sergey
>>
>>
>>
>>
>> [1] http://docs.codehaus.org/display/JETTY/Continuations
>> [2] https://issues.apache.org/jira/browse/CXF-1835
>> [3]
>> https://issues.apache.org/jira/browse/CXF-1835?focusedCommentId=12642361#ac
>>tion_12642361
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message