(note new subject line) Hi Chinthaka:
Eran Chinthaka wrote:
Can you remember you raised the same question during the hackathon and I answered it :). Anyway here it is again.
IIRC I asked about why Options were getting *copied* from place to place during MEPs, not why we're using the Options object as the MessageContext's property store... if I had realized that in Indiana, there would have been a longer conversation. :)
Client should see Options object as a means to pass params to Axis2 engine and not as a place holder for his properties. When he passes that
Right, that sounds good!
to MessageContext, we keep that underneath the message context as we do not want the overhead of copying everything to a new data structure inside the message context. Since this options object will be anyway there inside the message context, and since it can store properties, we didn't put another object to message context to store properties. We
OK, now this really does not sound good. :) Why does this make sense? I thought the idea (please correct me if I'm wrong) of Options was that you could reuse it across invocations, keeping all the "application settable" information in one place. If that's the case, then we are essentially cluttering a potentially long-lived object with references to properties that may have no meaning outside of a given invocation.
To put it another way - if Options is actually the exact same storage for properties as MessageContext, it doesn't seem like there was any point in creating the Options object at all. We could have just left the MessageContext exposed to the user and they could use it's setTo()/setReplyTo()/etc methods. Or if we wanted just an API shim for simplicity, we could have easily provided an Options interface which MessageContext would implement.
re-used the same options object. Yes, this is a deliberate design decision. IIRC, me and Sanjiva (Deepal also, IIRC) had a long chat on this, sent a proposal and did that.
I just spent a little while looking through the list archives. I did see the "new client API" thread, in which Options was brought up as a way to capture "options to configure any MEP client". But I did not see any discussion (until the code) of /replacing/ the MessageContext property bag with Options. If I missed something, my apologies, but even if I did, I still don't agree with this design.
See, what you are saying is in fact asking to copy the properties of the options object to message context property object, leaving the room for the user to re-use it. What we have done was asking the user to copy it himself, if he needs to re-use it, but achieving possible performance AND memory gains inside the engine.
First off, I'm not necessarily asking for any copying. The obvious way to do this is to simply have the MC search the Options object if it doesn't find a property in its local store, just like it searches any other parent context. I suspect that'll be quite sufficient, but if it turns out later ("don't prematurely optimize") that there's a real speed issue, then we can consider copying - which still shouldn't be very expensive (it would be odd if there were more than 50 or so things in there, I would guess).
As for "memory gains", I think *exactly* the opposite of what you're saying is true. With the current system, any time a Handler puts an object into the MessageContext, there is suddenly a reference to that object that will hang around as long as the Options object hangs around, so for any kind of long-running client you've got a memory leak. Long term storage is not the design center for MessageContexts! MC's contain stuff that should GO AWAY after the processing of the message completes. Stuff with longer lifespans should live in separate places.
Yes, it is by design and I don't see any issue with that. It is the way you see it. The only problem is I am not sure we have written down this somewhere, other than in a mail thread :(.
If you could point me towards the mail thread that would be great. I'd really like us to consider changing this for 1.3 and into the future. --Glen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
