Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Mon, 06 Feb 2006 16:23:47 +0100
From: John Embretsen <John.Embretsen@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-210) Network Server will leak prepared
 statements if not explicitly closed by the user until the connection is
 closed
In-reply-to: <43E1C6A9.5000504@Sun.COM>
To: derby-dev@db.apache.org
Message-id: <43E76A03.7020308@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930)
References: <1656324081.1138801568878.JavaMail.jira@ajax.apache.org>
 <43E0E636.2020908@amberpoint.com> <43E1C6A9.5000504@Sun.COM>

John Embretsen wrote:

> I suspect there will be other issues that are uncovered by running the
> DOTS test case (or variations of it) with various configurations, but
> they may or may not be related to this particular issue. I will
> certainly let you know as soon as possible if I notice any memory leaks.
> I will run the test against a patched Derby trunk for a while longer,
> and see how it goes.

Here's an update:

I was running the DOTS test case (unmodified) this weekend using a
maximum number of 20 concurrent db connections. The Network Server threw
an "OutOfMemoryError: PermGen space" about 55 hours into the test run,
with same heap size as earlier (128 MB heap, 64 MB PermSpace).

So it seems that the patch does not completely eliminate the problem
associated with that particular test case. However, I do not believe
this test failure is a showstopper for the patch. More testing is needed
in order to determine if the failure is caused by
    * lack of explicitly closing all statements
    * using/compiling too many different statements (i.e., more than the
current heap size can handle)
    * something else
    * a combination of the above


-- 
John