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 <[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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
