t;>>
>>> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, Oct 18, 2010 at 11:05 PM, Matt Benson
>>> wrote:
>>>
>>&
://www.99soft.org/
>>
>>
>>
>> On Mon, Oct 18, 2010 at 11:05 PM, Matt Benson
>> wrote:
>>
>>>
>>> On Oct 18, 2010, at 3:35 PM, Gary Gregory wrote:
>>>
>>> -Original Message-----
>>>>> From: Steven Siebert [mailto:
, 2010, at 3:35 PM, Gary Gregory wrote:
-Original Message-
From: Steven Siebert [mailto:smsi...@gmail.com]
Sent: Monday, October 18, 2010 04:52
To: Commons Developers List
Subject: Re: [pool] runtime re-configuration
Why not add an (or a small set of) MBean(s) to where you can not only manage
Steven Siebert [mailto:smsi...@gmail.com]
>>> Sent: Monday, October 18, 2010 04:52
>>> To: Commons Developers List
>>> Subject: Re: [pool] runtime re-configuration
>>>
>>> Why not add an (or a small set of) MBean(s) to where you can not only manage
>&g
On 19.10.2010 00:56, Mark Thomas wrote:
On 18/10/2010 01:22, Benoit Perroud wrote:
2010/10/17 Phil Steitz
On 10/17/10 8:53 AM, Benoit Perroud wrote:
We should talk about why the Tomcat devs decided to implement their own
FairBlockingQueue.
ENOCLUE. There might be something in the Javadoc but
On 18/10/2010 01:22, Benoit Perroud wrote:
> 2010/10/17 Phil Steitz
>
>> On 10/17/10 8:53 AM, Benoit Perroud wrote:
>>
>>> Making pool be able to be resized at runtime will introduce extra
>>> complexity, that could be otherwise totally delegated to a BlockingQueue
>>> as
>>> backend structure.
>
On Oct 18, 2010, at 3:35 PM, Gary Gregory wrote:
>> -Original Message-
>> From: Steven Siebert [mailto:smsi...@gmail.com]
>> Sent: Monday, October 18, 2010 04:52
>> To: Commons Developers List
>> Subject: Re: [pool] runtime re-configuration
>>
>>
> -Original Message-
> From: Steven Siebert [mailto:smsi...@gmail.com]
> Sent: Monday, October 18, 2010 04:52
> To: Commons Developers List
> Subject: Re: [pool] runtime re-configuration
>
> Why not add an (or a small set of) MBean(s) to where you can not only manage
Why not add an (or a small set of) MBean(s) to where you can not only manage
some of the mutable values, but also add the capability to runtime monitor
the pool through jconsole and 3rd party JMX/network monitoring systems?
This would keep the pool API the same, reducing the need for you to maintai
2010/10/17 Phil Steitz
> On 10/17/10 8:53 AM, Benoit Perroud wrote:
>
>> Making pool be able to be resized at runtime will introduce extra
>> complexity, that could be otherwise totally delegated to a BlockingQueue
>> as
>> backend structure.
>>
>
> I don't understand exactly what you are saying
On 10/17/10 8:53 AM, Benoit Perroud wrote:
Making pool be able to be resized at runtime will introduce extra
complexity, that could be otherwise totally delegated to a BlockingQueue as
backend structure.
I don't understand exactly what you are saying here. The question
is should the user-expo
Making pool be able to be resized at runtime will introduce extra
complexity, that could be otherwise totally delegated to a BlockingQueue as
backend structure.
Moreover is there some ideas of what kind of implementation will be used to
implement the pool v2 ?
ArrayBlockingQueue is IMO a good can
Hi guys,
I'd add that not all properties are configurable, we should add
setters only in case it makes sense, or not?
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz wrote:
>
>
>
>
> On Oct 12, 2010, at 4:42 PM, Jö
On Oct 12, 2010, at 4:42 PM, Jörg Schaible wrote:
> Gary Gregory wrote:
>
>> I too would like to be able to tweak the size of the pool at runtime.
>>
>> Gary
>>
>> On Oct 12, 2010, at 13:19, "James Carman"
>> wrote:
>>
>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>>> wrote:
> -Original Message-
> From: Gary Gregory
> Sent: Tuesday, October 12, 2010 17:08
> To: dev@commons.apache.org; 'joerg.schai...@gmx.de'
> Subject: RE: [pool] runtime re-configuration
>
> > -Original Message-
> > From: Jörg Schaible [mailto:
> -Original Message-
> From: Jörg Schaible [mailto:joerg.schai...@gmx.de]
> Sent: Tuesday, October 12, 2010 16:42
> To: dev@commons.apache.org
> Subject: Re: [pool] runtime re-configuration
>
> Gary Gregory wrote:
>
> > I too would like to be able to tweak t
Gary Gregory wrote:
> I too would like to be able to tweak the size of the pool at runtime.
>
> Gary
>
> On Oct 12, 2010, at 13:19, "James Carman"
> wrote:
>
>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>> wrote:
>>> Hi Phil! :)
>>> honestly I didn't understand which are the use cases
I too would like to be able to tweak the size of the pool at runtime.
Gary
On Oct 12, 2010, at 13:19, "James Carman" wrote:
> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> wrote:
>> Hi Phil! :)
>> honestly I didn't understand which are the use cases when a pool needs
>> to be reconfigure
Good point James, thanks for the feedback! I suppose that's the reason
why previous maintainers let the fields protected to access them
directly, that will be replaced by setters/getters methods.
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 10:18
On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
wrote:
> Hi Phil! :)
> honestly I didn't understand which are the use cases when a pool needs
> to be reconfigured, that's why I've always used the pool in "configure
> and use" modality and Seb's suggestion sounded good to me. OTOH I
> didn't modif
Yes
On Oct 12, 2010, at 12:17 PM, Simone Tripodi wrote:
> Hi Phil,
> OK that's clear, according to this policy, just to keep things
> consistent, also *.Config properties should be accessed only by
> getters/setters, how does it sound for you?
> Simo
>
> http://people.apache.org/~simonetripod
> Sent: Tuesday, October 12, 2010 09:39
>> To: Commons Developers List
>> Subject: Re: [pool] runtime re-configuration
>>
>> On 12 October 2010 17:13, Phil Steitz wrote:
>> > On 10/12/10 11:26 AM, sebb wrote:
>> >>
>> >> On 12 October 2010 1
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Tuesday, October 12, 2010 09:39
> To: Commons Developers List
> Subject: Re: [pool] runtime re-configuration
>
> On 12 October 2010 17:13, Phil Steitz wrote:
> > On 10/12/10 11:26 AM, sebb wro
On 12 October 2010 17:13, Phil Steitz wrote:
> On 10/12/10 11:26 AM, sebb wrote:
>>
>> On 12 October 2010 16:03, Phil Steitz wrote:
>>>
>>> On 10/12/10 7:32 AM, Simone Tripodi wrote:
Hi Seb,
I totally agree, I'm for this solution, BTW I'll wait the Phil's
opinion that knows mo
Hi Phil,
OK that's clear, according to this policy, just to keep things
consistent, also *.Config properties should be accessed only by
getters/setters, how does it sound for you?
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 6:13 PM, Phil Steitz
On 10/12/10 11:26 AM, sebb wrote:
On 12 October 2010 16:03, Phil Steitz wrote:
On 10/12/10 7:32 AM, Simone Tripodi wrote:
Hi Seb,
I totally agree, I'm for this solution, BTW I'll wait the Phil's
opinion that knows more than me.
Thanks!
Simo
http://people.apache.org/~simonetripodi/
http://www
On 12 October 2010 16:03, Phil Steitz wrote:
> On 10/12/10 7:32 AM, Simone Tripodi wrote:
>>
>> Hi Seb,
>> I totally agree, I'm for this solution, BTW I'll wait the Phil's
>> opinion that knows more than me.
>> Thanks!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org
Hi Phil! :)
honestly I didn't understand which are the use cases when a pool needs
to be reconfigured, that's why I've always used the pool in "configure
and use" modality and Seb's suggestion sounded good to me. OTOH I
didn't modify any single code line before hearing your thoughts since
you know
On 10/12/10 7:32 AM, Simone Tripodi wrote:
Hi Seb,
I totally agree, I'm for this solution, BTW I'll wait the Phil's
opinion that knows more than me.
Thanks!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 12:50 PM, sebb wrote:
On 12 October 2010
Hi Seb,
I totally agree, I'm for this solution, BTW I'll wait the Phil's
opinion that knows more than me.
Thanks!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 12:50 PM, sebb wrote:
> On 12 October 2010 10:20, Simone Tripodi wrote:
>> Hi all guys
On 12 October 2010 10:20, Simone Tripodi wrote:
> Hi all guys,
> while fixing the deprecated properties in classes like
> StackKeyedObjectPool[1], I noticed this class instance was
> re-configured during the test[2] (see line 126); is the
> "reconfigure-in-runtime" a pool feature we want? I'm aski
Hi all guys,
while fixing the deprecated properties in classes like
StackKeyedObjectPool[1], I noticed this class instance was
re-configured during the test[2] (see line 126); is the
"reconfigure-in-runtime" a pool feature we want? I'm asking because
I've never experienced the pool reconfiguration
32 matches
Mail list logo
