cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Jetty Continuations in CXF
Date Fri, 24 Oct 2008 13:42:41 GMT
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

Mime
View raw message