Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id ACD29D0F0 for ; Tue, 10 Jul 2012 21:52:25 +0000 (UTC) Received: (qmail 4997 invoked by uid 500); 10 Jul 2012 21:52:24 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 4882 invoked by uid 500); 10 Jul 2012 21:52:24 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 4873 invoked by uid 99); 10 Jul 2012 21:52:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Jul 2012 21:52:24 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of liviu.tudor@gmail.com designates 209.85.160.171 as permitted sender) Received: from [209.85.160.171] (HELO mail-gh0-f171.google.com) (209.85.160.171) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Jul 2012 21:52:18 +0000 Received: by ghy10 with SMTP id 10so734256ghy.30 for ; Tue, 10 Jul 2012 14:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=Dd/0Jz9TGw/4AAPh94Yq3zD+PZ4i2U3jwqdtMP/c5yk=; b=JuCSXStMDZhNpe9iNAwXQLM1BIqrW2XYbcvmFC2m4Re2eM7/vu/kI4uHj92Pdibpgg ZCtgGuJb0pk2nYaHzdvR9yJKXmSPCJmNKqncE7Mre01R6TIwtzdsNvzqCugskAcFOuSN 2PZD8v9AULk/upn4QWT07wWO7CvFDy+CS2F2AFo14O9EWLhZLtsFlyLa1EWoPQvkI/xE XJK/IZGs+U2+lYDfiPUS57N+ZH1DIrIJueUHT0uMcwtqe/qZbJnhAcrIYiyPXJ+GyPXH sCqY8VxjlU8kYJZW1XWeySv7FeD8oSica9iyPqYSlu6m7tJCQd9fAhyttZ2i+ueaMQfu MNSQ== Received: by 10.66.82.2 with SMTP id e2mr76609407pay.67.1341957117069; Tue, 10 Jul 2012 14:51:57 -0700 (PDT) Received: from [192.168.1.146] (74-95-206-38-SFBA.hfc.comcastbusiness.net. [74.95.206.38]) by mx.google.com with ESMTPS id hf5sm302425pbc.4.2012.07.10.14.51.54 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 14:51:56 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Tue, 10 Jul 2012 14:51:49 -0700 Subject: [pool] Question / potential improvement on KeyedObjectPool From: Liviu Tudor To: Commons Developers List Message-ID: Thread-Topic: [pool] Question / potential improvement on KeyedObjectPool Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3424776711_29267610" X-Virus-Checked: Checked by ClamAV on apache.org --B_3424776711_29267610 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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 wil= l 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 use= d to create in advance N instances of certain classes and pool them. All thes= e 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 =8B 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 creat= e 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 = =8B 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 =8B however, in both cases, I would like to keep around N instances pre-created in the pool, for each class type. Now, my idea =8B and this is where (finally!) my question/suggestion comes in =8B 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 t= o N instances for each key (based of course also on the getNumIdle(Key) return).=20 The problem with that =8B as I found out soon =8B 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 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 s= o we could easily wrap up the keySet() into an unmodifiable set or similar if that makes sense.) Alternatively =8B and this is question two, and where this email can turn int= o a proposal for a commit of a new component/class =8B 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 =8B but happy to provide more details where necessary. Many thanks in advance, Liv=20 =20 Liviu Tudor =20 E: liviu.tudor@gmail.com C: +1 650-2833815 (USA) M: +44 (0)7591540313 (UK, Europe) W: http://about.me/liviutudor Skype: liviutudor =20 I'm nobody, nobody's perfect -- therefore I'm perfect! =20 --B_3424776711_29267610--