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.tu...@gmail.com <mailto:liviu.tu...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
