[
https://issues.apache.org/jira/browse/JCR-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728690#comment-14728690
]
Bart van der Schans commented on JCR-2483:
------------------------------------------
Hi.
This issue and JCR-3905 are indeed related. I think we need to address two
things:
1. The doSync should do some kind of batched retrieval and processing to
prevent out of memory errors
2. Prevent reading too many/unneeded journal records on startup.
Solving the first problem should make the second issue merely an annoyance of
slow startups.
The second issue arises when a full reindex is done. This can be either when a
new node is added to a cluster or when a node is started without and existing
lucene index to force a full reindex. When a full reindex is detected, before
it starts indexing, it should save the current revision the cluster is add.
When the re-index is done, the local revision can be set to that saved revision
and only journal entries from that revision need to be synced.
The sync limit option looks to me like a "guessing" solution to the second
issue. I you guessed wrongly and more than the sync limit records needed
syncing, it will render the cluster in an inconsistent state.
Regards,
Bart
> 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
> Affects Versions: 1.6
> Environment: MySQL DB. 512 MB memory allocated to java app.
> Reporter: aasoj
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
