On 10/19/10 1:45 AM, Simone Tripodi wrote:
+1, I like the idea of using MBeans too!
+1 - the Tomcat jdbc-pool code has the beginnings of this.
Phil
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon, Oct 18, 2010 at 11:05 PM, Matt Benson<gudnabr...@gmail.com> wrote:
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
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 maintain
these in later versions. IMHO you would be gaining a lot more from this
approach.
If desired, I will volunteer to write the patch for this. I am using this
approach to monitor my pools, adding accessors for configuration values is
fairly trivial.
I do like this idea!
+1
-Matt
Gary
Regards,
Steve
On Wed, Oct 13, 2010 at 6:29 AM, Simone Tripodi
<simone.trip...@gmail.com>wrote:
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://people.apache.org/%7Esimonetri
podi/>
http://www.99soft.org/
On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz<phil.ste...@gmail.com>
wrote:
On Oct 12, 2010, at 4:42 PM, Jörg Schaible<joerg.schai...@gmx.de>
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"<ja...@carmanconsulting.com>
wrote:
On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
<simone.trip...@gmail.com> 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 modify any single code line before hearing your thoughts since
you know much more than me.
If pool's property are mutable, so I need to add the setters, make
them final otherwise :P
What if you want to alter the way the pool works at runtime? Perhaps
you're seeing that it keeps causing long waits because you're not
allowing it to grow big enough?
Why then not create a new pool and take over ownership of the objects?
There may be instances out in circulation. Also requests waiting,
maintenance in progress, etc not to mention the need to redirect clients.
The flexibility to be able to increase pool size or change other parameters
on the fly is good IMO and where we can safely support it without
performance impact we should.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
