From dev-return-32503-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Tue Oct 4 08:30:58 2011 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 B4CEA765D for ; Tue, 4 Oct 2011 08:30:58 +0000 (UTC) Received: (qmail 31497 invoked by uid 500); 4 Oct 2011 08:30:58 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 31409 invoked by uid 500); 4 Oct 2011 08:30:58 -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 31402 invoked by uid 99); 4 Oct 2011 08:30:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Oct 2011 08:30:58 +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; Tue, 04 Oct 2011 08:30:57 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 2D5B02A77ED for ; Tue, 4 Oct 2011 08:30:36 +0000 (UTC) Date: Tue, 4 Oct 2011 08:30:36 +0000 (UTC) From: "Danilo Ghirardelli (Commented) (JIRA)" To: dev@jackrabbit.apache.org Message-ID: <1693077354.6619.1317717036187.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 [ https://issues.apache.org/jira/browse/JCR-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119959#comment-13119959 ] Danilo Ghirardelli commented on JCR-2892: ----------------------------------------- The linked issue JCR-3090 addressed the same issue in a different way: every call to the "reallyExec" method (where the setFetchSize is set) has the maxRows value set to 0, so the patch for that issue is simply indirectly disabling the fetch size hint. This would probably solve the problem of this issue but will probably re-open the problem stated in JCR-2832. By the way, just like Manuel, I also used Magnolia CMS (with clustering) on Tomcat to reproduce the problem. > 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 > Attachments: oracleFetchSize.patch > > > 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira