jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Carlos Campanero (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3570) Make immediately Repository start configureable in JCAManagedConnectionFactory
Date Wed, 12 Feb 2014 18:11:20 GMT

    [ https://issues.apache.org/jira/browse/JCR-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13899361#comment-13899361
] 

Jose Carlos Campanero commented on JCR-3570:
--------------------------------------------

Something very similar to that indicated by Claudiu happens in the following scenario: in
our web application we use Jackrabbit embedded. This application is deployed on a cluster
of Weblogic: as part of its initialization process the application checks if the repository
is created, creating it through org.apache.jackrabbit.core.config.RepositoryConfig.create
otherwise. At this time log traces similar to those shown by Claudiu originate.

The environment consists of Weblogic 10.3.4 on RHEL 5.5 and Oracle 11g.
Jackrabbit version is 2.2.11.

Given the wealth of information that can be handled and the consequent delay in the start,
initialization of the repository after the first login might be inappropriate. Would it be
possible to synchronize in some other way this process?

> Make immediately Repository start configureable in JCAManagedConnectionFactory
> ------------------------------------------------------------------------------
>
>                 Key: JCR-3570
>                 URL: https://issues.apache.org/jira/browse/JCR-3570
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: clustering
>    Affects Versions: 2.6
>         Environment: Linux jaguar 2.6.32-262.el6.x86_64 #1 SMP Sun Apr 8 18:38:00 EDT
2012 x86_64 x86_64 x86_64 GNU/Linux 
> Jackrabbit 2.6.0 JCA deployed on JBoss AS 7.1.0.final cluster configuration (domain setup
with 2 managed server instances on the same machine)
>            Reporter: Claudiu Muresan
>            Assignee: Claus Köll
>            Priority: Blocker
>             Fix For: 2.6.1, 2.7
>
>         Attachments: JCR-3570.patch, repository_server1.xml, repository_server2.xml
>
>
> The 2 managed server instances are deployed jackrabbit-jca.rar archive using jboss cli.
> repository.xml is available for both instances at locations:
> (instance1 = server1 : /opt/kmp/jboss-7.1.0.Final/domain/servers/server1/data/jackrabbit)
> (instance2 = server2 : /opt/kmp/jboss-7.1.0.Final/domain/servers/server2/data/jackrabbit)
> The difference between the 2 repository xml files is given by the name of the cluster
node.
> server1 is known as node1 in Jackrabbit cluster
> server2 is known as node2 in Jackrabbit cluster
> JBoss starts the deployment of jackrabbit rar archive in the same time. Please note that
Jackrabbit tables/indexes have been created using an SQL script prior to jackrabbit deployment.
No data is added into the tables.
> One of the managed server instances e.g. server1 is able to add the the implicit node
type definitions as bundles into version_bundle and default_bundle respectively. The problem
is that the other managed server is trying to also store the bundles and we have a referential
integrity error.
> server2 instance fails with below exception:
> 12:14:11,502 ERROR [org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager]
(MSC service thread 1-3) FATAL error while writing the bundle: deadbeef-face-babe-cafe-babecafebabe:
java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (DBUSER_LOGAN.IDX_VERSION_BUNDLE_NODE_ID)
violated
>         at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:445) [ojdbc6.jar:11.2.0.3.0]
>         at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:396) [ojdbc6.jar:11.2.0.3.0]
>         at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:879) [ojdbc6.jar:11.2.0.3.0]
>         at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:450) [ojdbc6.jar:11.2.0.3.0]
>         at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:192) [ojdbc6.jar:11.2.0.3.0]
>         at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:531) [ojdbc6.jar:11.2.0.3.0]
>         at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:207)
[ojdbc6.jar:11.2.0.3.0]
>         at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1044)
[ojdbc6.jar:11.2.0.3.0]
>         at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1329)
[ojdbc6.jar:11.2.0.3.0]
>         at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3584)
[ojdbc6.jar:11.2.0.3.0]
>         at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3685)
[ojdbc6.jar:11.2.0.3.0]
>         at oracle.jdbc.driver.OraclePreparedStatementWrapper.execute(OraclePreparedStatementWrapper.java:1376)
[ojdbc6.jar:11.2.0.3.0]
>         at org.jboss.jca.adapters.jdbc.CachedPreparedStatement.execute(CachedPreparedStatement.java:297)
>         at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.execute(WrappedPreparedStatement.java:404)
>         at org.apache.jackrabbit.core.util.db.ConnectionHelper.execute(ConnectionHelper.java:516)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.util.db.ConnectionHelper.reallyUpdate(ConnectionHelper.java:344)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.util.db.ConnectionHelper$2.call(ConnectionHelper.java:331)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.util.db.ConnectionHelper$2.call(ConnectionHelper.java:327)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.util.db.ConnectionHelper$RetryManager.doTry(ConnectionHelper.java:550)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.util.db.ConnectionHelper.update(ConnectionHelper.java:327)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.storeBundle(BundleDbPersistenceManager.java:950)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.putBundle(AbstractBundlePersistenceManager.java:799)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.storeInternal(AbstractBundlePersistenceManager.java:714)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.store(AbstractBundlePersistenceManager.java:590)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.store(BundleDbPersistenceManager.java:482)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.version.InternalVersionManagerImpl.<init>(InternalVersionManagerImpl.java:174)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.RepositoryImpl.createVersionManager(RepositoryImpl.java:492)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:311)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:589)
[jackrabbit-core-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.jca.JCARepositoryManager.createNonTransientRepository(JCARepositoryManager.java:124)
[jackrabbit-jca-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.jca.JCARepositoryManager.createRepository(JCARepositoryManager.java:79)
[jackrabbit-jca-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createRepository(JCAManagedConnectionFactory.java:209)
[jackrabbit-jca-2.6.0.jar:2.6.0]
>         at org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createConnectionFactory(JCAManagedConnectionFactory.java:147)
[jackrabbit-jca-2.6.0.jar:2.6.0]
> How can we overcome this situation?
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message