[jira] Resolved: (JCR-2781) FileDataStore performance improvements

[Thomas Mueller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller resolved JCR-2781.
-

Resolution: Fixed

Fixed in revision #1022094 - I currently don't see any other obvious way to 
improve performance

> FileDataStore performance improvements
> --
>
> Key: JCR-2781
> URL: https://issues.apache.org/jira/browse/JCR-2781
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
>
> As seen in JCR-2695, the FileDataStore is slow on some file system. 
> Some file operations such as File.exists() or File.isDirectory() can be 
> replaced with try / catch, or by inspecting the return value of a previous 
> method (File.renameTo).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2396) File Journal workaround for misbehaving NFS implementations

[Thomas Mueller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller updated JCR-2396:


Status: Patch Available  (was: Open)

I don't plan to commit the patch currently, because it is only a partial 
solution.
The only real solution is to use a correct NFS implementation.

> File Journal workaround for misbehaving NFS implementations
> ---
>
> Key: JCR-2396
> URL: https://issues.apache.org/jira/browse/JCR-2396
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: clustering
>Affects Versions: core 1.4.10
> Environment: Some versions of NFS
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
> Attachments: diff.patch
>
>
> After one NFS client wrote data to a file, reading from another client 
> results in blocks of zero
> in some NFS implementations. This is a known issue:
> http://markmail.org/search/blocks+of+zeros+%28NULLs%29+in+NFS+files+in+kernels
> The Jackrabbit file journal implementation does not work properly in this 
> situation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2396) File Journal workaround for misbehaving NFS implementations

[Thomas Mueller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller updated JCR-2396:


Resolution: Won't Fix
Status: Resolved  (was: Patch Available)

> File Journal workaround for misbehaving NFS implementations
> ---
>
> Key: JCR-2396
> URL: https://issues.apache.org/jira/browse/JCR-2396
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: clustering
>Affects Versions: core 1.4.10
> Environment: Some versions of NFS
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
> Attachments: diff.patch
>
>
> After one NFS client wrote data to a file, reading from another client 
> results in blocks of zero
> in some NFS implementations. This is a known issue:
> http://markmail.org/search/blocks+of+zeros+%28NULLs%29+in+NFS+files+in+kernels
> The Jackrabbit file journal implementation does not work properly in this 
> situation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2033) Node.orderBefore is slow

[Thomas Mueller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller resolved JCR-2033.
-

Resolution: Won't Fix

I don't plan to work in this issue for Jackrabbit 2.x.
We should ensure it's solved in Jackrabbit 3 however.

> Node.orderBefore is slow
> 
>
> Key: JCR-2033
> URL: https://issues.apache.org/jira/browse/JCR-2033
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
>
> Use case: I have a node with a medium number of child nodes, and want to sort 
> the child nodes. To do that, I use Node.orderBefore.
> This is slow (31 seconds to sort 2000 child nodes), O(n^2).
> Workarounds: 
> 1) don't use that many child nodes
> 2) instead of using orderBefore, create a new node with the children in the 
> right order
> Test case:
> Session session = new TransientRepository().login(new SimpleCredentials("", 
> new char[0]));
> Node root = session.getRootNode();
> Node test = root.hasNode("test") ? root.getNode("test") : 
> root.addNode("test");
> long start = System.currentTimeMillis();
> int len = 2000;
> for (int i = 0; i < len; i++) {
> test.addNode("n" + i);
> }
> System.out.println("creating: " + (System.currentTimeMillis() - start));
> session.save();
> start = System.currentTimeMillis();
> for (int i = 0; i < len; i++) {
> test.orderBefore("n" + i, null);
> }
> System.out.println("sorted: " + (System.currentTimeMillis() - start));
> session.logout();
> Output:
> creating: 712
> sorted: 31281
> Possible solutions:
> - speed up Node.orderBefore
> - create a 'sorting tool' that uses the 'create new node' trick
> - create a new (Jackrabbit internal) solution to sort quickly

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2477) Log / trace wrapper: upgrade to JCR API 2.0

[Thomas Mueller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller resolved JCR-2477.
-

Resolution: Fixed

I think this issue is fixed now. If it doesn't work for you, please open a new 
bug

> Log / trace wrapper: upgrade to JCR API 2.0
> ---
>
> Key: JCR-2477
> URL: https://issues.apache.org/jira/browse/JCR-2477
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: sandbox
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>
> The JCR Log wrapper (jcrlog) currently only supports the JCR 1.0 API. It 
> should be upgraded to 2.0. Also, the dependency to jackrabbit-core should be 
> removed, and generics should be used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2049) A tool to support large or long running transactions

[Thomas Mueller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller resolved JCR-2049.
-

Resolution: Won't Fix

It seems this tool is not as important as I thought. I don't plan to implement 
it.

> A tool to support large or long running transactions
> 
>
> Key: JCR-2049
> URL: https://issues.apache.org/jira/browse/JCR-2049
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-jcr-commons
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
>
> I propose to write a tool for large or long running transactions. Instead of 
> keeping the changes in the transient space until a transaction is completed, 
> a backup of the current state is stored in a backup area. This allows to save 
> intermediate steps.
> I propose to create add a tool (probably just one class) in the 
> jackrabbit-jcr-commons project, package org.apache.jackrabbit.commons.tools:
> class LargeTransactionTool {
>   LargeTransactionTool getInstance(Session session, String backupPath);
>   beginTransaction();
>   deleteRecursive(Node n);
>   Node addNode(Node parent, String name);
>   backup(Node n);
>   backupRecursive(Node n);
>   commit();
>   rollback();
> }
> An application could then use the tool as follows:
> LargeTransactionTool tool = LargeTransactionTool.getInstance(session, 
> "/backupArea");
> tool.backup(n1);
> n1.setProperty(...);
> session.save();
> tool.deleteRecursive(n2);
> session.save();
> n4 = tool.addNode(n3, "x");
> session.save();
> tool.commit();

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2781) FileDataStore performance improvements

[JIRA]

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

Claus Köll commented on JCR-2781:
-

Hi Thomas it is no fix version labeld ..

greets

> FileDataStore performance improvements
> --
>
> Key: JCR-2781
> URL: https://issues.apache.org/jira/browse/JCR-2781
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
>
> As seen in JCR-2695, the FileDataStore is slow on some file system. 
> Some file operations such as File.exists() or File.isDirectory() can be 
> replaced with try / catch, or by inspecting the return value of a previous 
> method (File.renameTo).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-683) Bad transitive dependencies in commons-httpclient

[Sebb (JIRA)]

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

Sebb commented on JCR-683:
--

Commons httpclient 3.1 now uses  test for junit [1]

It still uses commons-logging, however.

[1] 
http://repo1.maven.org/maven2/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.pom

> Bad transitive dependencies in commons-httpclient
> -
>
> Key: JCR-683
> URL: https://issues.apache.org/jira/browse/JCR-683
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-webdav
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>Priority: Minor
> Fix For: 1.2.1
>
>
> As reported in HTTPCLIENT-605, the commons-httpclient 3.0 dependency 
> introduces junit as a transitive "compile" scope dependency. The library also 
> uses commons-logging, which sidesteps Jackrabbit's use of slf4j for logging.
> To avoid these issues we should locally override the junit dependency in 
> commons-httpclient and replace the commons-logging dependency with 
> jcl104-over-slf4j.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1455) Content browser/editor

[JIRA]

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

Claus Köll commented on JCR-1455:
-

After discussing about a good Web Content Explorer in our company i found 
a  Mail from 2008 where Greg Klebus announced the donation from the Content 
Explorer from day-software (http://markmail.org/message/xgf7od3si42wq6ly)
Are there any news about that donation ?


> Content browser/editor
> --
>
> Key: JCR-1455
> URL: https://issues.apache.org/jira/browse/JCR-1455
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-webapp
>Reporter: Jukka Zitting
>
> The Jackrabbit webapp should come with a web-based content browser/editor 
> tool that can be used to manage the content in the repository.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-2808) Hop 0 sample app doesn't exit because of on-daemon thread pool-1-thread-1

[Thomas Mueller (JIRA)]

Hop 0 sample app doesn't exit because of on-daemon thread pool-1-thread-1
-

 Key: JCR-2808
 URL: https://issues.apache.org/jira/browse/JCR-2808
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Reporter: Thomas Mueller


When starting the sample app Hop 0 (or any other Hop sample app) if there is no 
"repository" directory, then the application doesn't exit because there is a 
non-daemon thread named "pool-1-thread-1".

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2808) Hop 0 sample app doesn't exit because of on-daemon thread pool-1-thread-1

[Thomas Mueller (JIRA)]

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

Thomas Mueller commented on JCR-2808:
-

I couldn't find where the thread is created. Possibly this is related to 
search, because the problem goes away if I disable search in the repository.xml

> Hop 0 sample app doesn't exit because of on-daemon thread pool-1-thread-1
> -
>
> Key: JCR-2808
> URL: https://issues.apache.org/jira/browse/JCR-2808
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Reporter: Thomas Mueller
>
> When starting the sample app Hop 0 (or any other Hop sample app) if there is 
> no "repository" directory, then the application doesn't exit because there is 
> a non-daemon thread named "pool-1-thread-1".

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2808) Hop 0 sample app doesn't exit because of on-daemon thread pool-1-thread-1

[Thomas Mueller (JIRA)]

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

Thomas Mueller commented on JCR-2808:
-

The problem is DynamicPooledExecutor, which creates a ThreadPoolExecutor using 
the default ThreadFactory.

> Hop 0 sample app doesn't exit because of on-daemon thread pool-1-thread-1
> -
>
> Key: JCR-2808
> URL: https://issues.apache.org/jira/browse/JCR-2808
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Reporter: Thomas Mueller
>
> When starting the sample app Hop 0 (or any other Hop sample app) if there is 
> no "repository" directory, then the application doesn't exit because there is 
> a non-daemon thread named "pool-1-thread-1".

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2808) Hop 0 sample app doesn't exit because of on-daemon thread pool-1-thread-1

[Thomas Mueller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller resolved JCR-2808.
-

   Resolution: Fixed
Fix Version/s: 2.2.0
 Assignee: Thomas Mueller

> Hop 0 sample app doesn't exit because of on-daemon thread pool-1-thread-1
> -
>
> Key: JCR-2808
> URL: https://issues.apache.org/jira/browse/JCR-2808
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 2.2.0
>
>
> When starting the sample app Hop 0 (or any other Hop sample app) if there is 
> no "repository" directory, then the application doesn't exit because there is 
> a non-daemon thread named "pool-1-thread-1".

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2781) FileDataStore performance improvements

[Thomas Mueller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller updated JCR-2781:


Fix Version/s: 2.2.0

> FileDataStore performance improvements
> --
>
> Key: JCR-2781
> URL: https://issues.apache.org/jira/browse/JCR-2781
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 2.2.0
>
>
> As seen in JCR-2695, the FileDataStore is slow on some file system. 
> Some file operations such as File.exists() or File.isDirectory() can be 
> replaced with try / catch, or by inspecting the return value of a previous 
> method (File.renameTo).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (JCR-2740) On missing child node, automatically rename entry when trying to add a node with the same name

[Thomas Mueller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller reassigned JCR-2740:
---

Assignee: Thomas Mueller

> On missing child node, automatically rename entry when trying to add a node 
> with the same name
> --
>
> Key: JCR-2740
> URL: https://issues.apache.org/jira/browse/JCR-2740
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>
> If a node points to a non-existing child node (which is a repository 
> inconsistency), currently this child node is silently ignored for read 
> operations (as far as I can tell). However, when trying to add another child 
> node with the same name, an exception is thrown with a message saying a child 
> node with this name already exists.
> I suggest to rename the missing child node entry in that case (for example 
> add the current date/time, or a random digit until there is no conflict), and 
> then continue with adding the new child node. I wouldn't automatically remove 
> the bad entry, because the node might "appear" later (after a restore), and 
> because removing data from the repository seems wrong.
> It's not a perfect solution, but it might be better than throwing an 
> exception and basically preventing changes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2740) On missing child node, automatically rename entry when trying to add a node with the same name

[Thomas Mueller (JIRA)]

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

Thomas Mueller commented on JCR-2740:
-

I think it doesn't make much sense to move the broken child node *reference*, 
because it's not a node (the node itself doesn't exists). I guess we need to 
add all relevant test cases so existing features don't break.

> On missing child node, automatically rename entry when trying to add a node 
> with the same name
> --
>
> Key: JCR-2740
> URL: https://issues.apache.org/jira/browse/JCR-2740
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>
> If a node points to a non-existing child node (which is a repository 
> inconsistency), currently this child node is silently ignored for read 
> operations (as far as I can tell). However, when trying to add another child 
> node with the same name, an exception is thrown with a message saying a child 
> node with this name already exists.
> I suggest to rename the missing child node entry in that case (for example 
> add the current date/time, or a random digit until there is no conflict), and 
> then continue with adding the new child node. I wouldn't automatically remove 
> the bad entry, because the node might "appear" later (after a restore), and 
> because removing data from the repository seems wrong.
> It's not a perfect solution, but it might be better than throwing an 
> exception and basically preventing changes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2740) On missing child node, automatically rename entry when trying to add a node with the same name

[Thomas Mueller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Mueller updated JCR-2740:


Attachment: jcr-2740.patch

Could those that are familiar with NodeImpl please have a look at the changes 
and provide feedback? I know it's not a "real" unit test case yet (I will 
change that later on).

The solution doesn't try to solve all possible edge cases. It's just a simple 
solution for the most common problems. For edge cases we can use the existing 
consistency check and fix. This is just for the most common cases, for old 
repositories where it was relatively easy to get corruptions. I believe with 
more recent versions of Jackrabbit it's very hard to get corruptions. At least, 
that's the plan - if it's not the case yet then I believe we should spend most 
of our time in hardening Jackrabbit, and not in automatically fixing problems 
:-)

> On missing child node, automatically rename entry when trying to add a node 
> with the same name
> --
>
> Key: JCR-2740
> URL: https://issues.apache.org/jira/browse/JCR-2740
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Attachments: jcr-2740.patch
>
>
> If a node points to a non-existing child node (which is a repository 
> inconsistency), currently this child node is silently ignored for read 
> operations (as far as I can tell). However, when trying to add another child 
> node with the same name, an exception is thrown with a message saying a child 
> node with this name already exists.
> I suggest to rename the missing child node entry in that case (for example 
> add the current date/time, or a random digit until there is no conflict), and 
> then continue with adding the new child node. I wouldn't automatically remove 
> the bad entry, because the node might "appear" later (after a restore), and 
> because removing data from the repository seems wrong.
> It's not a perfect solution, but it might be better than throwing an 
> exception and basically preventing changes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1670) NPE when clustered JR queries version history on a node that has just had a version added by another JR in the same cluster

[Jukka Zitting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-1670:
---

Remaining Estimate: 0h
 Original Estimate: 0h

> NPE when clustered JR queries version history on a node that has just had a 
> version added by another JR in the same cluster
> ---
>
> Key: JCR-1670
> URL: https://issues.apache.org/jira/browse/JCR-1670
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: clustering, jackrabbit-core
>Affects Versions: core 1.4.3
> Environment: Windows XP servers, JDK 1.5.2.02, in process. Microsoft 
> SQL 2005 bundled persistence manager, datastore.
>Reporter: Brett Connor
>Priority: Critical
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Two computers A and B running jboss webapp, including in-process Jackrabbit 
> instances in a cluster.
> - A checks out a versioned node, then checks it in and unlocks it
> - A notifies B (through a non JR mechanism) that the node has been updated
> - B finds the node (by UUID) and calls getVersionHistory().getAllVersions()
> This results in java.lang.NullPointerException
>   at 
> org.apache.jackrabbit.core.version.VersionIteratorImpl.addVersion(VersionIteratorImpl.java:147)
>   at org.apache.jackrabbit.core.version.VersionIteratorImpl. 
> (VersionIteratorImpl.java:68)
>   at 
> org.apache.jackrabbit.core.version.VersionHistoryImpl.getAllVersions(VersionHistoryImpl.java:95)
> The addVersion() method is synchronized, but looks like it's reading a null 
> from 'successors'.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1670) NPE when clustered JR queries version history on a node that has just had a version added by another JR in the same cluster

[Jukka Zitting (JIRA)]

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

Jukka Zitting commented on JCR-1670:


This got fixed in JCR-2655, so resolving as a duplicate.

> NPE when clustered JR queries version history on a node that has just had a 
> version added by another JR in the same cluster
> ---
>
> Key: JCR-1670
> URL: https://issues.apache.org/jira/browse/JCR-1670
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: clustering, jackrabbit-core
>Affects Versions: core 1.4.3
> Environment: Windows XP servers, JDK 1.5.2.02, in process. Microsoft 
> SQL 2005 bundled persistence manager, datastore.
>Reporter: Brett Connor
>Priority: Critical
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Two computers A and B running jboss webapp, including in-process Jackrabbit 
> instances in a cluster.
> - A checks out a versioned node, then checks it in and unlocks it
> - A notifies B (through a non JR mechanism) that the node has been updated
> - B finds the node (by UUID) and calls getVersionHistory().getAllVersions()
> This results in java.lang.NullPointerException
>   at 
> org.apache.jackrabbit.core.version.VersionIteratorImpl.addVersion(VersionIteratorImpl.java:147)
>   at org.apache.jackrabbit.core.version.VersionIteratorImpl. 
> (VersionIteratorImpl.java:68)
>   at 
> org.apache.jackrabbit.core.version.VersionHistoryImpl.getAllVersions(VersionHistoryImpl.java:95)
> The addVersion() method is synchronized, but looks like it's reading a null 
> from 'successors'.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-1670) NPE when clustered JR queries version history on a node that has just had a version added by another JR in the same cluster

[Jukka Zitting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-1670.


Resolution: Duplicate

> NPE when clustered JR queries version history on a node that has just had a 
> version added by another JR in the same cluster
> ---
>
> Key: JCR-1670
> URL: https://issues.apache.org/jira/browse/JCR-1670
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: clustering, jackrabbit-core
>Affects Versions: core 1.4.3
> Environment: Windows XP servers, JDK 1.5.2.02, in process. Microsoft 
> SQL 2005 bundled persistence manager, datastore.
>Reporter: Brett Connor
>Priority: Critical
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Two computers A and B running jboss webapp, including in-process Jackrabbit 
> instances in a cluster.
> - A checks out a versioned node, then checks it in and unlocks it
> - A notifies B (through a non JR mechanism) that the node has been updated
> - B finds the node (by UUID) and calls getVersionHistory().getAllVersions()
> This results in java.lang.NullPointerException
>   at 
> org.apache.jackrabbit.core.version.VersionIteratorImpl.addVersion(VersionIteratorImpl.java:147)
>   at org.apache.jackrabbit.core.version.VersionIteratorImpl. 
> (VersionIteratorImpl.java:68)
>   at 
> org.apache.jackrabbit.core.version.VersionHistoryImpl.getAllVersions(VersionHistoryImpl.java:95)
> The addVersion() method is synchronized, but looks like it's reading a null 
> from 'successors'.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Hudson build became unstable: Jackrabbit-trunk #1346

[Apache Hudson Server]

See 

[jira] Resolved: (JCR-2763) Drop the Dumpable interface

[Jukka Zitting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-2763.


   Resolution: Fixed
Fix Version/s: 2.2.0
 Assignee: Jukka Zitting

Done also for jcr2spi in revision 1032651.

> Drop the Dumpable interface
> ---
>
> Key: JCR-2763
> URL: https://issues.apache.org/jira/browse/JCR-2763
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core, jackrabbit-spi2jcr
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>Priority: Trivial
> Fix For: 2.2.0
>
>
> I belive the o.a.j.core.util.Dumpable interface was originally used for 
> diagnostic purposes, but AFAIUI we don't use it anywhere anymore. I'd like to 
> drop the interface and refactor the dump() methods in various Jackrabbit 
> classes to more detailed toString() methods that would be more useful to 
> debuggers and other general-purpose diagnostic tools.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2078) InvalidItemState after some rollbacks with XA Resource

[Jukka Zitting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-2078.


Resolution: Duplicate

This got fixed in JCR-2712, so resolving as a duplicate.

> InvalidItemState after some rollbacks with XA Resource
> --
>
> Key: JCR-2078
> URL: https://issues.apache.org/jira/browse/JCR-2078
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core, transactions
>Affects Versions: 1.4, 1.5.4
>Reporter: Juergen Melzer
>Priority: Critical
>
> I modified a versionable node and do a rollback, after 3 to 10 iterations the 
> test will fail.
> Here is a simple testcase to demonstrate the situation.
> import junit.framework.TestCase;
> import org.apache.jackrabbit.core.RepositoryImpl;
> import org.apache.jackrabbit.core.config.RepositoryConfig;
> import org.springframework.core.io.ClassPathResource;
> import org.springmodules.jcr.jackrabbit.support.JackRabbitUserTransaction;
> import org.xml.sax.InputSource;
> import javax.jcr.*;
> import java.io.File;
> public class NoSuchItemStateExceptionTest extends TestCase {
> private static final File TARGET = new File("target");
> private static final String REPO_HOME = "repository-lock-test";
> public void testIt2() throws Exception {
> RepositoryConfig config =
> RepositoryConfig.create(new InputSource(new 
> ClassPathResource("repository.xml").getInputStream()),
> REPO_HOME);
> final Repository repository = RepositoryImpl.create(config);
> SimpleCredentials credentials = new SimpleCredentials("1", 
> "1".toCharArray());
> Session sess = repository.login(credentials);
> for (int i = 0; i < 100; i++) {
> JackRabbitUserTransaction tx = new 
> JackRabbitUserTransaction(sess);
> tx.begin();
> System.out.println("i=" + i);
> Node root = sess.getRootNode();
> createNode(sess, root);
> tx.rollback();
> }
> }
> void createNode(Session sess, Node root) throws RepositoryException {
> Node nodeType = root.addNode("first");
> Node n = nodeType.addNode("second");
> n.addMixin("mix:versionable");
> Node n2 = nodeType.addNode("second2");
> n2.addMixin("mix:versionable");
> sess.save();
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-537) Failure to remove a versionable node

[Jukka Zitting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-537.
---

Resolution: Cannot Reproduce

I tried reproducing this but couldn't. I believe we've fixed this somewhere 
along the line.

> Failure to remove a versionable node
> 
>
> Key: JCR-537
> URL: https://issues.apache.org/jira/browse/JCR-537
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core, versioning
>Affects Versions: 1.1
>Reporter: Florent Guillaume
>Assignee: Tobias Bocanegra
> Attachments: var.tgz
>
>
> This happens on current trunk.
> When running the following code on the attached jackrabbit repository,
> (sorry, Jython code, I trust the conversion to Java is trivial):
> from javax.jcr import SimpleCredentials
> from org.apache.jackrabbit.core import TransientRepository
> uuid = "83f6e473-3fe2-4584-9570-4e18a0cd6688"
> repoconf = "var/jackrabbit.xml"
> repopath = "var/jackrabbit"
> credentials = SimpleCredentials("username", "password")
> repository = TransientRepository(repoconf, repopath)
> session = repository.login(credentials, "default")
> root = session.getRootNode()
> node = session.getNodeByUUID(uuid)
> node.remove()
> root.save()
> I get the following error:
> org.apache.jackrabbit.core.state.NoSuchItemStateException: 
> c147b847-8ba5-4fe9-a890-481586476510
> at 
> org.apache.jackrabbit.core.state.SharedItemStateManager.getNodeReferences(SharedItemStateManager.java:307)
> at 
> org.apache.jackrabbit.core.state.SharedItemStateManager.updateReferences(SharedItemStateManager.java:1046)
> at 
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:484)
> at 
> org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:687)
> at 
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:717)
> at 
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:316)
> at 
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:323)
> at 
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:292)
> at 
> org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:258)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1209)
> ...
> javax.jcr.RepositoryException: javax.jcr.RepositoryException: /: unable to 
> update item.: c147b847-8ba5-4fe9-a890-481586476510: 
> c147b847-8ba5-4fe9-a890-481586476510
> The uuid I'm trying to delete is that of a document at path
>   /workspaces/ecm:children/subfolder/ecm:children/ghtgh
> The uuid mentioned in the error is the one of its version history.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Hudson build is back to stable : Jackrabb it-trunk » Jackrabbit JCR to WebDAV #1347

[Apache Hudson Server]

See 

Hudson build is back to stable : Jackrabbit-trunk #1347

[Apache Hudson Server]

See 

[jira] Resolved: (JCR-2796) Restoring a node fails (partially) if done within a XA transaction

[Jukka Zitting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-2796.


   Resolution: Fixed
Fix Version/s: 2.2.0
 Assignee: Jukka Zitting

Thanks for reporting this, and for including a good test case! Fixed in 
revision 1032770.

> Restoring a node fails (partially) if done within a XA transaction
> --
>
> Key: JCR-2796
> URL: https://issues.apache.org/jira/browse/JCR-2796
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.1.1
> Environment: Jackrabbit 2.1.1
>Reporter: Dominik Klaholt
>Assignee: Jukka Zitting
> Fix For: 2.2.0
>
>
> A problem occurs with the following sequence of steps: 
> 1) Create a versionable node that has a child and a grandchild.
> 2) Perform a check-in of the versionable node and give a version-label.
> 3) Perform a restore by using the version-label.
> 4) Access the grandchild.
> Step 4 fails, if step 3 is executed within a transaction. If no transaction 
> is used, then step 4 succeeds. 
> The test-case attached below can be executed within XATest.java 
> (http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/test/java/org/apache/jackrabbit/core/XATest.java).
> public void testRestore() throws Exception {
> Session session = null;
> try {
> session = getHelper().getSuperuserSession();
> // make sure that 'testNode' does not exist at the beginning of 
> the test
> for (NodeIterator ni = session.getRootNode().getNodes(); 
> ni.hasNext();) {
> Node aNode = ni.nextNode();
> if (aNode.getName().equals("testNode")) {
> aNode.remove();
> }
> }
> // 1) create 'testNode' that has a child and a grandchild
> 
> session.getRootNode().addNode("testNode").addMixin(NodeType.MIX_VERSIONABLE);
> 
> session.getRootNode().getNode("testNode").addNode("child").addNode("grandchild");
> session.save();
> // 2) check in 'testNode' and give a version-label
> Version version = 
> session.getWorkspace().getVersionManager().checkin(
> session.getRootNode().getNode("testNode").getPath());
> session.getWorkspace().getVersionManager().getVersionHistory(
> 
> session.getRootNode().getNode("testNode").getPath()).addVersionLabel(version.getName(),
> "testLabel", false);
> // 3) do restore by label
> UserTransaction utx = new UserTransactionImpl(session);
> utx.begin();
> session.getWorkspace().getVersionManager().restoreByLabel(
> session.getRootNode().getNode("testNode").getPath(), 
> "testLabel", true);
> utx.commit();
> // 4) try to get the grandchild (fails if the restoring has been 
> done within a transaction)
> 
> session.getRootNode().getNode("testNode").getNode("child").getNode("grandchild");
> } finally {
> if (session != null) {
> session.logout();
> }
> }
> } 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2298) NPE in EventStateCollection

[Jukka Zitting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-2298.


   Resolution: Fixed
Fix Version/s: 2.2.0
 Assignee: Jukka Zitting

Resolving as fixed based on the above partial solution. If we need a more 
complete solution, we can do that in a separate followup issue.

> NPE in EventStateCollection
> ---
>
> Key: JCR-2298
> URL: https://issues.apache.org/jira/browse/JCR-2298
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core, transactions, versioning
>Affects Versions: 1.6.0
>Reporter: quipere
>Assignee: Jukka Zitting
> Fix For: 2.2.0
>
>
> When removing a Version with a versionlabel and restoring an other Version 
> from the same containing history within 1 transaction, a NPE occured. When 
> debugging I noticed the method createEventStates was entered with an UUID 
> from a versionLabel. The ChangeLog.get(id) returned null.
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.jackrabbit.core.observation.EventStateCollection.getNodeType(EventStateCollection.java:614)
>   at 
> org.apache.jackrabbit.core.observation.EventStateCollection.createEventStates(EventStateCollection.java:381)
>   at 
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:697)
>   at 
> org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1085)
>   at 
> org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:163)
>   at 
> org.apache.jackrabbit.core.version.XAVersionManager.prepare(XAVersionManager.java:509)
>   at 
> org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:154)
>   at 
> org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:331)
>   at 
> org.springmodules.jcr.jackrabbit.support.JackRabbitUserTransaction.commit(JackRabbitUserTransaction.java:100)
>   at 
> org.springmodules.jcr.jackrabbit.LocalTransactionManager.doCommit(LocalTransactionManager.java:192)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-1223) Ocassionally NPE on node checkin

[Jukka Zitting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-1223.


Resolution: Duplicate

This problem was fixed in JCR-2655, so resolving as a duplicate.

> Ocassionally NPE on node checkin
> 
>
> Key: JCR-1223
> URL: https://issues.apache.org/jira/browse/JCR-1223
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core, versioning
>Affects Versions: 1.3.1
>Reporter: Christoph Kiehl
> Attachments: JR-stacktrace.txt
>
>
> I find the following Exception in our log files from time to time. I don't 
> know how to replicate it and I couldn't find a ticket in Jira nor seemed the 
> recent changes on the participating classes in trunk handling this error:
> java.lang.NullPointerException
> at 
> org.apache.jackrabbit.core.version.InternalVersionImpl.storeXCessors(InternalVersionImpl.java:225)
> at 
> org.apache.jackrabbit.core.version.InternalVersionImpl.internalAddSuccessor(InternalVersionImpl.java:281)
> at 
> org.apache.jackrabbit.core.version.InternalVersionImpl.internalAttach(InternalVersionImpl.java:265)
> at 
> org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.checkin(InternalVersionHistoryImpl.java:444)
> at 
> org.apache.jackrabbit.core.version.AbstractVersionManager.checkin(AbstractVersionManager.java:375)
> at 
> org.apache.jackrabbit.core.version.XAVersionManager.checkin(XAVersionManager.java:368)
> at 
> org.apache.jackrabbit.core.version.XAVersionManager.checkin(XAVersionManager.java:157)
> at org.apache.jackrabbit.core.NodeImpl.checkin(NodeImpl.java:2933) 
> [...]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2802) Deprecate all non-bundle persistence managers

[Jukka Zitting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-2802.


Resolution: Fixed
  Assignee: Jukka Zitting

I deprecated all the non-bundle persistence managers in revision 1032784.

In revision 1032787 I added a generic mechanism that logs warnings for all 
kinds of deprecated configuration entries.

> Deprecate all non-bundle persistence managers
> -
>
> Key: JCR-2802
> URL: https://issues.apache.org/jira/browse/JCR-2802
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: config, jackrabbit-core
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
> Fix For: 2.2.0
>
>
> Bundle persistence has been the recommended default since Jackrabbit 1.3, and 
> there is little reason for anyone to be using non-bundle persistence anymore. 
> Thus I'd like to deprecate all non-bundle PMs in Jackrabbit 2.2 and target 
> for their removal in Jackrabbit 3.0.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.