You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Thomas Mueller (JIRA)" <ji...@apache.org> on 2010/01/04 10:28:54 UTC
[jira] Created: (JCR-2449) Slow performance due to JCR-2138
(Prevent persistence of faulty back-references)
Slow performance due to JCR-2138 (Prevent persistence of faulty back-references)
--------------------------------------------------------------------------------
Key: JCR-2449
URL: https://issues.apache.org/jira/browse/JCR-2449
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.0-beta4, 1.5.7
Reporter: Thomas Mueller
In revision 782898, the following code was introduced:
updateReferences() {
for (Iterator i = local.addedStates(); i.hasNext();) {
...
if (hasItemState(state.getId())) {
...
}
}
}
This will try to fetch inexistent nodes from the persistence manager.
Depending on the persistence manager implementation, this is very slow.
I hope there is a way to avoid this call, or if not, speed it up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2449) Slow performance due to JCR-2138
(Prevent persistence of faulty back-references)
Posted by "Martijn Hendriks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802772#action_12802772 ]
Martijn Hendriks commented on JCR-2449:
---------------------------------------
The problem did not specifically involve clustered environments. I wrote the ReferencesTest that has been added in JCR-2138; running these against the jackrabbit-1.4.5 gives 5 test failures because of corrupt references. This happens when two sessions add/modify the same reference property at the same time.
Your patch effectively removes the patch for JCR-2138 and the ReferencesTest does not fail. That's good! Something in the ItemStateManager hierarchy must have changed such that the problem cannot occur anymore.
> Slow performance due to JCR-2138 (Prevent persistence of faulty back-references)
> --------------------------------------------------------------------------------
>
> Key: JCR-2449
> URL: https://issues.apache.org/jira/browse/JCR-2449
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.5.7, 2.0-beta4
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Fix For: 2.0.0
>
> Attachments: JCR-2449.patch
>
>
> In revision 782898, the following code was introduced:
> updateReferences() {
> for (Iterator i = local.addedStates(); i.hasNext();) {
> ...
> if (hasItemState(state.getId())) {
> ...
> }
> }
> }
> This will try to fetch inexistent nodes from the persistence manager.
> Depending on the persistence manager implementation, this is very slow.
> I hope there is a way to avoid this call, or if not, speed it up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2449) Slow performance due to JCR-2138
(Prevent persistence of faulty back-references)
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802773#action_12802773 ]
Thomas Mueller commented on JCR-2449:
-------------------------------------
Hi Martijn,
Thanks for your help. It's good to know the issue is resolved, and it's very good to have the additional test case. For me, it is very important that the check is disabled in Jackrabbit 2.0, because it is a major performance problem in my environment.
> Slow performance due to JCR-2138 (Prevent persistence of faulty back-references)
> --------------------------------------------------------------------------------
>
> Key: JCR-2449
> URL: https://issues.apache.org/jira/browse/JCR-2449
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.5.7, 2.0-beta4
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Fix For: 2.0.0
>
> Attachments: JCR-2449.patch
>
>
> In revision 782898, the following code was introduced:
> updateReferences() {
> for (Iterator i = local.addedStates(); i.hasNext();) {
> ...
> if (hasItemState(state.getId())) {
> ...
> }
> }
> }
> This will try to fetch inexistent nodes from the persistence manager.
> Depending on the persistence manager implementation, this is very slow.
> I hope there is a way to avoid this call, or if not, speed it up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2449) Slow performance due to JCR-2138
(Prevent persistence of faulty back-references)
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Mueller updated JCR-2449:
--------------------------------
Attachment: JCR-2449.patch
This patch solves the performance problem introduced by JCR-2138. The unit tests of jackrabbit-core still work for me after applying the patch.
I don't really understand what the problem was before JCR-2138.
Was it a clustering issue? If yes, then the check introduced doesn't really work. Reason: 1) first it checks if references were added, and if yes, then 2) the references are removed. However if the second cluster node adds the references between 1) and 2) then it will still not work.
If it was not a clustering problem, then why do you check if the node already exists in the 'addedStates' list? Those by definition don't exist (they are added, that's the reason to call it 'addedStates'). As far as I understand, saving is synchronized. Is it only a problem if a non-default ISMLocking is used?
> Slow performance due to JCR-2138 (Prevent persistence of faulty back-references)
> --------------------------------------------------------------------------------
>
> Key: JCR-2449
> URL: https://issues.apache.org/jira/browse/JCR-2449
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.5.7, 2.0-beta4
> Reporter: Thomas Mueller
> Attachments: JCR-2449.patch
>
>
> In revision 782898, the following code was introduced:
> updateReferences() {
> for (Iterator i = local.addedStates(); i.hasNext();) {
> ...
> if (hasItemState(state.getId())) {
> ...
> }
> }
> }
> This will try to fetch inexistent nodes from the persistence manager.
> Depending on the persistence manager implementation, this is very slow.
> I hope there is a way to avoid this call, or if not, speed it up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2449) Slow performance due to JCR-2138
(Prevent persistence of faulty back-references)
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Mueller resolved JCR-2449.
---------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0
Assignee: Thomas Mueller
> Slow performance due to JCR-2138 (Prevent persistence of faulty back-references)
> --------------------------------------------------------------------------------
>
> Key: JCR-2449
> URL: https://issues.apache.org/jira/browse/JCR-2449
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.5.7, 2.0-beta4
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Fix For: 2.0.0
>
> Attachments: JCR-2449.patch
>
>
> In revision 782898, the following code was introduced:
> updateReferences() {
> for (Iterator i = local.addedStates(); i.hasNext();) {
> ...
> if (hasItemState(state.getId())) {
> ...
> }
> }
> }
> This will try to fetch inexistent nodes from the persistence manager.
> Depending on the persistence manager implementation, this is very slow.
> I hope there is a way to avoid this call, or if not, speed it up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.