commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Tudor <liviu.tu...@gmail.com>
Subject [pool] Question / potential improvement on KeyedObjectPool
Date Tue, 10 Jul 2012 21:51:49 GMT
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.)

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!

 




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message