Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 77951 invoked from network); 15 Dec 2006 20:33:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Dec 2006 20:33:49 -0000 Received: (qmail 84121 invoked by uid 500); 15 Dec 2006 20:33:53 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 84029 invoked by uid 500); 15 Dec 2006 20:33:52 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 83977 invoked by uid 99); 15 Dec 2006 20:33:52 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Dec 2006 12:33:52 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Dec 2006 12:33:44 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id DE87A71413D for ; Fri, 15 Dec 2006 12:33:23 -0800 (PST) Message-ID: <25186757.1166214803908.JavaMail.jira@brutus> Date: Fri, 15 Dec 2006 12:33:23 -0800 (PST) From: "Ben Speakmon (JIRA)" To: commons-dev@jakarta.apache.org Subject: [jira] Commented: (POOL-91) StackObjectPool.borrowObject infinate loop when makeObject returns null In-Reply-To: <16577190.1164138062002.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ http://issues.apache.org/jira/browse/POOL-91?page=comments#action_12458919 ] Ben Speakmon commented on POOL-91: ---------------------------------- I'm interested in the decorated factory approach -- how would you see that API working? Sandy, your point about the concurrent library being fundamentally different in approach from commons-pool is well taken; perhaps it would be helpful if I explained how I've seen pool. I thought of pool as a general-purpose pool including support for threads as well as POJOs, and under that assumption the ThreadPoolExecutor approach made good sense. Of course when you're pooling heavyweight objects that don't implement Runnable, the thread-based approach doesn't really apply, and the callback is overkill. If pool isn't about threads, and the answer to someone who wants thread pooling is to either use JDK 5 or util.concurrent, then I'm perfectly happy with that. However, on a purely API basis, I'd still like to entertain the idea of not forcing the client to catch a checked exception when borrowing an object. A factory approach could lead that way, and I'd be interested to see where that leads. > StackObjectPool.borrowObject infinate loop when makeObject returns null > ----------------------------------------------------------------------- > > Key: POOL-91 > URL: http://issues.apache.org/jira/browse/POOL-91 > Project: Commons Pool > Issue Type: Bug > Reporter: Sandy McArthur > Assigned To: Sandy McArthur > Attachments: sample-borrow-fail-pool-policy.tar.bz2 > > > StackObjectPool.borrowObject has a infinate loop when makeObject returns null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org