-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Glen Daniels wrote:
> (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.
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
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.
I still do not see a huge difference between the current approach and
what you suggest. It might reduce one object in the memory.
>
>> 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.
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.
>
>> 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.
Ok, I will see. But my searching methodology is very primitive.
>
> 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.
Thanks,
Chinthaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGgFSojON2uBzUhh8RAhqaAKCGoLB+kSsG/pPaM48e/zxedKGIzgCePSmK
PrSkIAY2QkQoXs8YsKdmrGA=
=WHVs
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
