Samisa Abeysinghe wrote:
Damitha Kumarage wrote:
Samisa Abeysinghe wrote:
Dinesh Premalal wrote:
Hi,
Damitha Kumarage <[EMAIL PROTECTED]> writes:
Hi,
We copy properties from one ctx to another ctx often(in sandesha2
also)
This lead to problems in Sandesha2.
To avoid this would like to add a clone function ot axis2_property
like we have done in
aixs2_qname.
If we can maintain a reference counter, we could be able to get rid of
double freeing etc. Every time you referencing to that property
reference counter increases. Reference counter decrements when
freeing. Actual Freeing occurred when reference counter reaches to 0.
I think this method will be less expensive than cloning.
Ref count solved the problem but increases coupling. It becomes hard
to use it with all the places needing a reference having to deal
with ref count.
But it seems we have to keep a reference count. Otherwise it is
impossible to create a new context using exising context.
So it seems that we need to add an add_ref function to
aixs2_property. As Dinesh said when axis2_property_free is called
this ref count is decreased by 1 and when it is 0 actual freeding
should happen
When are we going to increase the ref count? In which methods? I think
we have to be clear on this, before implementing ref count. Unlike in
the case of namespaces, where the use is limited, properties are more
widely used - so IMHO, maintaining the ref count itself would be a
headache.
P.S. Even with namespace ref count, I am facing problems where there
is a leak in client failure cases - but I still cannot figure out
where the leak is happening. It sure help in some situations, but not
at all times.
The other solution is to use the scope concept of the property. For
the properties that we copy across, we can set the scope to be
application, in which case they are not freed by message context.
Currently I use this and it works fine. Actually when I look into the
whole code I can see that no structs except strings are set to
properties from client api's level. In all other places where structs
are set as property values I see that the scope is application level.
When scope is application level usually the value is not freed by the
property but by some other owner of the struct. So what I'm going to
suggest is not to free property values at property level at all. AFAIK
this will not affect
the current code. In fututre also we can avoid that. This will save us
from lot of headache.
Also even if we free property values the scope in the property has no
meaning. It should be a boolean to indicate whether
to free the value or not(May be I was the one who indroduced it to the
property :)). Because scope of the property can
be understood by to which struct it belongs to(ex. a conf property is
application scope above is more natural.
We can also set them at a higher level of the context hierarchy other
than message context, however, that is not possible if the properties
message level properties (that is each massage has a unique property
value), but the requirement suggests otherwise. Please see if that
Would be a viable solution. Else we may have to live with ref-count.
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
