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.tu...@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.ste...@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.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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
