cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: CXF continuation enhancement
Date Thu, 09 Sep 2010 02:57:38 GMT
On Wednesday 08 September 2010 9:08:36 pm Willem Jiang wrote:
.......
> I'm afraid I had to introduce other status into interceptor chain like
> SUSPEND, it will move the interceptor iterator to the preious one and
> through the SuspendedInvocationException, and PAUSED will not do these
> things.
> 
> I will give it a shoot :)

Cool.  Hopefully it works a bit better.

This actually should be a bit cleaner across the board.  If the 
ServiceInvokerInterceptor and such needs to see if the chain is suspended, it 
can just call message.getInterceptorChain().isSuspended() (or similar).  For 
example, since the Exception in not longer thrown, it may need (or at least 
should) check that to see if it should setup the response message or not.


> >> Current we just make the interceptor chain resume from where we pause
> >> it. I don't know that you want.
> >> I think the blow code is enough.
> >> 
> >>   continuation.setObject(obj);
> >>   continuation.resume()
> > 
> > I think my point was that why have it resume where it left off at all.  
> > Why could we not just do something like:
> > 
> > 
> > Foo doSomething(...) {
> > ....
> > 
> >     if (continuationProvider != null) {
> >     
> >          final Coninuation cont = coninuationProvider.getContinuation();
> >          cont.suspend();
> >          executor.execute(new Runnable() {
> >          
> >            public void run() {
> >            
> >                cont.resume(doTheRealThing(....));
> >            
> >            }
> >          
> >          });
> >          return null;
> >     
> >     }
> >     // no continuation support, must do syncronous
> > 	 
> > 	 return doTheRealThing(...);
> > 
> > }
> > Foo doTheRealThing(...) {
> > 
> >     return new Foo();
> > 
> > }
> 
> Understood, in this way the implemenation can support the continuation
> and no continuation environment at the same time.
> As we get the control of the interceptor chain, it can be done by
> hacking the ServiceInvokerInterceptor and put the response back, but it
> will break the old continuation semantic which can make the user method
> be called again when the continuation resume is called.

Well, I was kind of assuming that if resume() is called (the old method), the 
old behavior would remain.   If resume(object) is called, the new behavior can 
be used.   Thus, it really wouldn't break the old semantic, but would allow 
for a new, cleaner, semantic.   What do you think?

Dan



> 
> Willem
> 
> > With a setup like that, there isn't a need for doSomething(...) to be
> > called again at all.   The runtime would be able to handle it all.  For
> > some transports, we could use the thread that called resume(obj) to
> > restart the chain and such and not bother with another transport
> > provided thread and do the tread context switches and such.
> > 
> > Dan
> > 
> >>> I actually would like to change everything to not bother with the
> >>> exception either.   The endpoint would call "suspend" and if it returns
> >>> true (meaning the request was suspended), just return null.  If false,
> >>> it knows it needs to do the work synchronously.   It's much closer to
> >>> how the Servlet 3 things work.   Unfortunately, that would completely
> >>> change the semantics of the API and would require some good docs for
> >>> the migration guide.
> >> 
> >> I don't think this is a good idea, if we can't support to the
> >> continuation API from the transport level, we simple don't let the user
> >> can get the ContinuationProvider from the message context.
> >> 
> >> It could be much easier for user to use :)
> >> 
> >> [1]https://issues.apache.org/jira/browse/CXF-2982
> >> 
> >> Willem

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

Mime
View raw message