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 <[EMAIL PROTECTED]> 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
> > [EMAIL PROTECTED]
> > http://dankulp.com/blog
--
Daniel Kulp
[EMAIL PROTECTED]
http://dankulp.com/blog
