commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] Reusing Config
Date Thu, 28 Oct 2010 17:50:59 GMT
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

> 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

> ==
>
> 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?

> 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


Mime
View raw message