axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: [Axis2] Proposal: Extending the handler invocation pattern
Date Mon, 17 Apr 2006 00:11:37 GMT
Hi Alek,

> > Um why not? If you want to send a response and continue then you can
> > fire the response off in another thread (or the remaining work in
> > another thread). I don't think your approach makes sense as a solution
> > for this scenario at all: you're saying block everything until the
> > message is gone. 
> >   
> servlet writes response (201 OK) and servlet thread can be
> recycled/terminated by servlet container.

Yes I know .. but what's that got to do with what Bill is suggesting? He
wants to write the response and then notify executed handlers saying
"hey everything was cool". In the servlet world, you can't write the
response and then do something because the response gets written when
you return from the servlet. 

> is the way it is done in AXIS2 is= not how it has to be done to handle
> async WSA? is there any other way?

Sorry, I didn't grok that sentence. 

Axis2 allows you to do Async Web services at different levels - you can
hand off to another thread at the transport level, in the middle of
handlers (sort of what Sandesha does), or in a message receiver (as the
async message receivers do). Axis2 does not assume that a single thread
is doing all the work .. as long as you have the pointer to the context
hierarchy then all is fine. 

So my point to Bill was that the right way to exploit Axis2 is not to
stick stuff on the thread when messages are flowing thru Axis2 but
rather to stick stuff in the context hierarchy. The only time you should
stick stuff on the thread is when you're out of Axis2 and in a world
which requires it (such as when invoking an EJB). In that case, the code
that's going out is responsible for cleaning up.

Sanjiva.


Mime
View raw message