commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Tudor <liviu.tu...@gmail.com>
Subject Re: [pool] Question / potential improvement on KeyedObjectPool
Date Mon, 16 Jul 2012 18:16:14 GMT
Hi Phil,

Sorry to get onto this so late! I've just checked out the source code in
order to provide a patch at the same time as the JIRA ticket being
created, however, I see [pool] now is moving to pool2 -- my initial
suggestion was based on pool-1.6.0 (which is what I use in my
application). 

Are there any maintenance releases planned for pool-1.6 or should I
concentrate entirely (and apply this patch to) pool2?

Many thanks,


Liv 
 
Liviu Tudor
 
E: liviu.tudor@gmail.com
C: +1 650-2833815 (USA)
M: +44 (0)7591540313 (UK, Europe)
W: http://about.me/liviutudor
Skype: liviutudor
 
I'm nobody, nobody's perfect -- therefore I'm perfect!

 





On 11/07/2012 21:21, "Phil Steitz" <phil.steitz@gmail.com> 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
>>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
>



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


Mime
View raw message