Return-Path: Delivered-To: apmail-ofbiz-user-archive@www.apache.org Received: (qmail 71624 invoked from network); 1 Feb 2008 11:16:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Feb 2008 11:16:06 -0000 Received: (qmail 28167 invoked by uid 500); 1 Feb 2008 11:15:55 -0000 Delivered-To: apmail-ofbiz-user-archive@ofbiz.apache.org Received: (qmail 28158 invoked by uid 500); 1 Feb 2008 11:15:55 -0000 Mailing-List: contact user-help@ofbiz.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ofbiz.apache.org Delivered-To: mailing list user@ofbiz.apache.org Received: (qmail 28146 invoked by uid 99); 1 Feb 2008 11:15:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Feb 2008 03:15:55 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [195.6.159.187] (HELO smtp2.decathlon.com) (195.6.159.187) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Feb 2008 11:15:41 +0000 Received: from wlamsw02.subsidia.org (HELO wlamsw02.decathlon.com) ([192.168.1.185]) by smtp2.decathlon.com with ESMTP; 01 Feb 2008 12:17:09 +0100 X-IronPort-AV: i="4.25,289,1199660400"; d="scan'208"; a="30601822:sNHT95393984" Received: from nlaexb10.neptune.dkcorp.net (unverified) by wlamsw02.decathlon.com (Content Technologies SMTPRS 4.3.20) with SMTP id for ; Fri, 1 Feb 2008 12:12:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Stale DB-connections Date: Fri, 1 Feb 2008 12:15:24 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stale DB-connections Thread-Index: AchkNKe9kjD+B3LhRRiQO3IeQdg88QAjFNdA From: "LECOCQ Michel (CAMPUS)" To: X-Virus-Checked: Checked by ClamAV on apache.org Hello I've tested with the two connection factory classes (minerva and dbcp) on mysql and oracle databases. With minerva, no problem occured. With DBCP, the limit of pool-maxsize value from the datasource is not respected and the connections increase until reaching the connections max value defined on the database. The db-connections are not correctly removed too. Regards. Michael. -----Original Message----- From: David E Jones [mailto:jonesde@hotwaxmedia.com]=20 Sent: Thursday, January 31, 2008 7:10 PM To: user@ofbiz.apache.org Subject: Re: Stale DB-connections This is an interesting find Hans. Has anyone noticed, or tested, this with other databases (ie other than MySQL which is what Hans mentions testing with)? The big question in my mind is do we turn it off altogether, or make it a configurable option with recommended settings for different databases? If anyone can take a peek at their system(s) and offer feedback that would be great. -David On Jan 31, 2008, at 12:37 AM, Hans Holmlund wrote: > I have just upgraded to the latest version of Entity Engine and=20 > stumbled upon a problem. The problem I had was that db-connections=20 > were dropped after awhile but without actually closing the TCP session > with the database. So when I checked with netstat I had a lot of=20 > connections in a CLOSE_WAIT state. I'm using MySQL but I guess this=20 > may happen with other databases too. > I had a look in the code and come up with a fix. In=20 > DBCPConnectionFactory (row 96) there is a line saying: > pool.setTimeBetweenEvictionRunsMillis(600000); > > In GenericPool to set this parameter has the effect of creating an=20 > eviction thread, so every 10 minutes the pool will be checked if there > exist any unused objects. The problem seems to be when the object is=20 > evicted, I'm not sure what is happening but the object is not=20 > correctly removed. > I don't think that this cleaning procedure is necessary, if I have set > the pool-maxsize to 200 I can probably live with that the actual=20 > pool-size never shrinks. > So I made this change: > pool.setTimeBetweenEvictionRunsMillis(-1); > The eviction thread will not be created. And after I made this change=20 > I have not had any problems with stale DB-connections. > > / Hans Holmlund