From dev-return-7729-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Fri Jul 09 23:05:33 2004 Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 71277 invoked from network); 9 Jul 2004 23:05:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 9 Jul 2004 23:05:32 -0000 Received: (qmail 94947 invoked by uid 500); 9 Jul 2004 23:05:23 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 94895 invoked by uid 500); 9 Jul 2004 23:05:23 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@geronimo.apache.org Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 94882 invoked by uid 99); 9 Jul 2004 23:05:23 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.233.18.245] (HELO public.coredevelopers.net) (209.233.18.245) by apache.org (qpsmtpd/0.27.1) with ESMTP; Fri, 09 Jul 2004 16:05:21 -0700 Received: from [192.168.17.120] (unknown [69.111.157.225]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by public.coredevelopers.net (Postfix on SuSE Linux 8.0 (i386)) with ESMTP id AB48849F51 for ; Fri, 9 Jul 2004 16:02:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <98B7B9B4-D1F2-11D8-AE37-003065F4889C@coredevelopers.net> References: <98B7B9B4-D1F2-11D8-AE37-003065F4889C@coredevelopers.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7186B6D9-D1FC-11D8-9841-000393DB559A@coredevelopers.net> Content-Transfer-Encoding: 7bit From: Dain Sundstrom Subject: Re: Thread pool strategy Date: Fri, 9 Jul 2004 16:05:17 -0700 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.618) X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Jul 9, 2004, at 2:54 PM, David Jencks wrote: > What I have now is a gbean that: > > --interface: > you can either use Executor through the GBean calling mechanism or if > you think that is too slow get the underlying Executor itself. GBean proxies are very fast, so I doubt that this direct hook is needed. On my mac the overhead of an invocation 300ns, and on a decently fast computer it is well under 100ns. Anyway, I suggest we remove the direct hook (and any others we may have) until it is proven to be a performance problem, as a GBean proxy is controllable so we can reduce the possibility of memory leaks. > --implementation > Uses a PooledExecutor with a fixed minsize = maxsize and a LinkedQueue > to put waiting requests on. This will keep creating threads until it > is full, then put tasks on the queue and freed up threads will take > them off. This uses standard Concurrent classes only. As far as I > can tell any other behavior would require us to write some code, which > I would expect to contain some bugs. Until we see an actual problem > with this strategy I'l like to leave well enough alone. My original > question was whether anyone knew of problems we would be likely to run > into using this strategy. Works for me. -dain