commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [pool] Question / potential improvement on KeyedObjectPool
Date Thu, 12 Jul 2012 04:21:57 GMT
On 7/10/12 2:51 PM, Liviu Tudor wrote:
> Hi guys,
>
> I have a question regarding [pool] -- which might turned out to be either a
> request for change or a potential improvement patch (though it could be the
> case I suppose that I've misunderstood certain things, in which case it will
> just turn out into my wasting people's time -- hopefully not though :)
>
> So a bit of context: I'm using [pool] in one of the projects I'm working on,
> more specifically I'm using a GenericKeyedObjectPool. This is actually used
> as a "create (instances) and cache (them) ahead" in the sense that it's used
> to create in advance N instances of certain classes and pool them. All these
> classes are "script classes" -- in the sense that we do allow in this
> application a few hooks where we can execute user-written Java code, which
> obviously are not known ahead ‹ and because the application is a rather
> high-throughput one, rather than creating these instances on demand (when
> execution of the program reaches the "hook" point and needs to run the
> "script") I've decided to have a pool-based implementation which will create
> in advance N instances of these "script" classes and then when the "hook"
> point is used, simply use one of the already-created objects from the pool ‹
> thus decreasing the execution time. Without going into details, some of
> these instances can be re-used and added back to the pool, while others are
> simply a one-off execution, after which the class needs to be destroyed ‹
> however, in both cases, I would like to keep around N instances pre-created
> in the pool, for each class type.
>
> Now, my idea ‹ and this is where (finally!) my question/suggestion comes in
> ‹ is to have a background thread (a ScheduledExecutorService, scheduled at
> fixed intervals) which kicks in and goes through all the keys in the pool
> and for each such key it uses the KeyedObjectPoolableFactory to create up to
> N instances for each key (based of course also on the getNumIdle(Key)
> return). 
>
> The problem with that ‹ as I found out soon ‹ is that there is no way to
> access the set of keys in a KeyedObjectPool! I was expecting something upon
> the lines of standard JDK collections :
>
> Set<K> keySet();
>
> or similar, however, there isn't anything like that around. So question
> number one is : Should we consider making such a method available? (As far
> as I can see, the GenericKeyedObjectPool uses a poolMap member internally so
> we could easily wrap up the keySet() into an unmodifiable set or similar if
> that makes sense.)

This seems a reasonable enhancement request. Can you please open a
JIRA for it. That way you can also attach patches ;)

The tricky bit will be how to do this with integrity but without
performance impact.

Phil
>
> Alternatively ‹ and this is question two, and where this email can turn into
> a proposal for a commit of a new component/class ‹ does it make sense to
> have a specialised KeyedObjectPool which does what I described above? The
> way I'm doing the pre population is by keeping a set of all the keys that
> were requested/removed (through borrowObject/preparePool/etc) -- and the
> background thread iterates through these keys and creates instances where
> necessary. (I am happy of course to provide this implementation to ASF as a
> patch request or similar.)
>
> Hopefully I managed to explain what I'm trying to achieve here ‹ but happy
> to provide more details where necessary.
>
> Many thanks in advance,
>
>
>
> Liv 
>  
>
> Liviu Tudor
>  
> E: liviu.tudor@gmail.com <mailto:liviu.tudor@gmail.com>
> C: +1 650-2833815 (USA)
> M: +44 (0)7591540313 (UK, Europe)
> W: http://about.me/liviutudor <http://about.me/liviutudor>
> Skype: liviutudor
>  
> I'm nobody, nobody's perfect -- therefore I'm perfect!
>
>  
>
>
>
>



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


Mime
View raw message