[
https://jira.jboss.org/jira/browse/DNA-546?page=com.atlassian.jira.plugin...
]
Brian Carothers updated DNA-546:
--------------------------------
Attachment: concurrency_issue.patch
I am still hitting semi-random failures in the TCK test if awaitAllSubtasks is false in
FederatedRepositoryConnector.execute(...) and the
JcrRepository.WORKSPACES_SHARE_SYSTEM_BRANCH flag is set to true.
I have added some logging to the SimpleJpaRequestProcessor to see what's going on, and
it looks like requests are getting interleaved. For example, I get the following
SetPropertyRequest and the adjacent read request executing at the same time:
08:55:29,250 [pool-3-thread-1] Executing [CompositeRequest (1)
set property {}prop1 on </{}testroot/{}node1 &&
[{http://www.jboss.org/dna/1.0}uuid = 3954dafa-8367-47f0-a421-0a28a529b73f]> in the
"default" workspace to
[org.jboss.dna.graph.property.basic.InMemoryBinary@25b64dbinary[0] with hash
2jmj7l5rSw0yVb/vlWAYkK/YBwk=]]
08:55:29,250 [pool-3-thread-3] Executing [CompositeRequest (3)
read node at / in the "default" workspace
read node at /{}testroot in the "default" workspace
read node at /{}testroot/{}node1 in the "default" workspace]
08:55:29,250 [pool-3-thread-3] Executed [CompositeRequest (3)
read node at / in the "default" workspace
read node at /{}testroot in the "default" workspace
read node at /{}testroot/{}node1 in the "default" workspace]
08:55:29,250 [pool-3-thread-3] Closing request processor
08:55:29,250 [pool-3-thread-3] Closed request processor
08:55:29,250 [pool-3-thread-1] Executed [CompositeRequest (1)
set property {}prop1 on </{}testroot/{}node1 &&
[{http://www.jboss.org/dna/1.0}uuid = 3954dafa-8367-47f0-a421-0a28a529b73f]> in the
"default" workspace to
[org.jboss.dna.graph.property.basic.InMemoryBinary@25b64dbinary[0] with hash
2jmj7l5rSw0yVb/vlWAYkK/YBwk=]]
08:55:29,250 [pool-3-thread-1] Closing request processor
08:55:29,250 [pool-3-thread-1] Closed request processor
Note how the set property request starts to execute on /testroot/node1, then a read
request for /testroot/node1 starts and completes before the set property request
completes. Since the read is part of a test to see if the property was set or cleared,
the test often fails.
This can be reproduced by running the SimpleJpaRepositoryTckText (added in the attached
patch). It runs the SetValueBinaryTest case, consisting of 4 tests. Typical runs on my
laptop produce 0-4 errors (usually 1-3), although YMMV based on local performance. Please
note that the read and the set are coming from the same thread.
JCR Workspace and Session Imports Can Fail on JPA Connector
-----------------------------------------------------------
Key: DNA-546
URL:
https://jira.jboss.org/jira/browse/DNA-546
Project: DNA
Issue Type: Bug
Components: Connectors, JCR
Affects Versions: 0.6
Reporter: Brian Carothers
Fix For: 0.7
Attachments: concurrency_issue.patch, DNA-546_jpa_connector_refactor.patch,
DNA-546_map_node_change.patch, DNA-546_mostly_working.patch,
DNA-546_simple_model_WIP.patch, DNA-546_tck_test.patch
Importing a set of nodes from an XML file will fail if one of the imported nodes has the
same jcr:uuid as an existing node in the graph and removeExisting is true and the new
location for the imported node and its prior location are both accessed through the same
JPA connector.
The DocumentViewImportTest is disabled (commented out) in the JPA integration test as a
result of this defect.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira