Return-Path: X-Original-To: apmail-cayenne-user-archive@www.apache.org Delivered-To: apmail-cayenne-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 65FC79DD4 for ; Mon, 12 Dec 2011 18:23:06 +0000 (UTC) Received: (qmail 15923 invoked by uid 500); 12 Dec 2011 18:23:06 -0000 Delivered-To: apmail-cayenne-user-archive@cayenne.apache.org Received: (qmail 15903 invoked by uid 500); 12 Dec 2011 18:23:06 -0000 Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cayenne.apache.org Delivered-To: mailing list user@cayenne.apache.org Received: (qmail 15895 invoked by uid 99); 12 Dec 2011 18:23:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Dec 2011 18:23:06 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.210.171] (HELO mail-iy0-f171.google.com) (209.85.210.171) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Dec 2011 18:22:58 +0000 Received: by iaen33 with SMTP id n33so14329905iae.16 for ; Mon, 12 Dec 2011 10:22:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.173.4 with SMTP id bg4mr15958555igc.42.1323714157081; Mon, 12 Dec 2011 10:22:37 -0800 (PST) Sender: chris@strandz.org Received: by 10.231.169.213 with HTTP; Mon, 12 Dec 2011 10:22:36 -0800 (PST) In-Reply-To: References: <4CC0C744-1DD4-43A7-ADE6-C0426BA81D63@roxanemy.com> <05E8F825-5AC9-446A-AF38-5E190F6EF424@roxanemy.com> <2FE74A81-D80B-4F7C-813C-0E5C5F9EFD45@roxanemy.com> Date: Tue, 13 Dec 2011 05:22:36 +1100 X-Google-Sender-Auth: ijoC1wBcoxzyNL-hDGleeAaAQzw Message-ID: Subject: Re: Continual creation is a memory leak From: Chris Murphy To: user@cayenne.apache.org Content-Type: multipart/alternative; boundary=e89a8f642ec41df3d804b3e93826 --e89a8f642ec41df3d804b3e93826 Content-Type: text/plain; charset=ISO-8859-1 I'm using JProfiler to look for memory leaks. I've used it to see that they've been plugged since I implemented Robert's suggestion of having a separate temporary DataContext that gets garbage collected, collecting the Reading data objects with it. I now think that garbage collection being the reason for three connections to be required is quite silly! If a connection is ready for garbage collection then it won't be visible to the Cayenne code. The Cayenne code is baulking because two connections are currently in use and a third is required to execute a query (that's my understanding of the error message). To really see the cause of the problem it would be good if the "Too many connections" stack trace told us what the other two connections are being used for. Alternatively the instrumention at the DEBUG logging level might show connections being picked up and released, and I would be able to work out why the other two are being held from there. ~ Chris Murphy On 13 December 2011 00:50, Durchholz, Joachim < Joachim.Durchholz@hennig-fahrzeugteile.de> wrote: > > Perhaps the garbage collector thinks that its okay to leave around such > a small amount of garbage for more than a minute. > > > > Am I right?? It sounds weird that a garbage collector can cause a > program to crash! > > Probably not. Garbage collectors will kick in after a certain threshold > has been reached, and that threshold is usually set at the end of the last > cycle. > In other words, unless you have a real memory leak, the collector should > keep the memory footprint stable. It's part of its job description. > (The actual mechanism is far more complicated, but that's the bottom line). > > If you are using Sun's Java 6, you can monitor memory usage via JVisualVM, > which comes as part of the JDK. > JVisualVM also works well for Sun's Java 5 runtime. You'll have slightly > reduced functionality and you need to supply an extra -D parameter to the > Java 5 RE, but it does give you the pretty real-time graphs. That tool > helped me a ton, a year or two ago, with little hassle for set-up, despite > being tied to Java 5 at that time. (JVisualVM will even give you statistics > about which data types take up most memory, show you all objects of a type, > and will even do a breadth-first search for a stack frame that's keeping > any given object alive. I'm not 100% sure how much of this is available for > Java 5, but if Java 5 fails you can still try Java 6.) > > HTH > Jo > --e89a8f642ec41df3d804b3e93826--