Re: node locking when connection pool is used ?
Hi, Sorry for the late response. On 9/11/07, ruchi goel [EMAIL PROTECTED] wrote: In our design , instead of having one repository connection per user session , we would like to have a pool of repository connections which can be shared between the end user http sessions. As per JSR170 specs , locking of node is mapped per repository session . Now how do we enable locking per user session ? Do we need to do this manually by maintaining a mapping file . I'm not sure if it's best practice (haven't seen that many cases with locking and session pooling), but at least I would create the locks as open-scoped locks and store the lock tokens in the HTTP session. A request for releasing a lock would then take the lock token from the HTTP session and add it to the JCR session acquired from a pool to be able to release the lock. BR, Jukka Zitting
Re: release for Jackrabbit 1.4
Hi, On 9/11/07, ruchi goel [EMAIL PROTECTED] wrote: What is the expected time frame for release of Jackrabbit 1.4 ? I don't yet have any exact dates, but I'd expect at least a month or two before the release is ready. At least we still need to finalize the data store implementation and handle the upgrades of the OCM and SPI components. I'll come up with a more detailed release plan with relevant Jira references in near future. Is there interest in getting some essential bug fixes out already before the 1.4 release? I could easily imagine doing a 1.3.2 patch release if there's interest. BR, Jukka Zitting
[jira] Created: (JCR-1136) Timeout for locked nodes
Timeout for locked nodes Key: JCR-1136 URL: https://issues.apache.org/jira/browse/JCR-1136 Project: Jackrabbit Issue Type: New Feature Components: webdav Affects Versions: 1.3.1 Reporter: Claus Köll If the WebDAV Layer creates a non session scoped lock on a node and the webdav client (such as ms-word) ends unexpected the node is still locked and it is not possible to unlock this node. In that case it will be useful to have a timeout for locked nodes. This feature should be implemented also in JCR-283 greets claus -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Synchronized methods in ItemManager
Hi, I should have explained my question in more detail. The Javadoc of the ItemManager states that there's one ItemManager per Session: it is created in the constructor of SessionImpl. Sessions are not thread-safe by specification. Because some methods in the ItemManager are synchronized, an ItemManager instance of a Sesssion can also be accessed by other threads than the one that is using the Session that created that ItemManager. I am just wondering when that could happen. The reason I am asking this is because we have the feeling that the synchronization overhead begins to count on a multiprocessor (8 CPUs) platform. Best regards, Martijn -- Martijn Hendriks GX creative online development B.V. t: 024 - 3888 261 f: 024 - 3888 621 e: [EMAIL PROTECTED] Wijchenseweg 111 6538 SW Nijmegen http://www.gx.nl/ -Original Message- From: Thomas Mueller [mailto:[EMAIL PROTECTED] Sent: Friday, September 14, 2007 6:12 PM To: dev@jackrabbit.apache.org Subject: Re: Synchronized methods in ItemManager Hi, where the second thread comes from The application can use multiple threads. Jackrabbit needs to protect itself from that. Thomas
[jira] Created: (JCR-1137) test cases relying on Node.equals()
test cases relying on Node.equals() --- Key: JCR-1137 URL: https://issues.apache.org/jira/browse/JCR-1137 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Reporter: Julian Reschke Several test cases rely on Node.equals to compare nodes, where instead isSame() should be used: org.apache.jackrabbit.test.api.NodeTest.testNodeIdentity(NodeTest.java:751) org.apache.jackrabbit.test.api.NodeTest.testNodeIdentity(NodeTest.java:753) org.apache.jackrabbit.test.api.version.VersionHistoryTest.testInitallyGetAllVersionsContainsTheRootVersion(VersionHistoryTest.java:126) org.apache.jackrabbit.test.api.version.VersionHistoryTest.testGetVersion(VersionHistoryTest.java:180) org.apache.jackrabbit.test.api.version.CheckinTest.testMultipleCheckinHasNoEffect(CheckinTest.java:93) org.apache.jackrabbit.test.api.version.VersionGraphTest.testInitialBaseVersionPointsToRootVersion(VersionGraphTest.java:47) org.apache.jackrabbit.test.api.version.RemoveVersionTest.testRemoveVersionAdjustPredecessorSet(RemoveVersionTest.java:120) org.apache.jackrabbit.test.api.version.RemoveVersionTest.testRemoveVersionAdjustSucessorSet(RemoveVersionTest.java:144) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Synchronized methods in ItemManager
I should have explained my question in more detail. The Javadoc of the ItemManager states that there's one ItemManager per Session: it is created in the constructor of SessionImpl. Sessions are not thread-safe by specification. Because some methods in the ItemManager are synchronized, an ItemManager instance of a Sesssion can also be accessed by other threads than the one that is using the Session that created that ItemManager. I am just wondering when that could happen. our official statement still is you may use multiple threads on a session that just read but a single thread on a session that writes. in addition there's also the scenario where one thread saves changes on session and those changes get propagated to other sessions that are accessed by other threads. as for multiple threads on a single session instance I personally prefer a more coarse grained synchronization to avoid monitor contention. see: JCR-890. regards marcel
Re: [jira] Commented: (JCR-905) Clustering: race condition may cause duplicate entries in search index
Hi Andrea, yes, please do so. If you see that the problem is gone with the patch I will commit it. regards marcel Andrea K. wrote: Hi Marcel, I'm just trying your proposed patch on a cluster. If you want I can send you the resulting JR debug log and personal impressions. Thanks. Andrea - Marcel Reutegger wrote: Andrea K. wrote: Hi all, i'm testing the 2 line patch as suggested in (https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel). As I can see, no duplicated nodes exists with cluster configuration. What do you think aboout the patch proposed? Should it be used without any problem (other than a slow indexing tasks)? the patch will probably work, but is not a good solution to the problem. it adds overhead even if jackrabbit is not clustered. regards marcel
Re: Synchronized methods in ItemManager
Hi, we have the feeling that the synchronization overhead begins to count on a multiprocessor (8 CPUs) platform. Do you have some test case where this can be verified? on a single session instance I personally prefer a more coarse grained synchronization I agree. In my view, an application should not access the same session within multiple threads. But if the application does, synchronization is required within Jackrabbit to avoid corruption. Where synchronize on the session is required, this should be done on a high level to improve performance. Regards, Thomas
[jira] Resolved: (JCR-1131) JCR2SPI NodeEntryImpl throws NPE during reorderNodes
[ https://issues.apache.org/jira/browse/JCR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-1131. --- Resolution: Fixed Fixed in revision: 576296 Thanks for reporting this issue. JCR2SPI NodeEntryImpl throws NPE during reorderNodes Key: JCR-1131 URL: https://issues.apache.org/jira/browse/JCR-1131 Project: Jackrabbit Issue Type: Bug Components: SPI Reporter: David Rauschenbach Two folder nodes are created below root. From the root node, the 2nd folder is ordered before the first node. The request is batched up correctly, but upon save, NodeEntryImpl throws a NullPointerException in the first line of the completeTransientChanges method, because revertInfo.oldParent is null. Test code: final String FOLDER1 = folder1, FOLDER2 = folder2; // Create folder 1 on server in root Session serverSession = login(repository, creds); Node serverRootNode = serverSession.getRootNode(); Node serverFolder1 = serverRootNode.addNode(FOLDER1, nt:folder); // Create folder 2 on server in root Node serverFolder2 = serverRootNode.addNode(FOLDER2, nt:folder); serverSession.save(); // Validate order (TODO) // Perform reorder via client Session clientSession = login(clientRepository, creds); Node clientRootNode = clientSession.getRootNode(); clientRootNode.orderBefore(FOLDER2, FOLDER1); clientSession.save(); == Throws NPE Call Stack: [junit] java.lang.NullPointerException [junit] at org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.completeTransientChanges(NodeEntryImpl.java:1354) [junit] at org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.access$1100(NodeEntryImpl.java:60) [junit] at org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl$RevertInfo.statusChanged(NodeEntryImpl.java:1465) [junit] at org.apache.jackrabbit.jcr2spi.state.ItemState.setStatus(ItemState.java:257) [junit] at org.apache.jackrabbit.jcr2spi.state.NodeState.adjustNodeState(NodeState.java:554) [junit] at org.apache.jackrabbit.jcr2spi.state.NodeState.persisted(NodeState.java:276) [junit] at org.apache.jackrabbit.jcr2spi.state.ChangeLog.persisted(ChangeLog.java:135) [junit] at org.apache.jackrabbit.jcr2spi.WorkspaceManager.execute(WorkspaceManager.java:479) [junit] at org.apache.jackrabbit.jcr2spi.state.SessionItemStateManager.save(SessionItemStateManager.java:149) [junit] at org.apache.jackrabbit.jcr2spi.ItemImpl.save(ItemImpl.java:239) [junit] at org.apache.jackrabbit.jcr2spi.SessionImpl.save(SessionImpl.java:317) [junit] at TestWsNodeReorder.testReorderNodes(TestWsNodeReorder.java:72) I'm using an SPI I implemented, in conjunction with the jcr2spi and spi2jcr bridges, coupled with a back-end Jackrabbit in-memory filesystem. So there's always the possibility that node or property SPI calls inject errors and cause this downstream problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1131) JCR2SPI NodeEntryImpl throws NPE during reorderNodes
[ https://issues.apache.org/jira/browse/JCR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-1131: -- Affects Version/s: (was: 1.4) JCR2SPI NodeEntryImpl throws NPE during reorderNodes Key: JCR-1131 URL: https://issues.apache.org/jira/browse/JCR-1131 Project: Jackrabbit Issue Type: Bug Components: SPI Reporter: David Rauschenbach Two folder nodes are created below root. From the root node, the 2nd folder is ordered before the first node. The request is batched up correctly, but upon save, NodeEntryImpl throws a NullPointerException in the first line of the completeTransientChanges method, because revertInfo.oldParent is null. Test code: final String FOLDER1 = folder1, FOLDER2 = folder2; // Create folder 1 on server in root Session serverSession = login(repository, creds); Node serverRootNode = serverSession.getRootNode(); Node serverFolder1 = serverRootNode.addNode(FOLDER1, nt:folder); // Create folder 2 on server in root Node serverFolder2 = serverRootNode.addNode(FOLDER2, nt:folder); serverSession.save(); // Validate order (TODO) // Perform reorder via client Session clientSession = login(clientRepository, creds); Node clientRootNode = clientSession.getRootNode(); clientRootNode.orderBefore(FOLDER2, FOLDER1); clientSession.save(); == Throws NPE Call Stack: [junit] java.lang.NullPointerException [junit] at org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.completeTransientChanges(NodeEntryImpl.java:1354) [junit] at org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.access$1100(NodeEntryImpl.java:60) [junit] at org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl$RevertInfo.statusChanged(NodeEntryImpl.java:1465) [junit] at org.apache.jackrabbit.jcr2spi.state.ItemState.setStatus(ItemState.java:257) [junit] at org.apache.jackrabbit.jcr2spi.state.NodeState.adjustNodeState(NodeState.java:554) [junit] at org.apache.jackrabbit.jcr2spi.state.NodeState.persisted(NodeState.java:276) [junit] at org.apache.jackrabbit.jcr2spi.state.ChangeLog.persisted(ChangeLog.java:135) [junit] at org.apache.jackrabbit.jcr2spi.WorkspaceManager.execute(WorkspaceManager.java:479) [junit] at org.apache.jackrabbit.jcr2spi.state.SessionItemStateManager.save(SessionItemStateManager.java:149) [junit] at org.apache.jackrabbit.jcr2spi.ItemImpl.save(ItemImpl.java:239) [junit] at org.apache.jackrabbit.jcr2spi.SessionImpl.save(SessionImpl.java:317) [junit] at TestWsNodeReorder.testReorderNodes(TestWsNodeReorder.java:72) I'm using an SPI I implemented, in conjunction with the jcr2spi and spi2jcr bridges, coupled with a back-end Jackrabbit in-memory filesystem. So there's always the possibility that node or property SPI calls inject errors and cause this downstream problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Synchronized methods in ItemManager
Marcel Reutegger wrote: our official statement still is you may use multiple threads on a session that just read but a single thread on a session that writes. in - Could you please provide a pointer to that statement? - Also, we need to keep in mind that even if Jackrabbit allows that, JCR in general doesn't. So an application taking advantage of that may break on different JCR implementations. Finally, how does that translate to JCR2SPI and the SPI interfaces? It seems we need to clarify the thread-safety of spi.RepositoryService and spi.SessionInfo... ... Best regards, Julian
[jira] Created: (JCR-1138) Data store garbage collection
Data store garbage collection - Key: JCR-1138 URL: https://issues.apache.org/jira/browse/JCR-1138 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Thomas Mueller Assignee: Thomas Mueller Currently the data store garbage collection needs to be run manually. It should be simpler to use (maybe tool based), or automatic. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1138) Data store garbage collection
[ https://issues.apache.org/jira/browse/JCR-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528000 ] Thomas Mueller commented on JCR-1138: - Revision 576314: added a test case and fixed a bug: The garbage collecter deleted too many files when not closing the repository first Data store garbage collection - Key: JCR-1138 URL: https://issues.apache.org/jira/browse/JCR-1138 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Thomas Mueller Assignee: Thomas Mueller Currently the data store garbage collection needs to be run manually. It should be simpler to use (maybe tool based), or automatic. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Validation in QName class
Hi all,
The QName class does not do any validation on the syntax of the local
part. As a result, it is really easy to destroy your repository by
registration of a nodetype with, for instance, a property with QName
{http://myapp/a}local1:local2. The NodeTypeRegistry only validates the
prefix part on registration. The local part is validated when the
custom_nodetypes.xml are read in on a subsequent startup which will fail
because of the invalid name... (JR 1.3)
The javadoc of the Qname constructor says explicitly that the format of
the local part is not validated and that the NameFormat class should be
used. Imo it would be good to validate the local part in both the
constructor and the valueOf method, or is there a reason not to do this?
Best wishes,
Martijn
--
Martijn Hendriks
GX creative online development B.V.
t: 024 - 3888 261
f: 024 - 3888 621
e: [EMAIL PROTECTED]
Wijchenseweg 111
6538 SW Nijmegen
http://www.gx.nl/
Re: Validation in QName class
hi martijn,
On 9/17/07, Martijn Hendriks [EMAIL PROTECTED] wrote:
Hi all,
The QName class does not do any validation on the syntax of the local
part. As a result, it is really easy to destroy your repository by
registration of a nodetype with, for instance, a property with QName
{http://myapp/a}local1:local2. The NodeTypeRegistry only validates the
prefix part on registration. The local part is validated when the
custom_nodetypes.xml are read in on a subsequent startup which will fail
because of the invalid name... (JR 1.3)
The javadoc of the Qname constructor says explicitly that the format of
the local part is not validated and that the NameFormat class should be
used. Imo it would be good to validate the local part in both the
constructor and the valueOf method, or is there a reason not to do this?
QName's are only heavily used internally and assumed to be syntactically
correct. validations are intentionally avoided for performance reasons.
cheers
stefan
Best wishes,
Martijn
--
Martijn Hendriks
GX creative online development B.V.
t: 024 - 3888 261
f: 024 - 3888 621
e: [EMAIL PROTECTED]
Wijchenseweg 111
6538 SW Nijmegen
http://www.gx.nl/
Re: Validation in QName class
On 9/17/07, Stefan Guggisberg [EMAIL PROTECTED] wrote:
hi martijn,
On 9/17/07, Martijn Hendriks [EMAIL PROTECTED] wrote:
Hi all,
The QName class does not do any validation on the syntax of the local
part. As a result, it is really easy to destroy your repository by
registration of a nodetype with, for instance, a property with QName
{http://myapp/a}local1:local2. The NodeTypeRegistry only validates the
prefix part on registration. The local part is validated when the
custom_nodetypes.xml are read in on a subsequent startup which will fail
because of the invalid name... (JR 1.3)
The javadoc of the Qname constructor says explicitly that the format of
the local part is not validated and that the NameFormat class should be
used. Imo it would be good to validate the local part in both the
constructor and the valueOf method, or is there a reason not to do this?
QName's are only heavily used internally and assumed to be syntactically
erm, i meant: heavily used and internally only
correct. validations are intentionally avoided for performance reasons.
cheers
stefan
Best wishes,
Martijn
--
Martijn Hendriks
GX creative online development B.V.
t: 024 - 3888 261
f: 024 - 3888 621
e: [EMAIL PROTECTED]
Wijchenseweg 111
6538 SW Nijmegen
http://www.gx.nl/
RE: Validation in QName class
Hi Stefan,
Performance is a good argument of course. For this particular problem,
however, I think that some check inside Jackrabbit is needed because the
whole repository may become unusable by one wrong QName. The
NodeTypeRegistry.validateNodeTypeDef method could be used for that. What
do you think about adding some checks for invalid QNames there?
Best regards,
Martijn
--
Martijn Hendriks
GX creative online development B.V.
t: 024 - 3888 261
f: 024 - 3888 621
e: [EMAIL PROTECTED]
Wijchenseweg 111
6538 SW Nijmegen
http://www.gx.nl/
-Original Message-
From: Stefan Guggisberg [mailto:[EMAIL PROTECTED]
Sent: Monday, September 17, 2007 11:20 AM
To: dev@jackrabbit.apache.org
Subject: Re: Validation in QName class
On 9/17/07, Stefan Guggisberg [EMAIL PROTECTED] wrote:
hi martijn,
On 9/17/07, Martijn Hendriks [EMAIL PROTECTED] wrote:
Hi all,
The QName class does not do any validation on the syntax of the
local part. As a result, it is really easy to destroy your
repository by registration of a nodetype with, for instance, a
property with QName {http://myapp/a}local1:local2. The
NodeTypeRegistry only validates the prefix part on
registration. The
local part is validated when the custom_nodetypes.xml are
read in on
a subsequent startup which will fail because of the
invalid name...
(JR 1.3)
The javadoc of the Qname constructor says explicitly that
the format
of the local part is not validated and that the NameFormat class
should be used. Imo it would be good to validate the
local part in
both the constructor and the valueOf method, or is there
a reason not to do this?
QName's are only heavily used internally and assumed to be
syntactically
erm, i meant: heavily used and internally only
correct. validations are intentionally avoided for
performance reasons.
cheers
stefan
Best wishes,
Martijn
--
Martijn Hendriks
GX creative online development B.V.
t: 024 - 3888 261
f: 024 - 3888 621
e: [EMAIL PROTECTED]
Wijchenseweg 111
6538 SW Nijmegen
http://www.gx.nl/
Re: Validation in QName class
Hi, On 9/17/07, Martijn Hendriks [EMAIL PROTECTED] wrote: Performance is a good argument of course. For this particular problem, however, I think that some check inside Jackrabbit is needed because the whole repository may become unusable by one wrong QName. The NodeTypeRegistry.validateNodeTypeDef method could be used for that. What do you think about adding some checks for invalid QNames there? Sounds like a patch? :-) However, the officially supported node type registration methods are the ones in o.a.j.api.JackrabbitNodeTypeManager, and there we do validate all the QNames. If you are using NodeTypeRegistry directly, then I think it should be your responsibility to do the validation before constructing the QName instances. BR, Jukka Zitting
RE: Validation in QName class
Hi, On 9/17/07, Martijn Hendriks [EMAIL PROTECTED] wrote: Performance is a good argument of course. For this particular problem, however, I think that some check inside Jackrabbit is needed because the whole repository may become unusable by one wrong QName. The NodeTypeRegistry.validateNodeTypeDef method could be used for that. What do you think about adding some checks for invalid QNames there? Sounds like a patch? :-) Well, yes :). However, the officially supported node type registration methods are the ones in o.a.j.api.JackrabbitNodeTypeManager, and there we do validate all the QNames. If you are using NodeTypeRegistry directly, then I think it should be your responsibility to do the validation before constructing the QName instances. Ok, that's fair. We use the NodeTypeRegistry directly because we need to re-register nodetypes sometimes. The NodeTypeRegistry already has a method checkNamespace to check that the URI of a QName has been registered. Wouldn't adding a check with the NameFormat.checkFormat on the local name of the QName only make the registry more robust? Best wishes, Martijn BR, Jukka Zitting
RE: Synchronized methods in ItemManager
Hi, we have the feeling that the synchronization overhead begins to count on a multiprocessor (8 CPUs) platform. Do you have some test case where this can be verified? No, not yet but we're working on it. As soon as we have some results I'll get back on this. Best wishes, Martijn
Re: Validation in QName class
Hi, On 9/17/07, Martijn Hendriks [EMAIL PROTECTED] wrote: However, the officially supported node type registration methods are the ones in o.a.j.api.JackrabbitNodeTypeManager, and there we do validate all the QNames. If you are using NodeTypeRegistry directly, then I think it should be your responsibility to do the validation before constructing the QName instances. Ok, that's fair. We use the NodeTypeRegistry directly because we need to re-register nodetypes sometimes. The NodeTypeRegistry already has a method checkNamespace to check that the URI of a QName has been registered. Wouldn't adding a check with the NameFormat.checkFormat on the local name of the QName only make the registry more robust? I see the logic in adding more robustness, but so far the basic assumption about QNames has been that they are all valid once constructed. I wouldn't want to start eroding that assumption by allowing some clients to feed invalid QNames to internal Jackrabbit methods and expecting the repository to do the validation for them. If you do need the extra functionality from NodeTypeRegistry, how about if we exposed it on the JackrabbitNodeTypemanager level together with proper name validation? This solution would be cleaner design-wise and would allow you to drop one direct jackrabbit-core dependency. BR, Jukka Zitting
Using the geronimo-jta dependency only in test scope
Hi, I traced where we use the javax.transaction interfaces currently included by jackrabbit-core via the geronimo-jta dependency. The extra interfaces are used quite a lot within the test cases, but in src/main/java only the o.a.j.core.TransactionContext and o.a.j.core.lock.XAEnvironment classes use this dependency. Even more notably, the TransactionContext and XAEnvironment classes depend only on a couple of integer constants in javax.transaction.Status. We could easily create local versions of those state constants, and restrict the geronimo-jta dependency to test scope. Does anyone spot any obvious flaws in my understanding? If not, I'll propose a patch to do the above. BR, Jukka Zitting
[jira] Commented: (JCR-905) Clustering: race condition may cause duplicate entries in search index
[ https://issues.apache.org/jira/browse/JCR-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528043 ] Martijn Hendriks commented on JCR-905: -- I just tested Marcel's patch and it works fine. It's good to eliminate the overhead for non-clustered installations! Best wishes, Martijn Clustering: race condition may cause duplicate entries in search index -- Key: JCR-905 URL: https://issues.apache.org/jira/browse/JCR-905 Project: Jackrabbit Issue Type: Bug Components: clustering Affects Versions: 1.3 Reporter: Martijn Hendriks Attachments: JCR-905.patch, log1.txt, log2.txt, SearchManager.patch There seems to be a race condition that may cause duplicate search index entries. It is reproducible as follows (Jackrabbit 1.3): 1) Start clusternode 1 that just adds a single node of node type clustering:test. 2) Shutdown clusternode 1. 3) Start clusternode 2 with an empty search index. 4) Execute the query //element(*, clustering:test). 4) Print the result of the query (UUIDs of nodes in the result set). When I just run clusternode 2, then there is one node in the resultset, as expected. However, when I debug clusternode 2 and have a breakpoint (i.e., a pause of a few seconds at line 306 of RepositoryImpl.java - just before the clusternode is started), then the resultset contains two results, both with the same UUID. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Validation in QName class
Hi Jukka,
If you do need the extra functionality from NodeTypeRegistry,
how about if we exposed it on the JackrabbitNodeTypemanager
level together with proper name validation? This solution
would be cleaner design-wise and would allow you to drop one
direct jackrabbit-core dependency.
That would be great, should I create a JIRA issue for that?
In the category of quick and dirty fixes: would the following change
to checkNamespace in the NodeTypeRegistry be a risky one? The
1.4-SNAPSHOT of a few minutes ago builds correctly.
Best wishes,
Martijn
@@ -1363,6 +1365,14 @@
if (name != null) {
// make sure namespace uri denotes a registered namespace
nsReg.getPrefix(name.getNamespaceURI());
+// check the format of the local name
+if (!name.equals(ItemDef.ANY_NAME)){
+try {
+NameFormat.checkFormat(name.getLocalName());
+} catch (IllegalNameException e) {
+throw new RepositoryException(Invalid QName, e);
+}
+}
}
}
Re: Synchronized methods in ItemManager
Julian Reschke wrote: Marcel Reutegger wrote: our official statement still is you may use multiple threads on a session that just read but a single thread on a session that writes. in - Could you please provide a pointer to that statement? well, maybe 'official' is the wrong term. whenever these kind of questions arise on the mailing list, we tell people that reading from multiple thread is probably safe, while writing is not. searching the mail archive should give you some of those statements. Finally, how does that translate to JCR2SPI and the SPI interfaces? It seems we need to clarify the thread-safety of spi.RepositoryService and spi.SessionInfo... I agree, we should definitively do that. Again, I think jcr2spi should be entirely thread safe for any kind of operation, while the SPI level is IMO debatable, because it is at a lower level. regards marcel
Re: Synchronized methods in ItemManager
Marcel Reutegger wrote: Julian Reschke wrote: Marcel Reutegger wrote: our official statement still is you may use multiple threads on a session that just read but a single thread on a session that writes. in - Could you please provide a pointer to that statement? well, maybe 'official' is the wrong term. whenever these kind of questions arise on the mailing list, we tell people that reading from multiple thread is probably safe, while writing is not. searching the mail archive should give you some of those statements. I see. Note that you now said is probably safe :-) Finally, how does that translate to JCR2SPI and the SPI interfaces? It seems we need to clarify the thread-safety of spi.RepositoryService and spi.SessionInfo... I agree, we should definitively do that. Again, I think jcr2spi should be entirely thread safe for any kind of operation, while the SPI level is IMO debatable, because it is at a lower level. FWIW, we should make up our minds what we want to agree, and clearly document that. I don't care a lot about what we say, but I'm not convinced that guaranteeing more than JSR-170 says would be good for interoperability of clients. Best regards, Julian
Re: Synchronized methods in ItemManager
Hi, but I'm not convinced that guaranteeing more than JSR-170 says would be good for interoperability of clients. Maybe trying to detect concurrent access and throwing an exception would be an option? From HashMap javadocs: Fail-fast iterators throw ConcurrentModificationException on a best-effort basis... the fail-fast behavior of iterators should be used only to detect bugs... That way we don't have to synchronize, but also reduce the risk of corrupted internal structures on concurrent access within the same session. Thomas
Re: System slowdown
Hi, I think the ObjectPersistenceManager should not be used. Maybe it is time to deprecate it... Is there some specific reason why you can't use a more modern persistence manager, for example BundleFsPersistenceManager or BundleDbPersistenceManager? As far as I know, both can access binary data more efficiently. about one million, that inserting takes over three times as long. Generally large repositories are slower than small ones. This is also the case for other storage systems. How long is three times as long? I notice that the info from the CacheManager during its resizeAll the size was at 4k. This sounds like you have opened sessions but did not close them. Could you please verify that your application closes all sessions? Regards, Thomas
Re: Synchronized methods in ItemManager
Julian Reschke wrote: Marcel Reutegger wrote: Julian Reschke wrote: Marcel Reutegger wrote: our official statement still is you may use multiple threads on a session that just read but a single thread on a session that writes. in - Could you please provide a pointer to that statement? well, maybe 'official' is the wrong term. whenever these kind of questions arise on the mailing list, we tell people that reading from multiple thread is probably safe, while writing is not. searching the mail archive should give you some of those statements. I see. Note that you now said is probably safe :-) yeah, I looked up the relevant messages in the archive and found that we only say 'probably' ;) Finally, how does that translate to JCR2SPI and the SPI interfaces? It seems we need to clarify the thread-safety of spi.RepositoryService and spi.SessionInfo... I agree, we should definitively do that. Again, I think jcr2spi should be entirely thread safe for any kind of operation, while the SPI level is IMO debatable, because it is at a lower level. FWIW, we should make up our minds what we want to agree, and clearly document that. I don't care a lot about what we say, but I'm not convinced that guaranteeing more than JSR-170 says would be good for interoperability of clients. well, the main reason behind my call for a thread-safe implementation is for clients that use a session from multiple sessions *by mistake* and not on purpose. the repository should not break in any case. regards marcel
Re: Using the geronimo-jta dependency only in test scope
El lun, 17-09-2007 a las 14:52 +0300, Jukka Zitting escribió: Hi, I traced where we use the javax.transaction interfaces currently included by jackrabbit-core via the geronimo-jta dependency. The extra interfaces are used quite a lot within the test cases, but in src/main/java only the o.a.j.core.TransactionContext and o.a.j.core.lock.XAEnvironment classes use this dependency. Even more notably, the TransactionContext and XAEnvironment classes depend only on a couple of integer constants in javax.transaction.Status. We could easily create local versions of those state constants, and restrict the geronimo-jta dependency to test scope. Does anyone spot any obvious flaws in my understanding? If not, I'll propose a patch to do the above. Great! Transaction usage is optional. I was not sure if Jackrabbit core used transactions internally. -- Paco Avila [EMAIL PROTECTED]
Re: release for Jackrabbit 1.4
Hi, On 9/11/07, ruchi goel [EMAIL PROTECTED] wrote: What is the expected time frame for release of Jackrabbit 1.4 ? I don't yet have any exact dates, but I'd expect at least a month or two before the release is ready. At least we still need to finalize the data store implementation and handle the upgrades of the OCM and SPI components. I'll come up with a more detailed release plan with relevant Jira references in near future. Is there interest in getting some essential bug fixes out already before the 1.4 release? I could easily imagine doing a 1.3.2 patch release if there's interest. BR, Jukka Zitting Hi all. Yes! We think it would be a good idea to make an interim release. We're having trouble with JCR-962. We have JR 1.3.1 with the 962 patch applied, and we still get deadlocks in almost every run of ConcurrentVersioningWithTransactionsTest and ConcurrentCheckinMixedTransactionTest. We also run those tests against trunk but they didn't deadlock. Also, we have some code we can contribute that reads the locking strategy information from the repository/workspace.xml, and for JCR-935 (this one is commented in the the issue). Regards, Esteban Franqueiro [EMAIL PROTECTED] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (JCR-935) ConcurrentModificationException during logout (cont'd)
[ https://issues.apache.org/jira/browse/JCR-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528113 ] Esteban Franqueiro commented on JCR-935: We also sync'ed push() and getOverlayedState() in ItemState class. Regards, ConcurrentModificationException during logout (cont'd) -- Key: JCR-935 URL: https://issues.apache.org/jira/browse/JCR-935 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.3 Reporter: Pablo Rios I seldom get a CME running ConcurrentReadWriteTest.testReadWrite test. Following are different stack traces of two runs: Exception in thread Thread-9 java.util.ConcurrentModificationException at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.hasNext(AbstractReferenceMap.java:735) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:543) at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) at org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) at org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) at org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) at java.lang.Thread.run(Unknown Source) Exception in thread Thread-9 java.util.ConcurrentModificationException at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.nextEntry(AbstractReferenceMap.java:770) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValuesIterator.next(AbstractReferenceMap.java:829) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:544) at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) at org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) at org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) at org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) at java.lang.Thread.run(Unknown Source) My working copy is revision 538918 with both JCR-314 patches applied, using FineGrainedISMLocking strategy. I run this test manually from within Eclipse 3.2.1 / JRE 1.5.0_10-b03. The workstation were I run this test has an Intel Dual-Core Xeon 5130 2 GHz. To able to compare this CPU with another, with the default params of this test (NUM_NODES = 5, NUM_THREADS = 5, RUN_NUM_SECONDS = 20), the number of operations are ~ #writes performed: 300-400, #reads performed: 470 - 490. Regards, Pablo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-935) ConcurrentModificationException during logout (cont'd)
[ https://issues.apache.org/jira/browse/JCR-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524579 ] efranqueiro edited comment on JCR-935 at 9/17/07 11:56 AM: -- Regarding the NPE that Pablo mentioned, it looks like a race condition, because the code first checks for != null, and then you get an NPE. The problem seems to disappear by synchronizing the pull(), connect(), reconnect(), disconnect(), isConnected(), isStale() and hasOverlayedState() methods of the class ItemState. According to the results of the test Pablo mentioned, it seems that sync'ing these methods doesn't add too much serialization. Still, we're wondering what do you all think about this, because although it works in the test, we don't know if there's a better (or may be correct) way of solving this issue. Regards, Esteban was (Author: efranqueiro): Regarding the NPE that Pablo mentioned, it looks like a race condition, because the code first checks for != null, and then you get an NPE. The problem seems to disappear by synchronizing the pull(), connect(), reconnect(), disconnect(), isConnected(), isStale() and hasOverlayedState() methods. According to the results of the test Pablo mentioned, it seems that sync'ing these methods doesn't add too much serialization. Still. we're wondering what do you all think about this, because although it works in the test, we don't know if there's a better (or may be correct) way of solving this issue. Regards, Esteban ConcurrentModificationException during logout (cont'd) -- Key: JCR-935 URL: https://issues.apache.org/jira/browse/JCR-935 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.3 Reporter: Pablo Rios I seldom get a CME running ConcurrentReadWriteTest.testReadWrite test. Following are different stack traces of two runs: Exception in thread Thread-9 java.util.ConcurrentModificationException at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.hasNext(AbstractReferenceMap.java:735) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:543) at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) at org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) at org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) at org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) at java.lang.Thread.run(Unknown Source) Exception in thread Thread-9 java.util.ConcurrentModificationException at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.nextEntry(AbstractReferenceMap.java:770) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValuesIterator.next(AbstractReferenceMap.java:829) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:544) at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) at org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) at org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) at org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) at java.lang.Thread.run(Unknown Source) My working copy is revision 538918 with both JCR-314 patches applied, using FineGrainedISMLocking strategy. I run this test manually from within Eclipse 3.2.1 / JRE 1.5.0_10-b03. The workstation were I run this test has an Intel Dual-Core Xeon 5130 2 GHz. To able to compare this CPU with another, with the default params of this test (NUM_NODES = 5, NUM_THREADS = 5, RUN_NUM_SECONDS = 20), the number of operations are ~ #writes performed: 300-400, #reads performed: 470 - 490. Regards, Pablo -- This message is
Re: Synchronized methods in ItemManager
Reading this post and going through some of the work I have done re. syncronization in the persistence manager I wonder if the real issue is not threads sharing a session, which it is clear they shouldn't, but that each session is tied to a persistence manager and an item manager which are both heavily synchronized. I understand the need to keep caches in sync etc, but it seems that we could be more performant (and I know I still owe the group numbers for performance :-) if we could use another pattern such as reader/writer locks, etc. to ensure consistency but allow for multiple simultaneous reads and writes. -paddy
[jira] Updated: (JCR-1050) Remove synchronization from JNDI data sources
[ https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-1050: Attachment: DerbyPooledPersistenceManager.java Here is a persistence manager which uses embedded derby pools. The storage tests all passed, however, the times were about the same as the synchronized one. Remove synchronization from JNDI data sources - Key: JCR-1050 URL: https://issues.apache.org/jira/browse/JCR-1050 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Padraic Hannon Attachments: DatasourcePersistenceManager.java, DerbyPooledPersistenceManager.java, JNDI_Datasource_Changes.diff, OracleDatasourcePersistenceManager.java Using datasources one should be able to rely on the application server to manage PreparedStatement caches therefore pre-creating and holding onto the connection for long periods of time should not be needed. This relates to improvement JCR-313, however, that change did not address the benefits one could see in using an application server controlled datasource. Even if jackrabbit does aim to use an embedded database such a system could be configured to use datasources and could benefit from the removal of the synchronization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1139) Upgrading to Jackrabbit 1.3.1 - ERROR
Upgrading to Jackrabbit 1.3.1 - ERROR - Key: JCR-1139 URL: https://issues.apache.org/jira/browse/JCR-1139 Project: Jackrabbit Issue Type: Bug Components: config Affects Versions: 1.3.1 Environment: windows Reporter: Rama Krishna We are moving from version jackrabbit 1.0 to jackrabbit 1.3.1. We have replaced following jars: jackrabbit-api-1.0-4.jar -- jackrabbit-api-1.3.1.jar jackrabbit-commons-1.0-4.jar -- jackrabbit-core-1.3.1.jar jackrabbit-core-1.0-4.jar -- jackrabbit-jcr-commons-1.3.1.jar After replacing these jars my repository not started and also its not showing any error. RepositoryConfig.create -- returning null Please advise. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
