Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 70606 invoked from network); 3 Feb 2010 10:59:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Feb 2010 10:59:50 -0000 Received: (qmail 5823 invoked by uid 500); 3 Feb 2010 10:59:49 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 5753 invoked by uid 500); 3 Feb 2010 10:59:49 -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 5745 invoked by uid 99); 3 Feb 2010 10:59:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 10:59:49 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 10:59:48 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 4FAD5234C4A9 for ; Wed, 3 Feb 2010 02:59:28 -0800 (PST) Message-ID: <1112269994.571265194768324.JavaMail.jira@brutus.apache.org> Date: Wed, 3 Feb 2010 10:59:28 +0000 (UTC) From: "aasoj (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Updated: (JCR-2483) Out of memory error while adding a new host due to large number of revisions In-Reply-To: <1353728499.21265193928596.JavaMail.jira@brutus.apache.org> 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-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] aasoj updated JCR-2483: ----------------------- Attachment: patch > Out of memory error while adding a new host due to large number of revisions > ---------------------------------------------------------------------------- > > Key: JCR-2483 > URL: https://issues.apache.org/jira/browse/JCR-2483 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: clustering > Environment: MySQL DB. 512 MB memory allocated to java app. > Reporter: aasoj > Fix For: 1.6.0 > > Attachments: patch > > > In a cluster deployment, revisions are saved in Journal Table in the DB. After a while a huge number of revisions can get created (around 70 k in our test). When a new host is added to the cluster, it tries to read all the revisions and hence the following error: > Caused by: java.lang.OutOfMemoryError: Java heap space > at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2931) > at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2871) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3414) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:910) > at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1405) > at com.mysql.jdbc.MysqlIO.readSingleRowSet(MysqlIO.java:2816) > at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:467) > at com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:2510) > at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:1746) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2135) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2542) > at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1734) > at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:995) > at org.apache.jackrabbit.core.journal.DatabaseJournal.getRecords(DatabaseJournal.java:460) > at org.apache.jackrabbit.core.journal.AbstractJournal.doSync(AbstractJournal.java:201) > at org.apache.jackrabbit.core.journal.AbstractJournal.sync(AbstractJournal.java:188) > at org.apache.jackrabbit.core.cluster.ClusterNode.sync(ClusterNode.java:329) > at org.apache.jackrabbit.core.cluster.ClusterNode.start(ClusterNode.java:270) > This can also happen to an existing host in the cluster when the number of revisions returned is very high. > Possible solutions: > 1. Cleaning old revisions using Janitor thread: This may be good for new hosts. But it will fail in a scenario when sync delay is high (few hours) and number of updates is high in existing hosts in the cluster > 2. Increases memory allocated to Java process: This is not a feasible option always > 3. Limit the number of updates read from the DB in any cycle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.