You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Alex Mantaut <al...@intraway.com> on 2013/04/11 16:41:50 UTC

Hash interface change?

Hi All

I have a question... I've been trying to improve Axis2/C thread stability
and noticed several issues with the hash interface...

 -  In one of the issues I need to stop using an external passed
environment for the hash (because it might create problems in multithreaded
environments) . (https://issues.apache.org/jira/browse/AXIS2C-1634)

  - In the other issue I need to internally manage the keys used, to avoid
problems related to the memory of the keys...  (
https://issues.apache.org/jira/browse/AXIS2C-1632)

The problem is that the solutions I've found break backward compatibility
(i.e. if I manage the key memory internally and the application allocated
and freed the memory before it will create a double free problem)...

 I've managed to modify all the calls to the hash's methods in axis, but
applications (like WSFCPP) might have a problem if I change the interface...

My question would be, what is the better way to overcome this problem?

Can I create a second version of the hash like axutil_hash2?

Or can I create a second version of the methods whose interface changes
(keeping them in the same file as hash)? i.e
axutil_hash_find_entry_non_copy or axutil_hash2_find_entry?

As always thanks for your patience...

Regards

-- 
-- 
Mantaut Alex
Intraway Corp.

+54 (11) 6040-4000
MSN: alex.mantaut@intraway.com

Visit our website at http://www.intraway.com
Proud to be an ISO 9001:2008 certified company

Re: Hash interface change?

Posted by Alex Mantaut <al...@intraway.com>.
Hi,
    I uploaded the proposed interface for hash in
https://issues.apache.org/jira/browse/AXIS2C-1632, with unit tests to test
the new functionality and ensure that this solution keeps backward
compatibility...

    Can someone review it, if there are any changes that need to be done on
it I'll modify the patch...

As always Thanks for everything




On Wed, Apr 17, 2013 at 2:35 PM, Alex Mantaut <al...@intraway.com>wrote:

> Ok,  I'll do the second option then (it will take me a while to adjust the
> patches, I think I'll unifiy them) ... Thanks Nandika and Dinesh for the
> feedback.
>
> Regards
> Alex
>
>
> On Wed, Apr 17, 2013 at 1:16 PM, Dinesh Weerapurage <xy...@gmail.com>wrote:
>
>> Hi Alex,
>>
>> Sorry, took me a while to go through this. +1 for second option. We may
>> want to add a clear explanation in comments why we add an addition method
>> with a reference to jira too.
>>
>> thanks,
>> Dinesh.
>>
>>
>> On Fri, Apr 12, 2013 at 3:04 AM, Nandika Jayawardana <ja...@gmail.com>wrote:
>>
>>> Hi Alex,
>>> I think the second option [ having a second version of the methods ) is
>>> more viable.
>>>
>>> Regards
>>> Nandika
>>>
>>>
>>> On Thu, Apr 11, 2013 at 8:11 PM, Alex Mantaut <alex.mantaut@intraway.com
>>> > wrote:
>>>
>>>> Hi All
>>>>
>>>> I have a question... I've been trying to improve Axis2/C thread
>>>> stability and noticed several issues with the hash interface...
>>>>
>>>>  -  In one of the issues I need to stop using an external passed
>>>> environment for the hash (because it might create problems in multithreaded
>>>> environments) . (https://issues.apache.org/jira/browse/AXIS2C-1634)
>>>>
>>>>   - In the other issue I need to internally manage the keys used, to
>>>> avoid problems related to the memory of the keys...  (
>>>> https://issues.apache.org/jira/browse/AXIS2C-1632)
>>>>
>>>> The problem is that the solutions I've found break backward
>>>> compatibility (i.e. if I manage the key memory internally and the
>>>> application allocated and freed the memory before it will create a double
>>>> free problem)...
>>>>
>>>>  I've managed to modify all the calls to the hash's methods in axis,
>>>> but applications (like WSFCPP) might have a problem if I change the
>>>> interface...
>>>>
>>>> My question would be, what is the better way to overcome this problem?
>>>>
>>>> Can I create a second version of the hash like axutil_hash2?
>>>>
>>>> Or can I create a second version of the methods whose interface changes
>>>> (keeping them in the same file as hash)? i.e
>>>> axutil_hash_find_entry_non_copy or axutil_hash2_find_entry?
>>>>
>>>> As always thanks for your patience...
>>>>
>>>> Regards
>>>>
>>>> --
>>>> --
>>>> Mantaut Alex
>>>> Intraway Corp.
>>>>
>>>> +54 (11) 6040-4000
>>>> MSN: alex.mantaut@intraway.com
>>>>
>>>> Visit our website at http://www.intraway.com
>>>> Proud to be an ISO 9001:2008 certified company
>>>>
>>>
>>>
>>
>
>
> --
> --
> Mantaut Alex
> Intraway Corp.
>
> +54 (11) 6040-4000
> MSN: alex.mantaut@intraway.com
>
> Visit our website at http://www.intraway.com
> Proud to be an ISO 9001:2008 certified company
>



-- 
-- 
Mantaut Alex
Intraway Corp.

+54 (11) 6040-4000
MSN: alex.mantaut@intraway.com

Visit our website at http://www.intraway.com
Proud to be an ISO 9001:2008 certified company

Re: Hash interface change?

Posted by Alex Mantaut <al...@intraway.com>.
Ok,  I'll do the second option then (it will take me a while to adjust the
patches, I think I'll unifiy them) ... Thanks Nandika and Dinesh for the
feedback.

Regards
Alex


On Wed, Apr 17, 2013 at 1:16 PM, Dinesh Weerapurage <xy...@gmail.com>wrote:

> Hi Alex,
>
> Sorry, took me a while to go through this. +1 for second option. We may
> want to add a clear explanation in comments why we add an addition method
> with a reference to jira too.
>
> thanks,
> Dinesh.
>
>
> On Fri, Apr 12, 2013 at 3:04 AM, Nandika Jayawardana <ja...@gmail.com>wrote:
>
>> Hi Alex,
>> I think the second option [ having a second version of the methods ) is
>> more viable.
>>
>> Regards
>> Nandika
>>
>>
>> On Thu, Apr 11, 2013 at 8:11 PM, Alex Mantaut <al...@intraway.com>wrote:
>>
>>> Hi All
>>>
>>> I have a question... I've been trying to improve Axis2/C thread
>>> stability and noticed several issues with the hash interface...
>>>
>>>  -  In one of the issues I need to stop using an external passed
>>> environment for the hash (because it might create problems in multithreaded
>>> environments) . (https://issues.apache.org/jira/browse/AXIS2C-1634)
>>>
>>>   - In the other issue I need to internally manage the keys used, to
>>> avoid problems related to the memory of the keys...  (
>>> https://issues.apache.org/jira/browse/AXIS2C-1632)
>>>
>>> The problem is that the solutions I've found break backward
>>> compatibility (i.e. if I manage the key memory internally and the
>>> application allocated and freed the memory before it will create a double
>>> free problem)...
>>>
>>>  I've managed to modify all the calls to the hash's methods in axis, but
>>> applications (like WSFCPP) might have a problem if I change the interface...
>>>
>>> My question would be, what is the better way to overcome this problem?
>>>
>>> Can I create a second version of the hash like axutil_hash2?
>>>
>>> Or can I create a second version of the methods whose interface changes
>>> (keeping them in the same file as hash)? i.e
>>> axutil_hash_find_entry_non_copy or axutil_hash2_find_entry?
>>>
>>> As always thanks for your patience...
>>>
>>> Regards
>>>
>>> --
>>> --
>>> Mantaut Alex
>>> Intraway Corp.
>>>
>>> +54 (11) 6040-4000
>>> MSN: alex.mantaut@intraway.com
>>>
>>> Visit our website at http://www.intraway.com
>>> Proud to be an ISO 9001:2008 certified company
>>>
>>
>>
>


-- 
-- 
Mantaut Alex
Intraway Corp.

+54 (11) 6040-4000
MSN: alex.mantaut@intraway.com

Visit our website at http://www.intraway.com
Proud to be an ISO 9001:2008 certified company

Re: Hash interface change?

Posted by Dinesh Weerapurage <xy...@gmail.com>.
Hi Alex,

Sorry, took me a while to go through this. +1 for second option. We may
want to add a clear explanation in comments why we add an addition method
with a reference to jira too.

thanks,
Dinesh.


On Fri, Apr 12, 2013 at 3:04 AM, Nandika Jayawardana <ja...@gmail.com>wrote:

> Hi Alex,
> I think the second option [ having a second version of the methods ) is
> more viable.
>
> Regards
> Nandika
>
>
> On Thu, Apr 11, 2013 at 8:11 PM, Alex Mantaut <al...@intraway.com>wrote:
>
>> Hi All
>>
>> I have a question... I've been trying to improve Axis2/C thread stability
>> and noticed several issues with the hash interface...
>>
>>  -  In one of the issues I need to stop using an external passed
>> environment for the hash (because it might create problems in multithreaded
>> environments) . (https://issues.apache.org/jira/browse/AXIS2C-1634)
>>
>>   - In the other issue I need to internally manage the keys used, to
>> avoid problems related to the memory of the keys...  (
>> https://issues.apache.org/jira/browse/AXIS2C-1632)
>>
>> The problem is that the solutions I've found break backward compatibility
>> (i.e. if I manage the key memory internally and the application allocated
>> and freed the memory before it will create a double free problem)...
>>
>>  I've managed to modify all the calls to the hash's methods in axis, but
>> applications (like WSFCPP) might have a problem if I change the interface...
>>
>> My question would be, what is the better way to overcome this problem?
>>
>> Can I create a second version of the hash like axutil_hash2?
>>
>> Or can I create a second version of the methods whose interface changes
>> (keeping them in the same file as hash)? i.e
>> axutil_hash_find_entry_non_copy or axutil_hash2_find_entry?
>>
>> As always thanks for your patience...
>>
>> Regards
>>
>> --
>> --
>> Mantaut Alex
>> Intraway Corp.
>>
>> +54 (11) 6040-4000
>> MSN: alex.mantaut@intraway.com
>>
>> Visit our website at http://www.intraway.com
>> Proud to be an ISO 9001:2008 certified company
>>
>
>

Re: Hash interface change?

Posted by Nandika Jayawardana <ja...@gmail.com>.
Hi Alex,
Lets have the methods in the same file. Then, when everything is working
fine, we can deprecate the old methods.

Regards
Nandika




On Fri, Apr 12, 2013 at 7:16 PM, Alex Mantaut <al...@intraway.com>wrote:

> HI Nandika,
>                 In that case, shall I add the new methods to
> axutil_hash.h, or shall I create a new file like axutil_hash2.h for the new
> interfaces?
>
> Regards
>
>
> On Fri, Apr 12, 2013 at 4:04 AM, Nandika Jayawardana <ja...@gmail.com>wrote:
>
>> Hi Alex,
>> I think the second option [ having a second version of the methods ) is
>> more viable.
>>
>> Regards
>> Nandika
>>
>>
>> On Thu, Apr 11, 2013 at 8:11 PM, Alex Mantaut <al...@intraway.com>wrote:
>>
>>> Hi All
>>>
>>> I have a question... I've been trying to improve Axis2/C thread
>>> stability and noticed several issues with the hash interface...
>>>
>>>  -  In one of the issues I need to stop using an external passed
>>> environment for the hash (because it might create problems in multithreaded
>>> environments) . (https://issues.apache.org/jira/browse/AXIS2C-1634)
>>>
>>>   - In the other issue I need to internally manage the keys used, to
>>> avoid problems related to the memory of the keys...  (
>>> https://issues.apache.org/jira/browse/AXIS2C-1632)
>>>
>>> The problem is that the solutions I've found break backward
>>> compatibility (i.e. if I manage the key memory internally and the
>>> application allocated and freed the memory before it will create a double
>>> free problem)...
>>>
>>>  I've managed to modify all the calls to the hash's methods in axis, but
>>> applications (like WSFCPP) might have a problem if I change the interface...
>>>
>>> My question would be, what is the better way to overcome this problem?
>>>
>>> Can I create a second version of the hash like axutil_hash2?
>>>
>>> Or can I create a second version of the methods whose interface changes
>>> (keeping them in the same file as hash)? i.e
>>> axutil_hash_find_entry_non_copy or axutil_hash2_find_entry?
>>>
>>> As always thanks for your patience...
>>>
>>> Regards
>>>
>>> --
>>> --
>>> Mantaut Alex
>>> Intraway Corp.
>>>
>>> +54 (11) 6040-4000
>>> MSN: alex.mantaut@intraway.com
>>>
>>> Visit our website at http://www.intraway.com
>>> Proud to be an ISO 9001:2008 certified company
>>>
>>
>>
>
>
> --
> --
> Mantaut Alex
> Intraway Corp.
>
> +54 (11) 6040-4000
> MSN: alex.mantaut@intraway.com
>
> Visit our website at http://www.intraway.com
> Proud to be an ISO 9001:2008 certified company
>

Re: Hash interface change?

Posted by Alex Mantaut <al...@intraway.com>.
HI Nandika,
                In that case, shall I add the new methods to axutil_hash.h,
or shall I create a new file like axutil_hash2.h for the new interfaces?

Regards


On Fri, Apr 12, 2013 at 4:04 AM, Nandika Jayawardana <ja...@gmail.com>wrote:

> Hi Alex,
> I think the second option [ having a second version of the methods ) is
> more viable.
>
> Regards
> Nandika
>
>
> On Thu, Apr 11, 2013 at 8:11 PM, Alex Mantaut <al...@intraway.com>wrote:
>
>> Hi All
>>
>> I have a question... I've been trying to improve Axis2/C thread stability
>> and noticed several issues with the hash interface...
>>
>>  -  In one of the issues I need to stop using an external passed
>> environment for the hash (because it might create problems in multithreaded
>> environments) . (https://issues.apache.org/jira/browse/AXIS2C-1634)
>>
>>   - In the other issue I need to internally manage the keys used, to
>> avoid problems related to the memory of the keys...  (
>> https://issues.apache.org/jira/browse/AXIS2C-1632)
>>
>> The problem is that the solutions I've found break backward compatibility
>> (i.e. if I manage the key memory internally and the application allocated
>> and freed the memory before it will create a double free problem)...
>>
>>  I've managed to modify all the calls to the hash's methods in axis, but
>> applications (like WSFCPP) might have a problem if I change the interface...
>>
>> My question would be, what is the better way to overcome this problem?
>>
>> Can I create a second version of the hash like axutil_hash2?
>>
>> Or can I create a second version of the methods whose interface changes
>> (keeping them in the same file as hash)? i.e
>> axutil_hash_find_entry_non_copy or axutil_hash2_find_entry?
>>
>> As always thanks for your patience...
>>
>> Regards
>>
>> --
>> --
>> Mantaut Alex
>> Intraway Corp.
>>
>> +54 (11) 6040-4000
>> MSN: alex.mantaut@intraway.com
>>
>> Visit our website at http://www.intraway.com
>> Proud to be an ISO 9001:2008 certified company
>>
>
>


-- 
-- 
Mantaut Alex
Intraway Corp.

+54 (11) 6040-4000
MSN: alex.mantaut@intraway.com

Visit our website at http://www.intraway.com
Proud to be an ISO 9001:2008 certified company

Re: Hash interface change?

Posted by Nandika Jayawardana <ja...@gmail.com>.
Hi Alex,
I think the second option [ having a second version of the methods ) is
more viable.

Regards
Nandika


On Thu, Apr 11, 2013 at 8:11 PM, Alex Mantaut <al...@intraway.com>wrote:

> Hi All
>
> I have a question... I've been trying to improve Axis2/C thread stability
> and noticed several issues with the hash interface...
>
>  -  In one of the issues I need to stop using an external passed
> environment for the hash (because it might create problems in multithreaded
> environments) . (https://issues.apache.org/jira/browse/AXIS2C-1634)
>
>   - In the other issue I need to internally manage the keys used, to avoid
> problems related to the memory of the keys...  (
> https://issues.apache.org/jira/browse/AXIS2C-1632)
>
> The problem is that the solutions I've found break backward compatibility
> (i.e. if I manage the key memory internally and the application allocated
> and freed the memory before it will create a double free problem)...
>
>  I've managed to modify all the calls to the hash's methods in axis, but
> applications (like WSFCPP) might have a problem if I change the interface...
>
> My question would be, what is the better way to overcome this problem?
>
> Can I create a second version of the hash like axutil_hash2?
>
> Or can I create a second version of the methods whose interface changes
> (keeping them in the same file as hash)? i.e
> axutil_hash_find_entry_non_copy or axutil_hash2_find_entry?
>
> As always thanks for your patience...
>
> Regards
>
> --
> --
> Mantaut Alex
> Intraway Corp.
>
> +54 (11) 6040-4000
> MSN: alex.mantaut@intraway.com
>
> Visit our website at http://www.intraway.com
> Proud to be an ISO 9001:2008 certified company
>