commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Tudor <>
Subject Re: [pool] Question / potential improvement on KeyedObjectPool
Date Tue, 24 Jul 2012 06:42:48 GMT
Phil & others who have been in touch with [pool],

A follow up to this: I'm trying to log this in JIRA and submit a patch but
I've come across the following problem:

1/ The mechanism I am referring to had pool-1.6.0 in mind, however, I
can't find in SVN the branch for 1.6? There are release branches going up
to 1.5 but no 1.6? Can you point me in the right direction so I can create
the patch in the right branch?

2/ Since we've moved now to pool2, I would like to apply something similar
for [pool2], however, looking at the code, I see we now have a

    List<K> getKeys();

Due to the Mbean interface we're implementing. This looks similar to my
idea of returning a Set<K> for the keys -- since the order of the keys of
the cache is not important I thought. Looking at the code it turns out
indeed the order is not important, so List is not justified and Set could
have done it just fine. So am I ok to change the Mbean and the class to
actually use a Set rather than a List?

Liviu Tudor
C: +1 650-2833815 (USA)
M: +44 (0)7591540313 (UK, Europe)
Skype: liviutudor
I'm nobody, nobody's perfect -- therefore I'm perfect!


On 11/07/2012 21:21, "Phil Steitz" <> wrote:

>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
>> case I suppose that I've misunderstood certain things, in which case it
>> 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
>> as a "create (instances) and cache (them) ahead" in the sense that it's
>> to create in advance N instances of certain classes and pool them. All
>> 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,
>> obviously are not known ahead ‹ and because the application is a rather
>> high-throughput one, rather than creating these instances on demand
>> 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
>> in advance N instances of these "script" classes and then when the
>> 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
>> 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
>> 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
>> fixed intervals) which kicks in and goes through all the keys in the
>> 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
>> 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
>> 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.
>> Alternatively ‹ and this is question two, and where this email can turn
>> 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?
>> way I'm doing the pre population is by keeping a set of all the keys
>> were requested/removed (through borrowObject/preparePool/etc) -- and the
>> background thread iterates through these keys and creates instances
>> 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
>> to provide more details where necessary.
>> Many thanks in advance,
>> Liv 
>> Liviu Tudor
>> E: <>
>> C: +1 650-2833815 (USA)
>> M: +44 (0)7591540313 (UK, Europe)
>> W: <>
>> Skype: liviutudor
>> I'm nobody, nobody's perfect -- therefore I'm perfect!
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message