commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [pool] Reusing Config
Date Thu, 28 Oct 2010 18:10:54 GMT
On 28 October 2010 18:50, Simone Tripodi <simone.tripodi@gmail.com> wrote:
> Hi Seb,
> thanks for your feedbacks. Please read my questions inline your comments
>
>> The public StackObjectPoolConfig ctor repeats the settings available
>> in the nested Builder.
>> I'm not sure I see the point of having both. Or perhaps the ctor is
>> supposed to be private?
>
> I'm sorry but I didn't understand. Can you provide me a short sample
> please? Many thanks in advance :P

StackObjectPoolConfig config1 = new StackObjectPoolConfig(maxSleep,initIdle)

creates an instance which is equal to the one created by

StackObjectPoolConfig config2 = new StackObjectPoolConfig.Builder()
        .setInitIdleCapacity(initIdle)
        .setMaxSleeping(maxSleep)
        .createConfig();

>
>> Also, I don't like the way the ctor resets the parameters if they are
>> out of range, especially as this is not documented.
>>
>
> As user, I don't too, but I took inspiration from the old 1.5 code.
> Take a look at http://s.apache.org/tS

Yes, but that does at least document the parameter munging.

>
>> ==
>>
>> The StackObjectPool ctor calls the overridable method
>> reconfigure(StackObjectPoolConfig) which is not safe when subclassing.
>> Easily fixed by having a private method with the shared code.
>>
>
> I suppose the idea was to expose that method to allow users
> reconfigure the pool just passing the whole configuration and not
> setting the parameters one by one. So I suggest to make `final
> synchronized` that method. Thoughts?

Making the method final is another option; needs to be documented why
it was done.

>
>> Also, reconfigure() updates maxSleeping, but is not synchronized, so
>> may not publish maxSleeping correctly.
>>
>> Similar considerations apply to the other classes.
>
> Thanks a lot, have a nice day!
> Simo
>
>>
>>> If this fits to our vision, I can follow applying the refactor to
>>> Generic(Keyed)ObjectPool(Factory).
>>> Many thanks in advance!!!
>>> All the best,
>>> Simo
>>>
>>> [1] http://svn.apache.org/viewvc?rev=1028302&view=rev
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Thu, Oct 28, 2010 at 2:46 PM, Simone Tripodi
>>> <simone.tripodi@gmail.com> wrote:
>>>> Hi James,
>>>> thanks, understood. I take in charge yet another cycle of refactoring,
>>>> I'll ping you all when in trouble about something :)
>>>> Have a nice day and thanks for the feedbacks!
>>>> Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Thu, Oct 28, 2010 at 2:12 PM, James Carman
>>>> <james@carmanconsulting.com> wrote:
>>>>> On Thu, Oct 28, 2010 at 6:50 AM, Simone Tripodi
>>>>> <simone.tripodi@gmail.com> wrote:
>>>>>> That's why I wouldn't follow the option #2; but please, explain me
>>>>>> which are the side effects of that design, so I can avoid to repeat
>>>>>> the same mistake in the future.
>>>>>>
>>>>>
>>>>> If you make the config objects immutable, you can just keep the config
>>>>> references around and skip the copying in the reconfigure() method.  I
>>>>> don't think it would be difficult to implement things this way.  We
>>>>> don't want to let the JMX stuff dictate our API too much.  The JMX
>>>>> stuff can be less "elegant" for sure.  Consider it to be just a UI
>>>>> layer on top of our stuff.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message