Return-Path: X-Original-To: apmail-jackrabbit-dev-archive@www.apache.org Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5341E8BCB for ; Thu, 1 Sep 2011 14:13:40 +0000 (UTC) Received: (qmail 7151 invoked by uid 500); 1 Sep 2011 14:13:40 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 7046 invoked by uid 500); 1 Sep 2011 14:13:39 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 7039 invoked by uid 99); 1 Sep 2011 14:13:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2011 14:13:39 +0000 X-ASF-Spam-Status: No, hits=-2000.5 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2011 14:13:36 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 187EC4A349 for ; Thu, 1 Sep 2011 14:13:15 +0000 (UTC) Date: Thu, 1 Sep 2011 14:13:15 +0000 (UTC) From: "Danilo Ghirardelli (JIRA)" To: dev@jackrabbit.apache.org Message-ID: <435751587.6819.1314886395096.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <565820444.19027.1297811157592.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (JCR-2892) Large fetch sizes have potentially deleterious effects on VM memory requirements when using Oracle MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/JCR-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095306#comment-13095306 ] Danilo Ghirardelli commented on JCR-2892: ----------------------------------------- I have the same problem, 10000 in fetch size is causing out of memory, even jackrabbit version 2.2.8. In my case it seems to be triggered by clustering configuration, because probably that will return more than a single row, and in this case oracle will allocate all the necessary ram for about 10000 rows. You can try with Oracle 10 (XE edition also causes the problem), driver 10.2.0.4 (or 10.2.0.5), default java xms size (32 bit version, not 64, on Windows platform) and clustering configured. The simple existence of clustering causes the crash in my case, you may want to save a few nodes to force something in the clustering tables. Anyway, that size of fetch size is dangerous. If it was set only to limit postgresql allocation and you are sure that the average query will return a single record, you should hardcode it to 10... I tried that the application will start correctly with a value of 10 and 100 but not with 1000 or above. > Large fetch sizes have potentially deleterious effects on VM memory requirements when using Oracle > -------------------------------------------------------------------------------------------------- > > Key: JCR-2892 > URL: https://issues.apache.org/jira/browse/JCR-2892 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core, sql > Affects Versions: 2.2.2 > Environment: Oracle 10g+ > Reporter: Christopher Elkins > > Since Release 10g, Oracle JDBC drivers use the fetch size to allocate buffers for caching row data. > cf. http://www.oracle.com/technetwork/database/enterprise-edition/memory.pdf > r1060431 hard-codes the fetch size for all ResultSet-returning statements to 10,000. This value has significant, potentially deleterious, effects on the heap space required for even moderately-sized repositories. For example, the BUNDLE table (from 'oracle.ddl') has two columns -- NODE_ID raw(16) and BUNDLE_DATA blob -- which require 16 b and 4 kb of buffer space, respectively. This requires a buffer of more than 40 mb [(16+4096) * 10000 = 41120000]. > If the issue described in JCR-2832 is truly specific to PostgreSQL, I think its resolution should be moved to a PostgreSQL-specific ConnectionHelper subclass. Failing that, there should be a way to override this hard-coded value in OracleConnectionHelper. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira