You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Gamba <ho...@handelshof.de> on 2009/09/18 10:43:04 UTC
ERROR [EventStateCollection] Unable to resolve path for item ...
Hi,
I'm testing jackrabbit on jboss. Access from the tests ist per rmi, on the
server-side in a session bean delegating to a thread-safe singleton class I
get the following error outputs when starting 5 threads concurrently. Each
thread adds only one folder under the Path jcr:root/HMG/.
As you can see the first folders are created successfully. Running the test
with 2 or 3 threads there are no errors, but with 5 or more ...
10:32:01,000 INFO [SessionSingleton] Folder TEST_JCR_NODE_6027045 in path
HMG added by Thread : WorkerThread#1[127.0.0.1:3651]
10:32:01,000 INFO [SessionSingleton] Folder TEST_JCR_NODE_1267850195 in
path HMG added by Thread : WorkerThread#2[127.0.0.1:3653]
10:32:01,015 INFO [SessionSingleton] Folder TEST_JCR_NODE_-209488179 in
path HMG added by Thread : WorkerThread#3[127.0.0.1:3654]
10:32:01,015 INFO [SessionSingleton] Folder TEST_JCR_NODE_501045637 in path
HMG added by Thread : WorkerThread#0[127.0.0.1:3652]
10:32:01,015 INFO [SessionSingleton] Folder TEST_JCR_NODE_-2042129268 in
path HMG added by Thread : WorkerThread#4[127.0.0.1:3655]
10:32:01,078 INFO [SessionSingleton] Folder HMG/TEST_JCR_NODE_6027045
deleted by Thread: WorkerThread#1[127.0.0.1:3651]
10:32:01,078 ERROR [EventStateCollection] Unable to resolve path for item:
f0479fa2-cab1-4ded-81f4-46a3d9d926ad/{http://www.jcp.org/jcr/1.0}primaryType
10:32:01,078 INFO [SessionSingleton] Folder HMG/TEST_JCR_NODE_1267850195
deleted by Thread: WorkerThread#2[127.0.0.1:3653]
10:32:01,109 ERROR [EventStateCollection] Unable to resolve path for item:
cb627868-bfac-4e43-a0f7-447f369120f9/{http://www.jcp.org/jcr/1.0}primaryType
10:32:01,203 ERROR [EventStateCollection] Unable to resolve path for item:
9f3e46c9-d33d-49c0-8203-db68da6fcb54/{http://www.jcp.org/jcr/1.0}primaryType
What does the error: ERROR [EventStateCollection] Unable to resolve path for
item ... mean?
I ask myself what the number behind the " ... path for item. XYZ" means? Is
it the UUID? I can't believe
that because my nodes are from the type nt:unstructured and not
mix:referencable.
By the way, inside my unit-test I get a TransactionRollbackException:
java.lang.RuntimeException: javax.transaction.RollbackException:
[com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted]
[com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't
commit because the transaction is in aborted state
at
org.jboss.aspects.tx.TxPolicy.handleEndTransactionException(TxPolicy.java:198)
at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:180)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
...
But I think this is the result of the "Unable to resolve path ..." - error.
Regards,
Gamba
--
View this message in context: http://www.nabble.com/ERROR--EventStateCollection--Unable-to-resolve-path-for-item-...-tp25505035p25505035.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: ERROR [EventStateCollection] Unable to resolve path for item
...
Posted by Gamba <ho...@handelshof.de>.
Sometimes in my unit-tests I get the following server-side-error, without
further exception.
Only this output ...
ERROR [SharedItemStateManager] Unable to create event state collection.
... on the client-side I get a Transaction-Rollback-Exception ...
What does this ERROR mean?
Thx,
Gamba
Gamba wrote:
>
> Thx for the hint with the UUIDs.
>
> Sure, I totally agree with you it could be an concurrency problem, because
> I'm not able ro reproduce this exceptions at the moment. During the tests
> some other excpetions occurs e.g "inactive logical session handle called"
> or
>
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist
> resource, see the previous warnings. tx=TransactionImple < ac,
> BasicAction: a11359c:48a:4ab35912:269d status: ActionStatus.ABORT_ONLY >
> at
> org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:759)
> at ...
>
> So, indeed, it looks like a concurrency problem. But I have a
> singleton-instance which should be thread-safe (only one access-point to
> jcr) and I did not expect such a behaviour. Here is the singleton code:
>
> public final class SessionSingleton
> {
> private final static Logger log =
> Logger.getLogger(SessionSingleton.class);
>
> // Made final so singleton will be read-only
> private final static SessionSingleton instance;
>
> // Static initializer
> static {
> try {
> // Perform initialization here
> instance = new SessionSingleton();
>
> if (log.isDebugEnabled()) {
> log.debug("New SessionSingleton Instance created ...");
> }
> }
> catch (Throwable e) {
> throw new RuntimeException(e.getMessage());
> }
> }
>
> // private construktor
> private SessionSingleton()
> {}
>
> // get Singleton-Instance
> public static SessionSingleton getInstance() {
> if (log.isDebugEnabled()) {
> System.out.println("Retrieving SessionSingleton instance ...");
> }
> return instance;
> }
>
> // -----
> // Methods for JCR-Access
> // -----
> public void createFolderNode(String path, String name, Repository
> repository)
> throws HMGJCRException, RepositoryException
> {
> synchronized (instance) {
> Session session = null;
> Node lastNodeInTree = null;
>
> try {
> // JackRabbit Zugriff über JNDI
> session = repository.login(new SimpleCredentials("user",
> "pwd".toCharArray()), "default");
>
> Node rootNode = session.getRootNode();
> lastNodeInTree = rootNode.getNode(path);
> Node addedNode = null;
>
> if (!lastNodeInTree.hasNode(name)) {
> addedNode = lastNodeInTree.addNode(name);
> }
> else {
> throw new HMGJCRException("Folder " + name + " in path " + path + "
> already existis");
> }
>
> if (log.isInfoEnabled()) {
> log.info("Folder " + name + " in path " + path + " added by Thread :
> " +
>
> Thread.currentThread().getName());
> }
>
> session.save();
> }
> finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> }
> }
>
> public void deleteFolderNode(String path, Repository repository)
> throws RepositoryException
> {
> synchronized (instance) {
> Session session = null;
> Node oldNode = null;
>
> try {
> // JackRabbit Zugriff über JNDI
> session = repository.login(new SimpleCredentials("user",
> "pwd".toCharArray()), "default");
>
> Node rootNode = session.getRootNode();
>
> if (rootNode.hasNode(path)) {
> oldNode = rootNode.getNode(path);
> // oldNode.lock(true, true);
> oldNode.remove();
>
> if (log.isInfoEnabled()) {
> log.info("Folder " + path + " deleted by Thread: " +
>
> Thread.currentThread().getName());
> }
> }
> else {
> if (log.isInfoEnabled()) {
> log.info("Folder " + path + " not found by Thread: " +
>
> Thread.currentThread().getName());
> }
> }
>
> session.save();
> }
> finally {
> if (session != null) {
> session.logout();
> session = null;
> }
> }
> }
> }
> }
>
> Regards,
> Gamba
>
>
--
View this message in context: http://www.nabble.com/ERROR--EventStateCollection--Unable-to-resolve-path-for-item-...-tp25505035p25530243.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: ERROR [EventStateCollection] Unable to resolve path for item
...
Posted by Gamba <ho...@handelshof.de>.
Thx for the hint with the UUIDs.
Sure, I totally agree with you it could be an concurrency problem, because
I'm not able ro reproduce this exceptions at the moment. During the tests
some other excpetions occurs e.g "inactive logical session handle called" or
javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist
resource, see the previous warnings. tx=TransactionImple < ac, BasicAction:
a11359c:48a:4ab35912:269d status: ActionStatus.ABORT_ONLY > at
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:759)
at ...
So, indeed, it looks like a concurrency problem. But I have a
singleton-instance which should be thread-safe (only one access-point to
jcr) and I did not expect such a behaviour. Here is the singleton code:
public final class SessionSingleton
{
private final static Logger log = Logger.getLogger(SessionSingleton.class);
// Made final so singleton will be read-only
private final static SessionSingleton instance;
// Static initializer
static {
try {
// Perform initialization here
instance = new SessionSingleton();
if (log.isDebugEnabled()) {
log.debug("New SessionSingleton Instance created ...");
}
}
catch (Throwable e) {
throw new RuntimeException(e.getMessage());
}
}
// private construktor
private SessionSingleton()
{}
// get Singleton-Instance
public static SessionSingleton getInstance() {
if (log.isDebugEnabled()) {
System.out.println("Retrieving SessionSingleton instance ...");
}
return instance;
}
// -----
// Methods for JCR-Access
// -----
public void createFolderNode(String path, String name, Repository
repository)
throws HMGJCRException, RepositoryException
{
synchronized (instance) {
Session session = null;
Node lastNodeInTree = null;
try {
// JackRabbit Zugriff über JNDI
session = repository.login(new SimpleCredentials("user",
"pwd".toCharArray()), "default");
Node rootNode = session.getRootNode();
lastNodeInTree = rootNode.getNode(path);
Node addedNode = null;
if (!lastNodeInTree.hasNode(name)) {
addedNode = lastNodeInTree.addNode(name);
}
else {
throw new HMGJCRException("Folder " + name + " in path " + path + "
already existis");
}
if (log.isInfoEnabled()) {
log.info("Folder " + name + " in path " + path + " added by Thread : "
+
Thread.currentThread().getName());
}
session.save();
}
finally {
if (session != null) {
session.logout();
session = null;
}
}
}
}
public void deleteFolderNode(String path, Repository repository)
throws RepositoryException
{
synchronized (instance) {
Session session = null;
Node oldNode = null;
try {
// JackRabbit Zugriff über JNDI
session = repository.login(new SimpleCredentials("user",
"pwd".toCharArray()), "default");
Node rootNode = session.getRootNode();
if (rootNode.hasNode(path)) {
oldNode = rootNode.getNode(path);
// oldNode.lock(true, true);
oldNode.remove();
if (log.isInfoEnabled()) {
log.info("Folder " + path + " deleted by Thread: " +
Thread.currentThread().getName());
}
}
else {
if (log.isInfoEnabled()) {
log.info("Folder " + path + " not found by Thread: " +
Thread.currentThread().getName());
}
}
session.save();
}
finally {
if (session != null) {
session.logout();
session = null;
}
}
}
}
}
Regards,
Gamba
--
View this message in context: http://www.nabble.com/ERROR--EventStateCollection--Unable-to-resolve-path-for-item-...-tp25505035p25507216.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: ERROR [EventStateCollection] Unable to resolve path for item ...
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Sep 18, 2009 at 10:43, Gamba <ho...@handelshof.de> wrote:
> 10:32:01,203 ERROR [EventStateCollection] Unable to resolve path for item:
> 9f3e46c9-d33d-49c0-8203-db68da6fcb54/{http://www.jcp.org/jcr/1.0}primaryType
>
> What does the error: ERROR [EventStateCollection] Unable to resolve path for
> item ... mean?
> I ask myself what the number behind the " ... path for item. XYZ" means? Is
> it the UUID? I can't believe
> that because my nodes are from the type nt:unstructured and not
> mix:referencable.
Jackrabbit internally uses UUIDs to identify nodes (this goes down
into the persistence manager). If a node is mix:referencable, that
UUID is exposed as the node's UUID.
Regarding your problem it could be a concurrency issue. JCR sessions
are not thread safe.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com