Hi Chinthaka:
Eran Chinthaka wrote:
Well, I don't think exposing message context is an option as it has lots
of methods and complex. Yes we could come up with an alternative to
I don't think it is (or perhaps "should be") all that complex, really.
implement options interface to message context, but we didn't consider
that alternative when we were implementing it. The current method was
the best one that we could think of at that time.
To be clear - I like the idea of the Options object. In Axis1, we could
set properties on the Call object (like ServiceClient) which would be
accessible via the MessageContext, but you'd need to do it for each
Call. Options is nicely split out so that you can reuse it for multiple
ServiceClients - or at least it looks that way. :)
I still do not see a huge difference between the current approach and
what you suggest. It might reduce one object in the memory.
See below.
Good point. But Options object will only have reference from a message
context, so how can it be in the memory. We didn't see anything like
that when we were doing memory profiling. Also how can a handler putting
an object make a sudden change? Please explain a bit more.
The user code has a reference to the Options object, at least if you're
reusing it. See below again. :)
I'd really like us to consider changing this for 1.3 and into the future.
I still do not think we need to change this ;) BTW, what is the problem
of the current approach? Obviously Ruchith's initial concern is now
settled. Please help me to understand the problem, which is kinda hard
using mailing lists.
A little code:
public class MyTestProgram {
public static void main() throws Exception {
Options opts = new Options();
// ...initialize options...
while (a_very_long_time) {
ServiceClient client = new ServiceClient(opts);
// ... do some more stuff ...
client.sendReceive(...);
}
}
}
So every time around that loop, that Options object is becoming not only
the storage for the stuff that the user put there, but also for any
properties that the Handlers which run happen to put there. Let's say
you've got a Handler that can be deployed multiple times on a given
flow; one that performs some function and then counts the number of
times it has been invoked in a given message flow. So it has code like:
Integer count = (Integer)msgContext.getProperty("myCount");
if (count == null) count = new Integer(0);
count = new Integer(count.intValue() + 1);
msgContext.setProperty("myCount");
Now, the idea is to record the number of invocations per MESSAGE, which
is why it's writing to the *Message*Context. You can see how the second
time around the loop, the count becomes incorrect, right? Because the
property isn't per-MessageContext, it's per-Options. Bad.
That's one kind of problem. Another is that Handlers might use largish
data structures and put them in MessageContext properties - any such
structures won't get GC'ed for as long as the Options object is held...
and that might be a long time (for instance I can imagine an Axis2
system running in a continuous loop polling shop floor equipment
checking for alert conditions - too hot, low on oil, etc).
Yet another problem is that I might want to reuse the same Options
object across multiple ServiceClients - imagine a user doing that where
they tried to do multiple invocations on multiple threads! Two
MessageContexts could be traversing different handler chains, with the
exact same backing store for properties... I would be very surprised if
that worked out well. :)
I see lots of problems with the current approach. I don't (yet) see any
problems which would arise out of fixing it.
Fixing it involves, IMO, separating the MC's property store from the
Options bag, and making sure that getProperty() searches in the correct
order. There may be some more discussion needed to deal with use-cases
where the user pulls properties back OUT of Options after invocation -
do we have situations like that?
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
