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:59:26 GMT
On Friday 24 October 2008 9:46:14 am Guillaume Nodet wrote:
> Btw, is the JMS transport able to not block a thread too ?  

With my commits last week, it can on the client side.   Not on the server side 
though.

> Given the 
> very nature of JMS, this should be even more feasible than for HTTP.

Right.  Which is why I want the API's for this to not be specific to Jetty.

Dan


> 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



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message