axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepal Jayasinghe <>
Subject Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
Date Tue, 10 Oct 2006 22:29:03 GMT
Sanjiva Weerawarana wrote:

>On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote:
>>In terms of setting up TLS info, I'm interested by the comment that it
>>would be set in the AxisEngine. When we had the conversation about the
>>ThreadContextMigrator interface (which does now exist) I understood
>>that there wasn't any guarantee that there is a single thread in use
>>through the handler chain.
>I believe it'll be set in the message receiver just before invoking the
>method right guys? I can't see why it needs to be set earlier.
Yes that was the final conclusion.

Deepal: hi dims
     [15:07]    Deepal:  u there
     [15:08]    Deepal: I dont think we can move saveTCCL(messageCtx);
in AxisEngine
     [15:23]    GlenD: dims?
     [15:23]    GlenD: u there?
     [15:26]    dims: ping
     [15:26]    GlenD: hey
     [15:26]    GlenD: so Deepal and I were chatting about the context stuff
     [15:26]    dims: yes
     [15:26]    GlenD: and ended up coming up with a very interesting
idea which we wanted to run past you
     [15:26]    dims: sure
     [15:26]    GlenD: I think it's too big a change for now, but it's
pretty cool for a future release
     [15:27]    dims: we need to make a list of those :)
     [15:28]    GlenD: the issue is that there's a lot of code
duplication amongst MessageReceivers
     [15:28]    dims: ah. that one :)
     [15:28]    GlenD: if we want this setTCCL stuff and the
setCurrentContext stuff to live in the MRs, it's hard to figure out
where to put it so it isn't dup'ed everywhere
     [15:29]    dims: call back to engine?
     [15:29]    dims: sorry...go ahead.
     [15:29]    GlenD: so we're wondering if you could maybe factor it
out into a single AbstractMessageReceiver
     [15:29]    GlenD: which would do the TCCL/Context stuff, then call
invokeBusinessLogic() but pass only the OperationContext
     [15:29]    dims: we have one of those
     [15:30]    dims: AbstractMessageReceiver
     [15:30]    GlenD: not have separate ones that pass either
(inContext) or (inContext, outContext)
     [15:30]    GlenD: we do?
     [15:30]    dims: we need to structure it better
     [15:30]    Deepal: we have 4 of them :)
     [15:30]    GlenD: right
     [15:30]    GlenD: we have 4
     [15:30]    dims: org.apache.axis2.receivers.AbstractMessageReceiver
     [15:31]    dims: ah. i see
     [15:31]    Deepal: and we are thinking of chaning
invokeBusinessLogic signature
     [15:31]    GlenD: only the lower level ones (AbstractInOnlyMR, etc)
actually have receive()
     [15:31]    GlenD: the top level one doesn't do anything
     [15:31]    GlenD: except hold utility methods
     [15:31]    dims: any cleanup is very welcome! sorely needed in this
     [15:31]    dims: +1
     [15:31]    GlenD: so the interesting part is that SOMEONE needs to
know to take the outMessageContext from the operationContext and send it
     [15:31]    dims: please make sure you handle the spring scenario
     [15:31]    Deepal: invokeBusinessLogice will take OperationContext 
as it argument
     [15:32]    GlenD: that's the real difference between in and inout
     [15:32]    dims: and then check isinstanceof?
     [15:32]    GlenD: we're wondering if there's a way to genericize
that by calling invokeBusinessLogic() and then something like complete()
or doNext()
     [15:32]    GlenD: but we need to think about it a little more I
think :)
     [15:33]    dims: yep...
     [15:33]    dims: pre and post?
     [15:34]    GlenD: (thinking here)
     [15:34]    dims: first step is to collapse all 4 into 1
     [15:34]    dims: somehow
     [15:34]    GlenD: that was the thought yes but we're seeing if it
can work....
     [15:35]    dims: then adjust the calls to invokeBusinessLogic and
maybe call something before it and something after it for special
processing for different MEP's?
     [15:36]    dims: are we looking for clean code or new feature here?
     [15:36]    Deepal: I think both :)
     [15:37]    dims: and the new Feature is?..
     [15:37]    GlenD: its really mostly clean code
     [15:37]    GlenD: and a good place to put the common stuff for tls
     [15:38]    dims: :) ok.
     [15:53]    GlenD: ok never mind :)
     [15:53]    GlenD: I think we just came to the conclusion that it's
actually useful to have different abstract Receiver types
     [15:54]    GlenD: because they're the ones that know the logic for
message processing
     [15:54]    GlenD: if you had an in/in/out MR, for instance, it
could have processMessage1() and processMessage2() abstract operations
     [15:54]    GlenD: that's nicer than just relying on a single
invokeBusinessLogic(OperationContext), I think
     [15:56]    GlenD: So the idea is to coalesce the TCCL stuff and the
CurrentContext stuff into a setupThreadContext() and
removeThreadContext() on AbstractMessageReceiver
     [15:57]    GlenD: so developers of new MRs that want TLS
functionality would need to know to call that method, but it sets up
both the classloader and the MessageContext.getCurrentContext()
     [16:00]    dims has disconnected: Read error: 104 (Connection reset
by peer)
     [16:00]    dims has joined
     [16:01]    dims: +1 to "coalesce the TCCL stuff and the
CurrentContext stuff into a setupThreadContext() and removeThreadContext()"
     [16:01]    GlenD: great
     [16:01]    Deepal: +1 for doing that for 1.1
     [16:01]    dims: sure
     [16:02]    dims: but again. proposal to mailing list.
     [16:07]    GlenD: ya
     [16:35]    GlenD: brb
     [16:35]    GlenD has disconnected
     [16:36]    GlenD has joined
     [17:13]    Deepal: this time hackerthon seems good to me
     [17:14]    Deepal: finding bugs , improvements
     [17:14]    Deepal: s/hackerthon/hackarthon

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message