[jira] [Commented] (JCRVLT-683) Import of Authorizable node with acHandling=IGNORE should preserve existing rep:principalPolicy child node
[ https://issues.apache.org/jira/browse/JCRVLT-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719725#comment-17719725 ] Thomas Mueller commented on JCRVLT-683: --- > Well in this case I don't think it is necessary but if you want to add a > toggle please enrich the PR. Well, that's not how reviews work... You don't ask the reviewer to add something that the author should do. > Import of Authorizable node with acHandling=IGNORE should preserve existing > rep:principalPolicy child node > -- > > Key: JCRVLT-683 > URL: https://issues.apache.org/jira/browse/JCRVLT-683 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: Packaging >Affects Versions: 3.6.6 >Reporter: Mark Adamcin >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.6.10 > > > For situations where an authorizable node may be distributed from another > environment where a different rep:principalPolicy for the user is defined > than exists for that user in the target environment, it is important that the > existing rep:principalPolicy be preserved when acHandling is unset, > acHandling=IGNORE, or acHandling=MERGE_PRESERVE. > Currently, the effective behavior of such a package install, as [it appears > to be implemented in > DocViewImporter|https://github.com/apache/jackrabbit-filevault/blob/5f9657374bd6c2d3dd1f6e9e2be0b9f5b25ddc26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewImporter.java#L782-L787], > results in the following: > * If the package specifies acHandling=IGNORE, the existing > rep:principalPolicy is deleted without replacement, regardless of whether the > package contains its own rep:principalPolicy, which is equivalent to > *acHandling=CLEAR* > * If the package specifies acHandling=MERGE_PRESERVE or MERGE, the existing > rep:principalPolicy is replaced with whatever rep:principalPolicy is > contained in the package, or deletes the policy if a replacement is not > present, which is equivalent to *acHandling=OVERWRITE* > Unexpectedly, the least destructive (and most default) acHandling mode > (IGNORE) turns out to be as destructive to packaged system user permissions > as choosing any other mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-683) Import of Authorizable node with acHandling=IGNORE should preserve existing rep:principalPolicy child node
[ https://issues.apache.org/jira/browse/JCRVLT-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719719#comment-17719719 ] Thomas Mueller edited comment on JCRVLT-683 at 5/5/23 7:49 AM: --- > Every code relying on that bug can be easily fixed by adjusting the > aclHandling. In general, I think that most bugfixes should come with "circuit breakers" (feature flags) that allow people to disable the "bugfix", specially if the bugfix changes behavior. In the past, we have used system properties to allow switching back to the old behavior. (There are bugfixes that _don't_ change the behavior, for example if they only improve performance.) I also think that most changes should be reviewed. It seems the linked PRs don't currently have reviewers; is think the review process is done in some other way? Update: sorry, https://github.com/apache/jackrabbit-filevault/pull/272 doesn't have reviewers; https://github.com/apache/jackrabbit-filevault/pull/294 has reviewers. PRs should also come with test cases. Is it true that https://github.com/apache/jackrabbit-filevault/pull/294/files doesn't have any test case? There are a lot of code changes as far as I see. was (Author: tmueller): > Every code relying on that bug can be easily fixed by adjusting the > aclHandling. In general, I think that most bugfixes should come with "circuit breakers" (feature flags) that allow people to disable the "bugfix", specially if the bugfix changes behavior. In the past, we have used system properties to allow switching back to the old behavior. (There are bugfixes that _don't_ change the behavior, for example if they only improve performance.) I also think that most changes should be reviewed. It seems the linked PRs don't currently have reviewers; is think the review process is done in some other way? PRs should also come with test cases. Is it true that https://github.com/apache/jackrabbit-filevault/pull/294/files doesn't have any test case? There are a lot of code changes as far as I see. > Import of Authorizable node with acHandling=IGNORE should preserve existing > rep:principalPolicy child node > -- > > Key: JCRVLT-683 > URL: https://issues.apache.org/jira/browse/JCRVLT-683 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: Packaging >Affects Versions: 3.6.6 >Reporter: Mark Adamcin >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.6.10 > > > For situations where an authorizable node may be distributed from another > environment where a different rep:principalPolicy for the user is defined > than exists for that user in the target environment, it is important that the > existing rep:principalPolicy be preserved when acHandling is unset, > acHandling=IGNORE, or acHandling=MERGE_PRESERVE. > Currently, the effective behavior of such a package install, as [it appears > to be implemented in > DocViewImporter|https://github.com/apache/jackrabbit-filevault/blob/5f9657374bd6c2d3dd1f6e9e2be0b9f5b25ddc26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewImporter.java#L782-L787], > results in the following: > * If the package specifies acHandling=IGNORE, the existing > rep:principalPolicy is deleted without replacement, regardless of whether the > package contains its own rep:principalPolicy, which is equivalent to > *acHandling=CLEAR* > * If the package specifies acHandling=MERGE_PRESERVE or MERGE, the existing > rep:principalPolicy is replaced with whatever rep:principalPolicy is > contained in the package, or deletes the policy if a replacement is not > present, which is equivalent to *acHandling=OVERWRITE* > Unexpectedly, the least destructive (and most default) acHandling mode > (IGNORE) turns out to be as destructive to packaged system user permissions > as choosing any other mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-683) Import of Authorizable node with acHandling=IGNORE should preserve existing rep:principalPolicy child node
[ https://issues.apache.org/jira/browse/JCRVLT-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719719#comment-17719719 ] Thomas Mueller commented on JCRVLT-683: --- > Every code relying on that bug can be easily fixed by adjusting the > aclHandling. In general, I think that most bugfixes should come with "circuit breakers" (feature flags) that allow people to disable the "bugfix", specially if the bugfix changes behavior. In the past, we have used system properties to allow switching back to the old behavior. (There are bugfixes that _don't_ change the behavior, for example if they only improve performance.) I also think that most changes should be reviewed. It seems the linked PRs don't currently have reviewers; is think the review process is done in some other way? PRs should also come with test cases. Is it true that https://github.com/apache/jackrabbit-filevault/pull/294/files doesn't have any test case? There are a lot of code changes as far as I see. > Import of Authorizable node with acHandling=IGNORE should preserve existing > rep:principalPolicy child node > -- > > Key: JCRVLT-683 > URL: https://issues.apache.org/jira/browse/JCRVLT-683 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: Packaging >Affects Versions: 3.6.6 >Reporter: Mark Adamcin >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.6.10 > > > For situations where an authorizable node may be distributed from another > environment where a different rep:principalPolicy for the user is defined > than exists for that user in the target environment, it is important that the > existing rep:principalPolicy be preserved when acHandling is unset, > acHandling=IGNORE, or acHandling=MERGE_PRESERVE. > Currently, the effective behavior of such a package install, as [it appears > to be implemented in > DocViewImporter|https://github.com/apache/jackrabbit-filevault/blob/5f9657374bd6c2d3dd1f6e9e2be0b9f5b25ddc26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewImporter.java#L782-L787], > results in the following: > * If the package specifies acHandling=IGNORE, the existing > rep:principalPolicy is deleted without replacement, regardless of whether the > package contains its own rep:principalPolicy, which is equivalent to > *acHandling=CLEAR* > * If the package specifies acHandling=MERGE_PRESERVE or MERGE, the existing > rep:principalPolicy is replaced with whatever rep:principalPolicy is > contained in the package, or deletes the policy if a replacement is not > present, which is equivalent to *acHandling=OVERWRITE* > Unexpectedly, the least destructive (and most default) acHandling mode > (IGNORE) turns out to be as destructive to packaged system user permissions > as choosing any other mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-496) Clarify usage of oak:index in application packages
[ https://issues.apache.org/jira/browse/JCRVLT-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290024#comment-17290024 ] Thomas Mueller commented on JCRVLT-496: --- > Should index definitions be allowed by default or just if an explicit boolean > flag is set inside application packages? Whatever we need to do, we need to verify and possibly update the documentation everywhere. Not just in the vault-doc. Right now PackageTypeValidator.java has hardcoded paths for /apps + /libs, which isn't nice. Having DEFAULT_IMMUTABLE_ROOT_NODE_NAMES is better, if there is no way to auto-detect (?) But the patch itself doesn't seem to introduce a flag? Maybe I didn't see it yet... but "prohibitMutableContent" is already there it seems. > Clarify usage of oak:index in application packages > -- > > Key: JCRVLT-496 > URL: https://issues.apache.org/jira/browse/JCRVLT-496 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.4.8 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.10 > > > Although according to JCRVLT-170 application packages must not contain oak > index definitions, this is necessary though for AEM as a Cloud Service > (https://experienceleague.adobe.com/docs/experience-manager-cloud-service/operations/indexing.html?lang=en#index-management-using-blue-green-deployments > and > https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/developing/aem-project-content-package-structure.html?lang=en#mutable-vs-immutable). > To allow validation of such application packages there should be a flag > considered, which allows for oak index definitions inside application > packages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-163) Allow to define compression levels
[
https://issues.apache.org/jira/browse/JCRVLT-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15899314#comment-15899314
]
Thomas Mueller commented on JCRVLT-163:
---
I guess the vast majority of binary data is stored in "jcr:data" properties.
But not all, and the list of possible mime types is relatively large. Also, for
some mime types, data is not always compressed (for example tiff).
For such cases, it might be interesting to use
[auto-detection|http://stackoverflow.com/questions/7027022/how-to-efficiently-predict-if-data-is-compressible].
This can be done with low overhead, without knowing the content type, and
without configuration options. Sample code is available in one of the answers
("I implemented a few methods to test if data is compressible…"). It is quite
simple, and only needs to process 256 bytes. Both the "Partial Entropy" and the
"Simplified Compression" work relatively well. This is not designed to be a
"perfect" solution for the problem. It's a low-overhead heuristic, that will
reduce the compression overhead on the average.
> Allow to define compression levels
> --
>
> Key: JCRVLT-163
> URL: https://issues.apache.org/jira/browse/JCRVLT-163
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.0
>Reporter: Timothee Maret
> Fix For: 3.1.36
>
>
> As discussed in [0], this issue tracks allowing to specify the compression
> level when building packages. The primary idea is to avoid compressing
> (compression level = {{NO_COMPRESSION}}) already compressed binaries,
> identified based on their MIME type.
> Setting the compression level is a tradeoff between the compression speed and
> the size of the compressed artefacts.
> Different use cases likely favour maximising either of the two.
> Therefor, it may make sense to allow configuring the compression levels per
> use case (not globally).
> A generic way to express this configuration would be:
> * a mapping from MIME type to compression level
> * the default level (for MIME type not matching any entry in the mapping)
> [0] https://www.mail-archive.com/dev@jackrabbit.apache.org/msg37807.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)
[ https://issues.apache.org/jira/browse/JCR-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-4115: Attachment: JCR-4115b.patch JCR-4115b.patch: new patch, including changes to the test case > Don't use SHA-1 for new DataStore binaries (Jackrabbit) > --- > > Key: JCR-4115 > URL: https://issues.apache.org/jira/browse/JCR-4115 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Reporter: Thomas Mueller > Labels: candidate_jcr_2_10, candidate_jcr_2_12, > candidate_jcr_2_14, candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8 > Attachments: JCR-4115b.patch, JCR-4115.patch > > > A collision for SHA-1 has been published. We still use SHA-1 for the > FileDataStore, and I believe the S3 DataStore right now. Given there is a > collision, we should switch to a stronger algorithm, for example SHA-256, for > new binaries. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)
[
https://issues.apache.org/jira/browse/JCR-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882713#comment-15882713
]
Thomas Mueller commented on JCR-4115:
-
Patch for the test case, with generator function
{noformat}
--- src/test/java/org/apache/jackrabbit/core/data/DataStoreTest.java
(revision 1784247)
+++ src/test/java/org/apache/jackrabbit/core/data/DataStoreTest.java
(working copy)
@@ -24,12 +24,19 @@
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.File;
+import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
+import java.io.OutputStream;
+import java.nio.ByteBuffer;
+import java.security.DigestOutputStream;
+import java.security.MessageDigest;
+import java.security.NoSuchAlgorithmException;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.ArrayList;
import java.util.HashMap;
+import java.util.HashSet;
import java.util.Random;
/**
@@ -103,14 +110,35 @@
}
}
+public static void main(String... args) throws NoSuchAlgorithmException {
+// create and print a "directory-collision", that is, two byte arrays
+// where the hash starts with the same bytes
+// those values can be used for testDeleteRecordWithParentCollision
+HashMap map = new HashMap();
+MessageDigest digest = MessageDigest.getInstance("SHA-256");
+ByteBuffer input = ByteBuffer.allocate(8);
+byte[] array = input.array();
+for(long x = 0;; x++) {
+input.putLong(x).flip();
+long h = ByteBuffer.wrap(digest.digest(array)).getLong();
+Long old = map.put(h & 0xff00L, x);
+if (old != null) {
+System.out.println(Long.toHexString(old) + " " +
Long.toHexString(x));
+break;
+}
+}
+}
+
public void testDeleteRecordWithParentCollision() throws Exception {
FileDataStore fds = new FileDataStore();
fds.init(testDir + "/fileDeleteCollision");
-String c1 = "06b2f82fd81b2c20";
-String c2 = "02c60cb75083ceef";
-DataRecord d1 = fds.addRecord(IOUtils.toInputStream(c1));
-DataRecord d2 = fds.addRecord(IOUtils.toInputStream(c2));
+ByteArrayInputStream c1 = new ByteArrayInputStream(ByteBuffer
+.allocate(8).putLong(0x181c7).array());
+ByteArrayInputStream c2 = new ByteArrayInputStream(ByteBuffer
+.allocate(8).putLong(0x11fd78).array());
+DataRecord d1 = fds.addRecord(c1);
+DataRecord d2 = fds.addRecord(c2);
fds.deleteRecord(d1.getIdentifier());
DataRecord testRecord = fds.getRecordIfStored(d2.getIdentifier());
{noformat}
> Don't use SHA-1 for new DataStore binaries (Jackrabbit)
> ---
>
> Key: JCR-4115
> URL: https://issues.apache.org/jira/browse/JCR-4115
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
>Reporter: Thomas Mueller
> Labels: candidate_jcr_2_10, candidate_jcr_2_12,
> candidate_jcr_2_14, candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8
> Attachments: JCR-4115.patch
>
>
> A collision for SHA-1 has been published. We still use SHA-1 for the
> FileDataStore, and I believe the S3 DataStore right now. Given there is a
> collision, we should switch to a stronger algorithm, for example SHA-256, for
> new binaries.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)
[ https://issues.apache.org/jira/browse/JCR-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882664#comment-15882664 ] Thomas Mueller commented on JCR-4115: - [~julian.resc...@gmx.de] just noticed, DataStoreTest.testDeleteRecordWithParentCollision fails. This test relies on SHA-1, and would need to be changed. By the way, testDeleteRecordWithoutParentCollision should probably also be changed, even thought it doesn't fail - it also relies on SHA-1. > Don't use SHA-1 for new DataStore binaries (Jackrabbit) > --- > > Key: JCR-4115 > URL: https://issues.apache.org/jira/browse/JCR-4115 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Reporter: Thomas Mueller > Labels: candidate_jcr_2_10, candidate_jcr_2_12, > candidate_jcr_2_14, candidate_jcr_2_4, candidate_jcr_2_6, candidate_jcr_2_8 > Attachments: JCR-4115.patch > > > A collision for SHA-1 has been published. We still use SHA-1 for the > FileDataStore, and I believe the S3 DataStore right now. Given there is a > collision, we should switch to a stronger algorithm, for example SHA-256, for > new binaries. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)
[ https://issues.apache.org/jira/browse/JCR-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882491#comment-15882491 ] Thomas Mueller commented on JCR-4115: - [~ajain] could you please review the patch? > Don't use SHA-1 for new DataStore binaries (Jackrabbit) > --- > > Key: JCR-4115 > URL: https://issues.apache.org/jira/browse/JCR-4115 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Reporter: Thomas Mueller > Attachments: JCR-4115.patch > > > A collision for SHA-1 has been published. We still use SHA-1 for the > FileDataStore, and I believe the S3 DataStore right now. Given there is a > collision, we should switch to a stronger algorithm, for example SHA-256, for > new binaries. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)
[ https://issues.apache.org/jira/browse/JCR-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882257#comment-15882257 ] Thomas Mueller edited comment on JCR-4115 at 2/24/17 9:24 AM: -- Not sure if AbstractDataStore.HmacSHA1 is also affected or not. Probably not, because it uses DataIdentifier.toString() as the input. was (Author: tmueller): Not sure if AbstractDataStore.HmacSHA1 is also affected or not. > Don't use SHA-1 for new DataStore binaries (Jackrabbit) > --- > > Key: JCR-4115 > URL: https://issues.apache.org/jira/browse/JCR-4115 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Reporter: Thomas Mueller > > A collision for SHA-1 has been published. We still use SHA-1 for the > FileDataStore, and I believe the S3 DataStore right now. Given there is a > collision, we should switch to a stronger algorithm, for example SHA-256, for > new binaries. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)
[ https://issues.apache.org/jira/browse/JCR-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-4115: Attachment: JCR-4115.patch JCR-4115.patch (patch for testing). Just jackrabbit-data. > Don't use SHA-1 for new DataStore binaries (Jackrabbit) > --- > > Key: JCR-4115 > URL: https://issues.apache.org/jira/browse/JCR-4115 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Reporter: Thomas Mueller > Attachments: JCR-4115.patch > > > A collision for SHA-1 has been published. We still use SHA-1 for the > FileDataStore, and I believe the S3 DataStore right now. Given there is a > collision, we should switch to a stronger algorithm, for example SHA-256, for > new binaries. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)
[ https://issues.apache.org/jira/browse/JCR-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882288#comment-15882288 ] Thomas Mueller commented on JCR-4115: - We could also use the approach here to detect problematic binaries: https://github.com/cr-marcstevens/sha1collisiondetection > Don't use SHA-1 for new DataStore binaries (Jackrabbit) > --- > > Key: JCR-4115 > URL: https://issues.apache.org/jira/browse/JCR-4115 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Reporter: Thomas Mueller > > A collision for SHA-1 has been published. We still use SHA-1 for the > FileDataStore, and I believe the S3 DataStore right now. Given there is a > collision, we should switch to a stronger algorithm, for example SHA-256, for > new binaries. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)
[ https://issues.apache.org/jira/browse/JCR-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882257#comment-15882257 ] Thomas Mueller commented on JCR-4115: - Not sure if AbstractDataStore.HmacSHA1 is also affected or not. > Don't use SHA-1 for new DataStore binaries (Jackrabbit) > --- > > Key: JCR-4115 > URL: https://issues.apache.org/jira/browse/JCR-4115 > Project: Jackrabbit Content Repository > Issue Type: Improvement >Reporter: Thomas Mueller > > A collision for SHA-1 has been published. We still use SHA-1 for the > FileDataStore, and I believe the S3 DataStore right now. Given there is a > collision, we should switch to a stronger algorithm, for example SHA-256, for > new binaries. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)
Thomas Mueller created JCR-4115: --- Summary: Don't use SHA-1 for new DataStore binaries (Jackrabbit) Key: JCR-4115 URL: https://issues.apache.org/jira/browse/JCR-4115 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller A collision for SHA-1 has been published. We still use SHA-1 for the FileDataStore, and I believe the S3 DataStore right now. Given there is a collision, we should switch to a stronger algorithm, for example SHA-256, for new binaries. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (JCR-4042) Adding Escape Character in GQL
[
https://issues.apache.org/jira/browse/JCR-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-4042:
Description:
Currently GQL does not have a escape character. Adding the escape character
will help in special character cases for example where a search term contains
both colon ({{:}}) and quote ({{"}}) character.
for example search string is {{foo:bar}}, if term is put in quote {{"foo:bar"}}
and this whole term is considered as a single search value.
But in case user need to search {{foo"abc:bar}} then putting this term in
quotes won't work. But if GQL will have a escape character, then user can
search this term using escape character.
was:
Currently GQL does not have a escape character. Adding the escape character
will help in special character cases for example where a search term contains
both colon(:) and quote(") character.
for example search string is foo:bar, if term is put in quote "foo:bar" and
this whole term is considered as a single search value.
But in case user need to search foo"abc:bar then putting this term in quotes
won't work. But if GQL will have a escape character, then user can search this
term using escape character.
> Adding Escape Character in GQL
> --
>
> Key: JCR-4042
> URL: https://issues.apache.org/jira/browse/JCR-4042
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-commons
>Reporter: Ankit Agarwal
>Assignee: Vikas Saurabh
> Attachments: JCR-4042.take1.patch
>
>
> Currently GQL does not have a escape character. Adding the escape character
> will help in special character cases for example where a search term contains
> both colon ({{:}}) and quote ({{"}}) character.
> for example search string is {{foo:bar}}, if term is put in quote
> {{"foo:bar"}} and this whole term is considered as a single search value.
> But in case user need to search {{foo"abc:bar}} then putting this term in
> quotes won't work. But if GQL will have a escape character, then user can
> search this term using escape character.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-3870) Export SessionImpl#getItemOrNull in JackrabbitSession
[ https://issues.apache.org/jira/browse/JCR-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660076#comment-14660076 ] Thomas Mueller commented on JCR-3870: - +1 Not only makes the code faster, but also reduces code size at the consumer side. Export SessionImpl#getItemOrNull in JackrabbitSession - Key: JCR-3870 URL: https://issues.apache.org/jira/browse/JCR-3870 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-api Affects Versions: 2.10 Reporter: Joel Richard Priority: Critical Labels: performance Attachments: 0001-JCR-3870-Export-SessionImpl-getItemOrNull-in-Jackrab.patch getItemOrNull should be exported in JackrabbitSession. This would allow to combine itemExists and getItem in Sling which would reduce the rendering time by 8%. See the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3226) stateCreated deadlock
[ https://issues.apache.org/jira/browse/JCR-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644006#comment-14644006 ] Thomas Mueller commented on JCR-3226: - http://svn.apache.org/r1693011 (trunk) stateCreated deadlock - Key: JCR-3226 URL: https://issues.apache.org/jira/browse/JCR-3226 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.2, 2.4 Reporter: Jukka Zitting Assignee: Thomas Mueller Labels: deadlock Attachments: JCR-3226-test-2.patch, JCR-3226-test.patch In JCR-2650 a potential deadlock in SessionItemStateManager.stateModified() got fixed by postponing the work to the save() call. Unfortunately this still leaves the stateCreated() method vulnerable to a similar (though much less likely) deadlock scenario (observed in Jackrabbit 2.2.x): Thread A: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:118) - waiting to lock 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:152) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:791) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:398) at org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:231) at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:309) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:777) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1488) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:289) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) Thread B: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:119) - waiting to lock 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:869) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.ItemSaveOperation.persistTransientItems(ItemSaveOperation.java:836) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:243) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) at org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:42) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758) IIUC this can only occur when two sessions are concurrently importing a node with the same UUID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3226) stateCreated deadlock
[ https://issues.apache.org/jira/browse/JCR-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635015#comment-14635015 ] Thomas Mueller commented on JCR-3226: - [~dpfister], [~stefan@jira], [~tripod], could you please review the patch above? stateCreated deadlock - Key: JCR-3226 URL: https://issues.apache.org/jira/browse/JCR-3226 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.2, 2.4 Reporter: Jukka Zitting Assignee: Thomas Mueller Labels: deadlock Attachments: JCR-3226-test-2.patch, JCR-3226-test.patch In JCR-2650 a potential deadlock in SessionItemStateManager.stateModified() got fixed by postponing the work to the save() call. Unfortunately this still leaves the stateCreated() method vulnerable to a similar (though much less likely) deadlock scenario (observed in Jackrabbit 2.2.x): Thread A: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:118) - waiting to lock 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:152) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:791) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:398) at org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:231) at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:309) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:777) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1488) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:289) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) Thread B: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:119) - waiting to lock 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:869) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.ItemSaveOperation.persistTransientItems(ItemSaveOperation.java:836) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:243) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) at org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:42) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758) IIUC this can only occur when two sessions are concurrently importing a node with the same UUID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3226) stateCreated deadlock
[
https://issues.apache.org/jira/browse/JCR-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634838#comment-14634838
]
Thomas Mueller commented on JCR-3226:
-
Potential patch to fix the problem. This requires a code review.
{noformat}
--- src/main/java/org/apache/jackrabbit/core/state/SessionItemStateManager.java
(revision 1691398)
+++ src/main/java/org/apache/jackrabbit/core/state/SessionItemStateManager.java
(working copy)
@@ -803,7 +803,19 @@
visibleState = transientState;
}
}
-dispatcher.notifyStateCreated(visibleState);
+boolean notifyTransientSpace;
+if (visibleState instanceof NodeState) {
+// No need to push node created to transient space:
+// either the transient already knows about this state, or it
doesn't.
+// If we notify in this case, this can lead to a deadlock,
+// see JCR-3226.
+notifyTransientSpace = false;
+} else {
+notifyTransientSpace = true;
+}
+if (notifyTransientSpace) {
+dispatcher.notifyStateCreated(visibleState);
+}
}
/**
{noformat}
stateCreated deadlock
-
Key: JCR-3226
URL: https://issues.apache.org/jira/browse/JCR-3226
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.2, 2.4
Reporter: Jukka Zitting
Assignee: Thomas Mueller
Labels: deadlock
Attachments: JCR-3226-test-2.patch, JCR-3226-test.patch
In JCR-2650 a potential deadlock in SessionItemStateManager.stateModified()
got fixed by postponing the work to the save() call.
Unfortunately this still leaves the stateCreated() method vulnerable to a
similar (though much less likely) deadlock scenario (observed in Jackrabbit
2.2.x):
Thread A:
at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:118)
- waiting to lock 0x7ffec8ddfa18 (a
org.apache.jackrabbit.core.state.NodeState)
- locked 0x7ffec8ddf9d8 (a
org.apache.jackrabbit.core.state.NodeState)
at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:152)
- locked 0x7ffec8ddf9d8 (a
org.apache.jackrabbit.core.state.NodeState)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:791)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:398)
at
org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:231)
at
org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:309)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:777)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1488)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351)
at
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:289)
at
org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329)
Thread B:
at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:119)
- waiting to lock 0x7ffec8ddf9d8 (a
org.apache.jackrabbit.core.state.NodeState)
- locked 0x7ffec8ddfa18 (a
org.apache.jackrabbit.core.state.NodeState)
at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:869)
- locked 0x7ffec8ddfa18 (a
org.apache.jackrabbit.core.state.NodeState)
at
org.apache.jackrabbit.core.ItemSaveOperation.persistTransientItems(ItemSaveOperation.java:836)
at
org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:243)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at
[jira] [Updated] (JCR-3226) stateCreated deadlock
[ https://issues.apache.org/jira/browse/JCR-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-3226: Attachment: JCR-3226-test-2.patch JCR-3226-test-2.patch - improved test case, with possible solution. Unfortunately, can't use this as a unit test, as the problem is not reproducible without adding random sleep in the NodeState class. This is really just to reproduce the problem with a manually run test. stateCreated deadlock - Key: JCR-3226 URL: https://issues.apache.org/jira/browse/JCR-3226 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.2, 2.4 Reporter: Jukka Zitting Labels: deadlock Attachments: JCR-3226-test-2.patch, JCR-3226-test.patch In JCR-2650 a potential deadlock in SessionItemStateManager.stateModified() got fixed by postponing the work to the save() call. Unfortunately this still leaves the stateCreated() method vulnerable to a similar (though much less likely) deadlock scenario (observed in Jackrabbit 2.2.x): Thread A: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:118) - waiting to lock 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:152) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:791) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:398) at org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:231) at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:309) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:777) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1488) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:289) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) Thread B: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:119) - waiting to lock 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:869) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.ItemSaveOperation.persistTransientItems(ItemSaveOperation.java:836) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:243) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) at org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:42) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758) IIUC this can only occur when two sessions are concurrently importing a node with the same UUID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (JCR-3226) stateCreated deadlock
[ https://issues.apache.org/jira/browse/JCR-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned JCR-3226: --- Assignee: Thomas Mueller stateCreated deadlock - Key: JCR-3226 URL: https://issues.apache.org/jira/browse/JCR-3226 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.2, 2.4 Reporter: Jukka Zitting Assignee: Thomas Mueller Labels: deadlock Attachments: JCR-3226-test-2.patch, JCR-3226-test.patch In JCR-2650 a potential deadlock in SessionItemStateManager.stateModified() got fixed by postponing the work to the save() call. Unfortunately this still leaves the stateCreated() method vulnerable to a similar (though much less likely) deadlock scenario (observed in Jackrabbit 2.2.x): Thread A: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:118) - waiting to lock 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:152) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:791) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:398) at org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:231) at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:309) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:777) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1488) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:289) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) Thread B: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:119) - waiting to lock 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:869) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.ItemSaveOperation.persistTransientItems(ItemSaveOperation.java:836) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:243) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) at org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:42) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758) IIUC this can only occur when two sessions are concurrently importing a node with the same UUID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3226) stateCreated deadlock
[ https://issues.apache.org/jira/browse/JCR-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634831#comment-14634831 ] Thomas Mueller commented on JCR-3226: - Please note the repository.xml file in the patch needs to be copied to ./target/repository before running the test. This is needed to disable the cluster config (I couldn't reproduce the problem with the cluster enabled). stateCreated deadlock - Key: JCR-3226 URL: https://issues.apache.org/jira/browse/JCR-3226 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.2, 2.4 Reporter: Jukka Zitting Assignee: Thomas Mueller Labels: deadlock Attachments: JCR-3226-test-2.patch, JCR-3226-test.patch In JCR-2650 a potential deadlock in SessionItemStateManager.stateModified() got fixed by postponing the work to the save() call. Unfortunately this still leaves the stateCreated() method vulnerable to a similar (though much less likely) deadlock scenario (observed in Jackrabbit 2.2.x): Thread A: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:118) - waiting to lock 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:152) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:791) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:398) at org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:231) at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:309) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:777) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1488) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:289) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) Thread B: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:119) - waiting to lock 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:869) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.ItemSaveOperation.persistTransientItems(ItemSaveOperation.java:836) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:243) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) at org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:42) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758) IIUC this can only occur when two sessions are concurrently importing a node with the same UUID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3226) stateCreated deadlock
[
https://issues.apache.org/jira/browse/JCR-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14628128#comment-14628128
]
Thomas Mueller commented on JCR-3226:
-
I have a much simpler test case now. 3 threads are needed (even thought one
thread doesn't do much - it is blocked when trying to save the created node),
and node type nt:unstructured (can not reproduce with nt:base). Each thread
does this just once, concurrently:
{noformat}
if (node.hasNode(test)) {
Node t = node.getNode(test);
t.setProperty(x, 1);
s.save();
} else {
// can not reproduce with nt:base
// node.addNode(test, nt:base);
node.addNode(test, nt:unstructured);
s.save();
}
{noformat}
stateCreated deadlock
-
Key: JCR-3226
URL: https://issues.apache.org/jira/browse/JCR-3226
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.2, 2.4
Reporter: Jukka Zitting
Assignee: Jukka Zitting
Labels: deadlock
Attachments: JCR-3226-test.patch
In JCR-2650 a potential deadlock in SessionItemStateManager.stateModified()
got fixed by postponing the work to the save() call.
Unfortunately this still leaves the stateCreated() method vulnerable to a
similar (though much less likely) deadlock scenario (observed in Jackrabbit
2.2.x):
Thread A:
at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:118)
- waiting to lock 0x7ffec8ddfa18 (a
org.apache.jackrabbit.core.state.NodeState)
- locked 0x7ffec8ddf9d8 (a
org.apache.jackrabbit.core.state.NodeState)
at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:152)
- locked 0x7ffec8ddf9d8 (a
org.apache.jackrabbit.core.state.NodeState)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:791)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:398)
at
org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:231)
at
org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:309)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:777)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1488)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351)
at
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:289)
at
org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329)
Thread B:
at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:119)
- waiting to lock 0x7ffec8ddf9d8 (a
org.apache.jackrabbit.core.state.NodeState)
- locked 0x7ffec8ddfa18 (a
org.apache.jackrabbit.core.state.NodeState)
at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:869)
- locked 0x7ffec8ddfa18 (a
org.apache.jackrabbit.core.state.NodeState)
at
org.apache.jackrabbit.core.ItemSaveOperation.persistTransientItems(ItemSaveOperation.java:836)
at
org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:243)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329)
at
org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:42)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758)
IIUC this can only occur when two
[jira] [Commented] (JCR-3226) stateCreated deadlock
[
https://issues.apache.org/jira/browse/JCR-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14622347#comment-14622347
]
Thomas Mueller commented on JCR-3226:
-
So the output of the test is for example:
i: 0
i: 1
...
i: 40
i: 41
and then it stops there and doesn't continue. If it doesn't continue for a few
seconds, it was always a deadlock, and I think always the same type of
deadlock. jstack -l pid, or pausing in Eclipse will show that.
Some observation below. I don't currently understand the algorithm that is
used, how this is supposed to work, so I can't say if some state is a
localState (or transient) while it should not longer be one, or before it
should be one, or if there is a problem with the overall algorithm.
{noformat}
NodeState #241:
isTransient = false
overlayedState = #247
status = 1
propertyNames = primaryType
NodeState #242:
isTransient = true
listener = SessionItemStateManager #260
overlayedState = #241
status = 2
propertyNames = primaryType, x
Java stack information for the threads listed above:
===
Thread-179:
* the sessions SessionItemStateManager is #260
* locked the transient.overlayedState, which is called localState here,
and waits to lock the transient
at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:153)
- waiting to lock 7f42b1b10 (a
org.apache.jackrabbit.core.state.NodeState) #242
- locked 7f42b (a org.apache.jackrabbit.core.state.NodeState) #241
at
org.apache.jackrabbit.core.state.SessionItemStateManager.makePersistent(SessionItemStateManager.java:984)
- locked 7f42b (a org.apache.jackrabbit.core.state.NodeState) #241
at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:867)
at
org.apache.jackrabbit.core.ItemSaveOperation.persistTransientItems(ItemSaveOperation.java:849)
at
org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:243)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329)
at
org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:65)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:812)
at
org.apache.jackrabbit.core.deadlock.RandomChange.randomOp(RandomChange.java:96)
at
org.apache.jackrabbit.core.deadlock.RandomChange$1.run(RandomChange.java:58)
Thread-180:
* the sessions SessionItemStateManager is #283
* locked the transient of the other session, and waits to lock the
transient.overlayedState
at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:153)
- waiting to lock 7f42b (a
org.apache.jackrabbit.core.state.NodeState) #241
- locked 7f42b1b10 (a org.apache.jackrabbit.core.state.NodeState) #242
at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:152)
- locked 7f42b1b10 (a org.apache.jackrabbit.core.state.NodeState) #242
at
org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:788)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:487)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:407)
at
org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:233)
at
org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:323)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:831)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1541)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:400)
at
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:375)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:275)
at
org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258)
at
[jira] [Updated] (JCR-3226) stateCreated deadlock
[ https://issues.apache.org/jira/browse/JCR-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-3226: Attachment: JCR-3226-test.patch JCR-3226-test.patch: test case to reproduce the problem. The repository.xml needs to be moved to target/repository; here clustering is disabled. There is a sleep added before the second synchronized block, to increase the chance that a deadlock occurs. Sometimes the deadlock occurs after about 5-20 iterations, sometimes I had to restart the test. Not sure why, maybe it has to do with a JVM optimization (lock coarsening / lock elision / biased locking). Or maybe it was just bad luck. stateCreated deadlock - Key: JCR-3226 URL: https://issues.apache.org/jira/browse/JCR-3226 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.2, 2.4 Reporter: Jukka Zitting Assignee: Jukka Zitting Labels: deadlock Attachments: JCR-3226-test.patch In JCR-2650 a potential deadlock in SessionItemStateManager.stateModified() got fixed by postponing the work to the save() call. Unfortunately this still leaves the stateCreated() method vulnerable to a similar (though much less likely) deadlock scenario (observed in Jackrabbit 2.2.x): Thread A: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:118) - waiting to lock 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:152) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:791) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:398) at org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:231) at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:309) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:777) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1488) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:289) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) Thread B: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:119) - waiting to lock 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:869) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.ItemSaveOperation.persistTransientItems(ItemSaveOperation.java:836) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:243) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) at org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:42) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758) IIUC this can only occur when two sessions are concurrently importing a node with the same UUID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3226) stateCreated deadlock
[ https://issues.apache.org/jira/browse/JCR-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14622383#comment-14622383 ] Thomas Mueller commented on JCR-3226: - I'm not an expert in this area, maybe [~stefan@jira], [~dpfister], or [~tripod] can help here? stateCreated deadlock - Key: JCR-3226 URL: https://issues.apache.org/jira/browse/JCR-3226 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.2, 2.4 Reporter: Jukka Zitting Assignee: Jukka Zitting Labels: deadlock Attachments: JCR-3226-test.patch In JCR-2650 a potential deadlock in SessionItemStateManager.stateModified() got fixed by postponing the work to the save() call. Unfortunately this still leaves the stateCreated() method vulnerable to a similar (though much less likely) deadlock scenario (observed in Jackrabbit 2.2.x): Thread A: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:118) - waiting to lock 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:152) - locked 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:791) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:94) at org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:398) at org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:231) at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:309) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:777) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1488) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:289) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) Thread B: at org.apache.jackrabbit.core.state.NodeState.copy(NodeState.java:119) - waiting to lock 0x7ffec8ddf9d8 (a org.apache.jackrabbit.core.state.NodeState) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.NodeImpl.makePersistent(NodeImpl.java:869) - locked 0x7ffec8ddfa18 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.ItemSaveOperation.persistTransientItems(ItemSaveOperation.java:836) at org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:243) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329) at org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:42) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:355) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:758) IIUC this can only occur when two sessions are concurrently importing a node with the same UUID. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3858) NodeIterator.getSize(): compatibility with Jackrabbit 2.5
[ https://issues.apache.org/jira/browse/JCR-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14364714#comment-14364714 ] Thomas Mueller commented on JCR-3858: - I think by default it should be as secure as possible. And with the patch, this is the case. We should provide backward compatibility, but the user would have to explicitly enable this, and it needs to be clear that enabling it is potentially a (very small) security problem. NodeIterator.getSize(): compatibility with Jackrabbit 2.5 - Key: JCR-3858 URL: https://issues.apache.org/jira/browse/JCR-3858 Project: Jackrabbit Content Repository Issue Type: New Feature Affects Versions: 2.6.2, 2.7 Reporter: Thomas Mueller Assignee: Thomas Mueller In Jackrabbit 2.5 and older, the query result set (NodeIterator.getSize()) was an estimation that sometimes included nodes that are not visible for the current user. This is a possible security problem. The behavior was changed (and the security problem fixed) in JCR-3402. However, this is an incompatibility with Jackrabbit 2.5. I suggest to make this configurable in workspace.xml / repository.xml (or a system property, if that turns out to be too complicated). The default is the current (secure) behavior, with the option to use the old variant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3858) NodeIterator.getSize(): compatibility with Jackrabbit 2.5
[
https://issues.apache.org/jira/browse/JCR-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365263#comment-14365263
]
Thomas Mueller commented on JCR-3858:
-
To enable, the property sizeEstimate needs to be set to true in all
SearchIndex configurations, in all repository.xml and workspace.xml
files. Example (... is a placeholder for existing settings).
{noformat}
SearchIndex class=com.day.crx.query.lucene.LuceneHandler
param name=sizeEstimate value=true/
/SearchIndex
{noformat}
In addition to the patch above, I added an info level log message Size
estimation is enabled. This is to check that the patch is installed and the
feature is really enabled.
NodeIterator.getSize(): compatibility with Jackrabbit 2.5
-
Key: JCR-3858
URL: https://issues.apache.org/jira/browse/JCR-3858
Project: Jackrabbit Content Repository
Issue Type: New Feature
Affects Versions: 2.6.2, 2.7
Reporter: Thomas Mueller
Assignee: Thomas Mueller
In Jackrabbit 2.5 and older, the query result set (NodeIterator.getSize())
was an estimation that sometimes included nodes that are not visible for the
current user.
This is a possible security problem. The behavior was changed (and the
security problem fixed) in JCR-3402. However, this is an incompatibility with
Jackrabbit 2.5.
I suggest to make this configurable in workspace.xml / repository.xml (or a
system property, if that turns out to be too complicated). The default is the
current (secure) behavior, with the option to use the old variant.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCR-3858) NodeIterator.getSize(): compatibility with Jackrabbit 2.5
[ https://issues.apache.org/jira/browse/JCR-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-3858. - Resolution: Fixed Revision 1667317 (trunk) Revision 1667318 (2.6 branch) NodeIterator.getSize(): compatibility with Jackrabbit 2.5 - Key: JCR-3858 URL: https://issues.apache.org/jira/browse/JCR-3858 Project: Jackrabbit Content Repository Issue Type: New Feature Affects Versions: 2.6.2, 2.7 Reporter: Thomas Mueller Assignee: Thomas Mueller In Jackrabbit 2.5 and older, the query result set (NodeIterator.getSize()) was an estimation that sometimes included nodes that are not visible for the current user. This is a possible security problem. The behavior was changed (and the security problem fixed) in JCR-3402. However, this is an incompatibility with Jackrabbit 2.5. I suggest to make this configurable in workspace.xml / repository.xml (or a system property, if that turns out to be too complicated). The default is the current (secure) behavior, with the option to use the old variant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCR-3858) NodeIterator.getSize(): compatibility with Jackrabbit 2.5
Thomas Mueller created JCR-3858: --- Summary: NodeIterator.getSize(): compatibility with Jackrabbit 2.5 Key: JCR-3858 URL: https://issues.apache.org/jira/browse/JCR-3858 Project: Jackrabbit Content Repository Issue Type: New Feature Affects Versions: 2.7, 2.6.2 Reporter: Thomas Mueller Assignee: Thomas Mueller In Jackrabbit 2.5 and older, the query result set (NodeIterator.getSize()) was an estimation that sometimes included nodes that are not visible for the current user. This is a possible security problem. The behavior was changed (and the security problem fixed) in JCR-3402. However, this is an incompatibility with Jackrabbit 2.5. I suggest to make this configurable in workspace.xml / repository.xml (or a system property, if that turns out to be too complicated). The default is the current (secure) behavior, with the option to use the old variant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3858) NodeIterator.getSize(): compatibility with Jackrabbit 2.5
[
https://issues.apache.org/jira/browse/JCR-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14356682#comment-14356682
]
Thomas Mueller commented on JCR-3858:
-
Patch for review:
{noformat}
Index:
src/main/java/org/apache/jackrabbit/core/query/lucene/QueryResultImpl.java
===
--- src/main/java/org/apache/jackrabbit/core/query/lucene/QueryResultImpl.java
(revision 1641780)
+++ src/main/java/org/apache/jackrabbit/core/query/lucene/QueryResultImpl.java
(working copy)
@@ -39,7 +39,7 @@
* Implements the codeQueryResult/code interface.
*/
public abstract class QueryResultImpl implements JackrabbitQueryResult {
-
+
/**
* The logger instance for this class
*/
@@ -119,6 +119,8 @@
* The maximum size of this result if limit = 0
*/
private final long limit;
+
+private final boolean sizeEstimate;
/**
* Creates a new query result. The concrete sub class is responsible for
@@ -146,6 +148,7 @@
ColumnImpl[] columns, boolean documentOrder,
long offset, long limit) throws RepositoryException {
this.index = index;
+this.sizeEstimate = index.getSizeEstimate();
this.sessionContext = sessionContext;
this.queryImpl = queryImpl;
this.spellSuggestion = spellSuggestion;
@@ -258,10 +261,12 @@
log.debug(getResults({}) limit={}, size, limit);
}
-// quick check
-// if numResults is set, all relevant results have been fetched
-if (numResults != -1) {
-return;
+if (!sizeEstimate) {
+// quick check
+// if numResults is set, all relevant results have been fetched
+if (numResults != -1) {
+return;
+}
}
long maxResultSize = size;
@@ -291,7 +296,11 @@
ListScoreNode[] offsetNodes = new ArrayListScoreNode[]();
if (resultNodes.isEmpty() offset 0) {
// collect result offset into dummy list
-collectScoreNodes(result, offsetNodes, offset);
+if (sizeEstimate) {
+collectScoreNodes(result, new ArrayListScoreNode[](),
offset);
+} else {
+collectScoreNodes(result, offsetNodes, offset);
+}
} else {
int start = resultNodes.size() + invalid + (int) offset;
result.skip(start);
@@ -303,24 +312,29 @@
log.debug(retrieved ScoreNodes in {} ms ({}),
System.currentTimeMillis() - time, r3 - r2);
-// update numResults if all results have been fetched
-// if resultNodes.getSize() is strictly smaller than
maxResultSize, it means that all results have been fetched
-int resultSize = resultNodes.size();
-if (resultSize maxResultSize) {
-if (resultNodes.isEmpty()) {
-// if there's no result nodes, the actual totalResults if
smaller or equals than the offset
-totalResults = offsetNodes.size();
-numResults = 0;
+if (sizeEstimate) {
+// update numResults
+numResults = result.getSize();
+} else {
+// update numResults if all results have been fetched
+// if resultNodes.getSize() is strictly smaller than
maxResultSize, it means that all results have been fetched
+int resultSize = resultNodes.size();
+if (resultSize maxResultSize) {
+if (resultNodes.isEmpty()) {
+// if there's no result nodes, the actual totalResults
if smaller or equals than the offset
+totalResults = offsetNodes.size();
+numResults = 0;
+}
+else {
+totalResults = resultSize + (int) offset;
+numResults = resultSize;
+}
}
-else {
-totalResults = resultSize + (int) offset;
-numResults = resultSize;
+else if (resultSize == limit) {
+// if there's limit results, we can't know the total
size (which may be greater), but the result size is the limit
+numResults = (int) limit;
}
}
-else if (resultSize == limit) {
-// if there's limit results, we can't know the total size
(which may be greater), but the result size is the limit
-numResults = (int) limit;
-}
} catch (IOException e) {
throw new RepositoryException(e);
} finally
[jira] [Created] (JCR-3812) Improvements to the GQL tools
Thomas Mueller created JCR-3812:
---
Summary: Improvements to the GQL tools
Key: JCR-3812
URL: https://issues.apache.org/jira/browse/JCR-3812
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-jcr-commons
Reporter: Thomas Mueller
Assignee: Thomas Mueller
The GQL tool currently only supports full-text constraints (jcr:contains). I
would like to add other constraints as well, for example jcr:like. For that I
would like to use the syntax
{noformat}
jcr:nativeXPath:jcr:like(@property, '%test%')
{noformat}
For debugging and testing, I would like to have a way to get the XPath query
instead of executing the query. Also, it would be nice to have a way to execute
an XPath query, using the filter mechanism of this tool.
To simplify testing, the session should be optional.
The tool always adds an order by constraint. I would like to make this
optional. The syntax is:
{noformat}
order:-
{noformat}
(currently, '-' is used to sort descending).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3812) Improvements to the GQL tools
[
https://issues.apache.org/jira/browse/JCR-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-3812:
Attachment: JCR-3812.patch
Proposed patch
Improvements to the GQL tools
-
Key: JCR-3812
URL: https://issues.apache.org/jira/browse/JCR-3812
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-jcr-commons
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Attachments: JCR-3812.patch
The GQL tool currently only supports full-text constraints (jcr:contains).
I would like to add other constraints as well, for example jcr:like. For
that I would like to use the syntax
{noformat}
jcr:nativeXPath:jcr:like(@property, '%test%')
{noformat}
For debugging and testing, I would like to have a way to get the XPath query
instead of executing the query. Also, it would be nice to have a way to
execute an XPath query, using the filter mechanism of this tool.
To simplify testing, the session should be optional.
The tool always adds an order by constraint. I would like to make this
optional. The syntax is:
{noformat}
order:-
{noformat}
(currently, '-' is used to sort descending).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCR-3812) Improvements to the GQL tools
[
https://issues.apache.org/jira/browse/JCR-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-3812.
-
Resolution: Fixed
Revision 1627529
Improvements to the GQL tools
-
Key: JCR-3812
URL: https://issues.apache.org/jira/browse/JCR-3812
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-jcr-commons
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Attachments: JCR-3812.patch
The GQL tool currently only supports full-text constraints (jcr:contains).
I would like to add other constraints as well, for example jcr:like. For
that I would like to use the syntax
{noformat}
jcr:nativeXPath:jcr:like(@property, '%test%')
{noformat}
For debugging and testing, I would like to have a way to get the XPath query
instead of executing the query. Also, it would be nice to have a way to
execute an XPath query, using the filter mechanism of this tool.
To simplify testing, the session should be optional.
The tool always adds an order by constraint. I would like to make this
optional. The syntax is:
{noformat}
order:-
{noformat}
(currently, '-' is used to sort descending).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JCR-3812) Improvements to the GQL tools
[
https://issues.apache.org/jira/browse/JCR-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147687#comment-14147687
]
Thomas Mueller edited comment on JCR-3812 at 9/25/14 1:03 PM:
--
Revision 1627529 (trunk)
was (Author: tmueller):
Revision 1627529
Improvements to the GQL tools
-
Key: JCR-3812
URL: https://issues.apache.org/jira/browse/JCR-3812
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-jcr-commons
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Attachments: JCR-3812.patch
The GQL tool currently only supports full-text constraints (jcr:contains).
I would like to add other constraints as well, for example jcr:like. For
that I would like to use the syntax
{noformat}
jcr:nativeXPath:jcr:like(@property, '%test%')
{noformat}
For debugging and testing, I would like to have a way to get the XPath query
instead of executing the query. Also, it would be nice to have a way to
execute an XPath query, using the filter mechanism of this tool.
To simplify testing, the session should be optional.
The tool always adds an order by constraint. I would like to make this
optional. The syntax is:
{noformat}
order:-
{noformat}
(currently, '-' is used to sort descending).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCRVLT-53) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCRVLT-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14054550#comment-14054550
]
Thomas Mueller commented on JCRVLT-53:
--
also, large childnode lists don't need to be orderable
That's what we hope. But is this simply wishful thinking? :-) Fact is, we do
have lists of 10'000 child nodes with orderable node types.
vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
---
Key: JCRVLT-53
URL: https://issues.apache.org/jira/browse/JCRVLT-53
Project: Jackrabbit FileVault
Issue Type: Improvement
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Attachments: JCR-3793.patch, ReorderTest.java
The method org.apache.jackrabbit.vault.fs.api.NodeNameList.restoreOrder
re-orders orderable child nodes by using Node.orderBefore. This is very slow
if there are many child nodes, specially with Oak (minutes for 10'000 nodes,
while only about 1 second for Jackrabbit 2.x).
[~tripod], I wonder if a possible solution is to first check whether
re-ordering is needed? For example using:
{noformat}
boolean isOrdered(ArrayListString names, Node parent)
throws RepositoryException {
NodeIterator it1 = parent.getNodes();
for (IteratorString it2 = names.iterator(); it2.hasNext();) {
if (!it1.hasNext() ||
!it1.nextNode().getName().equals(it2.next())) {
return false;
}
}
return !it1.hasNext();
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCRVLT-53) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCRVLT-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14053521#comment-14053521
]
Thomas Mueller commented on JCRVLT-53:
--
My patch still improves performance about 20-fold (for Oak) and 10-fold (for
Jackrabbit 2.x), so I think it's worth it.
Yes, in VLT, and after Jukka's improvement. Jukkas improvement is very good,
but it only addresses Oak (not Jackrabbit 2.x), and it can't possibly get to
the same performance as when not calling orderBefore at all.
I think it's also important to fix this in VLT because in the future, we expect
even flatter hierarchies. In which case trying to avoid orderBefore is even
more important (my test case is just 10'000 child nodes). I also expect other
people will try to re-use the algorithm from VLT for slightly different use
cases (using VLT code as the gold standard). So it is important that VLT uses
the most optimal solution.
vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
---
Key: JCRVLT-53
URL: https://issues.apache.org/jira/browse/JCRVLT-53
Project: Jackrabbit FileVault
Issue Type: Improvement
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Attachments: JCR-3793.patch, ReorderTest.java
The method org.apache.jackrabbit.vault.fs.api.NodeNameList.restoreOrder
re-orders orderable child nodes by using Node.orderBefore. This is very slow
if there are many child nodes, specially with Oak (minutes for 10'000 nodes,
while only about 1 second for Jackrabbit 2.x).
[~tripod], I wonder if a possible solution is to first check whether
re-ordering is needed? For example using:
{noformat}
boolean isOrdered(ArrayListString names, Node parent)
throws RepositoryException {
NodeIterator it1 = parent.getNodes();
for (IteratorString it2 = names.iterator(); it2.hasNext();) {
if (!it1.hasNext() ||
!it1.nextNode().getName().equals(it2.next())) {
return false;
}
}
return !it1.hasNext();
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller reassigned JCR-3793:
---
Assignee: Thomas Mueller
vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
---
Key: JCR-3793
URL: https://issues.apache.org/jira/browse/JCR-3793
Project: Jackrabbit Content Repository
Issue Type: Improvement
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Attachments: JCR-3793.patch, ReorderTest.java
The method org.apache.jackrabbit.vault.fs.api.NodeNameList.restoreOrder
re-orders orderable child nodes by using Node.orderBefore. This is very slow
if there are many child nodes, specially with Oak (minutes for 10'000 nodes,
while only about 1 second for Jackrabbit 2.x).
[~tripod], I wonder if a possible solution is to first check whether
re-ordering is needed? For example using:
{noformat}
boolean isOrdered(ArrayListString names, Node parent)
throws RepositoryException {
NodeIterator it1 = parent.getNodes();
for (IteratorString it2 = names.iterator(); it2.hasNext();) {
if (!it1.hasNext() ||
!it1.nextNode().getName().equals(it2.next())) {
return false;
}
}
return !it1.hasNext();
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
Thomas Mueller created JCR-3793:
---
Summary: vlt: with many child nodes, NodeNameList.restoreOrder is
very slow with Oak
Key: JCR-3793
URL: https://issues.apache.org/jira/browse/JCR-3793
Project: Jackrabbit Content Repository
Issue Type: Improvement
Reporter: Thomas Mueller
The method org.apache.jackrabbit.vault.fs.api.NodeNameList.restoreOrder
re-orders orderable child nodes by using Node.orderBefore. This is very slow if
there are many child nodes, specially with Oak (minutes for 10'000 nodes, while
only about 1 second for Jackrabbit 2.x).
[~tripod], I wonder if a possible solution is to first check whether
re-ordering is needed? For example using:
{noformat}
boolean isOrdered(ArrayListString names, Node parent)
throws RepositoryException {
NodeIterator it1 = parent.getNodes();
for (IteratorString it2 = names.iterator(); it2.hasNext();) {
if (!it1.hasNext() || !it1.nextNode().getName().equals(it2.next()))
{
return false;
}
}
return !it1.hasNext();
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048847#comment-14048847
]
Thomas Mueller commented on JCR-3793:
-
[~jukkaz], yes I have a potential patch for Oak, which is: only update the
ordered list in case the order is actually different. And in fact the order
is not different, however Oak is still very slow.
With the vlt patch, performance improved even for Jackrabbit 2.x (from about 1
second to 0.1 seconds), as well as for Oak (to around 0.1 seconds).
I don't have a _good_ benchmark, but I will upload the benchmark I have.
vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
---
Key: JCR-3793
URL: https://issues.apache.org/jira/browse/JCR-3793
Project: Jackrabbit Content Repository
Issue Type: Improvement
Reporter: Thomas Mueller
Attachments: JCR-3793.patch
The method org.apache.jackrabbit.vault.fs.api.NodeNameList.restoreOrder
re-orders orderable child nodes by using Node.orderBefore. This is very slow
if there are many child nodes, specially with Oak (minutes for 10'000 nodes,
while only about 1 second for Jackrabbit 2.x).
[~tripod], I wonder if a possible solution is to first check whether
re-ordering is needed? For example using:
{noformat}
boolean isOrdered(ArrayListString names, Node parent)
throws RepositoryException {
NodeIterator it1 = parent.getNodes();
for (IteratorString it2 = names.iterator(); it2.hasNext();) {
if (!it1.hasNext() ||
!it1.nextNode().getName().equals(it2.next())) {
return false;
}
}
return !it1.hasNext();
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-3793:
Attachment: ReorderTest.java
Test that shows re-ordering is slow in Oak.
vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
---
Key: JCR-3793
URL: https://issues.apache.org/jira/browse/JCR-3793
Project: Jackrabbit Content Repository
Issue Type: Improvement
Reporter: Thomas Mueller
Attachments: JCR-3793.patch, ReorderTest.java
The method org.apache.jackrabbit.vault.fs.api.NodeNameList.restoreOrder
re-orders orderable child nodes by using Node.orderBefore. This is very slow
if there are many child nodes, specially with Oak (minutes for 10'000 nodes,
while only about 1 second for Jackrabbit 2.x).
[~tripod], I wonder if a possible solution is to first check whether
re-ordering is needed? For example using:
{noformat}
boolean isOrdered(ArrayListString names, Node parent)
throws RepositoryException {
NodeIterator it1 = parent.getNodes();
for (IteratorString it2 = names.iterator(); it2.hasNext();) {
if (!it1.hasNext() ||
!it1.nextNode().getName().equals(it2.next())) {
return false;
}
}
return !it1.hasNext();
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048852#comment-14048852
]
Thomas Mueller commented on JCR-3793:
-
Potential patch for Oak (doesn't help much unfortunately):
{noformat}
### Eclipse Workspace Patch 1.0
#P oak-core
Index: src/main/java/org/apache/jackrabbit/oak/core/MutableTree.java
===
--- src/main/java/org/apache/jackrabbit/oak/core/MutableTree.java
(revision 1604905)
+++ src/main/java/org/apache/jackrabbit/oak/core/MutableTree.java
(working copy)
@@ -249,6 +249,23 @@
if (name == null) {
names.add(this.name);
}
+PropertyState old = parent.nodeBuilder.getProperty(OAK_CHILD_ORDER);
+boolean isChanged;
+if (old.count() != names.size()) {
+isChanged = true;
+} else {
+isChanged = false;
+for (int i = 0; i old.count(); i++) {
+String oldName = old.getValue(Type.STRING, i);
+if (!oldName.equals(names.get(i))) {
+isChanged = true;
+break;
+}
+}
+}
+if (!isChanged) {
+return false;
+}
parent.nodeBuilder.setProperty(OAK_CHILD_ORDER, names, NAMES);
root.updated();
return true;
{noformat}
vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
---
Key: JCR-3793
URL: https://issues.apache.org/jira/browse/JCR-3793
Project: Jackrabbit Content Repository
Issue Type: Improvement
Reporter: Thomas Mueller
Attachments: JCR-3793.patch, ReorderTest.java
The method org.apache.jackrabbit.vault.fs.api.NodeNameList.restoreOrder
re-orders orderable child nodes by using Node.orderBefore. This is very slow
if there are many child nodes, specially with Oak (minutes for 10'000 nodes,
while only about 1 second for Jackrabbit 2.x).
[~tripod], I wonder if a possible solution is to first check whether
re-ordering is needed? For example using:
{noformat}
boolean isOrdered(ArrayListString names, Node parent)
throws RepositoryException {
NodeIterator it1 = parent.getNodes();
for (IteratorString it2 = names.iterator(); it2.hasNext();) {
if (!it1.hasNext() ||
!it1.nextNode().getName().equals(it2.next())) {
return false;
}
}
return !it1.hasNext();
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (JCR-3769) Support Full-Text Aggregation with Similarity Queries
Thomas Mueller created JCR-3769: --- Summary: Support Full-Text Aggregation with Similarity Queries Key: JCR-3769 URL: https://issues.apache.org/jira/browse/JCR-3769 Project: Jackrabbit Content Repository Issue Type: Improvement Components: query Reporter: Thomas Mueller Fix For: 1.1 The full-text similarity condition (rep:similar for XPath, similar for SQL-2) does not currently support full-text aggregation. For improved usability and Jackrabbit 2.x compatibility, this should be supported. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (JCR-3760) FileDataStore: reduce synchronization
[
https://issues.apache.org/jira/browse/JCR-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-3760.
-
Resolution: Fixed
Fixed in revision 1582686
FileDataStore: reduce synchronization
-
Key: JCR-3760
URL: https://issues.apache.org/jira/browse/JCR-3760
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-data
Reporter: Thomas Mueller
Assignee: Thomas Mueller
The FileDataStore uses the following synchronization:
synchronized (this) {
if (!file.exists()) {
return null;
}
...
File.exists calls are very slow, it would be better if this check could be
done outside of the synchronized block. I don't think this would cause any
issues.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (JCR-3760) FileDataStore: reduce synchronization
[
https://issues.apache.org/jira/browse/JCR-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller reassigned JCR-3760:
---
Assignee: Thomas Mueller
FileDataStore: reduce synchronization
-
Key: JCR-3760
URL: https://issues.apache.org/jira/browse/JCR-3760
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-data
Reporter: Thomas Mueller
Assignee: Thomas Mueller
The FileDataStore uses the following synchronization:
synchronized (this) {
if (!file.exists()) {
return null;
}
...
File.exists calls are very slow, it would be better if this check could be
done outside of the synchronized block. I don't think this would cause any
issues.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (JCR-3760) FileDataStore: reduce synchronization
Thomas Mueller created JCR-3760:
---
Summary: FileDataStore: reduce synchronization
Key: JCR-3760
URL: https://issues.apache.org/jira/browse/JCR-3760
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-data
Reporter: Thomas Mueller
The FileDataStore uses the following synchronization:
{noformat}
synchronized (this) {
if (!file.exists()) {
return null;
}
...
{noformat}
File.exists calls are very slow, it would be better if this check could be done
outside of the synchronized block. I don't think this would cause any issues.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (JCR-3760) FileDataStore: reduce synchronization
[
https://issues.apache.org/jira/browse/JCR-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-3760:
Description:
The FileDataStore uses the following synchronization:
synchronized (this) {
if (!file.exists()) {
return null;
}
...
File.exists calls are very slow, it would be better if this check could be done
outside of the synchronized block. I don't think this would cause any issues.
was:
The FileDataStore uses the following synchronization:
{noformat}
synchronized (this) {
if (!file.exists()) {
return null;
}
...
{noformat}
File.exists calls are very slow, it would be better if this check could be done
outside of the synchronized block. I don't think this would cause any issues.
FileDataStore: reduce synchronization
-
Key: JCR-3760
URL: https://issues.apache.org/jira/browse/JCR-3760
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-data
Reporter: Thomas Mueller
The FileDataStore uses the following synchronization:
synchronized (this) {
if (!file.exists()) {
return null;
}
...
File.exists calls are very slow, it would be better if this check could be
done outside of the synchronized block. I don't think this would cause any
issues.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCR-3743) failing test if aws extensions
[
https://issues.apache.org/jira/browse/JCR-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13941529#comment-13941529
]
Thomas Mueller commented on JCR-3743:
-
whenever you expect currentTimeMillis to change, I'd simple busy-wait exactly
for that
To avoid a 100% CPU loop, I would do:
{noformat}
while (System.currentTimeMillis() = last) {
Thread.sleep(1);
}
{noformat}
failing test if aws extensions
--
Key: JCR-3743
URL: https://issues.apache.org/jira/browse/JCR-3743
Project: Jackrabbit Content Repository
Issue Type: Bug
Reporter: Julian Reschke
Assignee: Dominique Pfister
Priority: Minor
On Win7/64bit/corei7:
Failed tests:
testDeleteAllOlderThan(org.apache.jackrabbit.aws.ext.ds.TestInMemDs)
testDeleteAllOlderThan(org.apache.jackrabbit.aws.ext.ds.TestInMemDsCacheOff)
Likely because of incorrect assumptions about System.currentTimeMillis()
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCR-3731) Multi-threaded migration of binary files from FileSystem to S3 datastore
[ https://issues.apache.org/jira/browse/JCR-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930029#comment-13930029 ] Thomas Mueller commented on JCR-3731: - [~dpfister] will review the patch. Multi-threaded migration of binary files from FileSystem to S3 datastore - Key: JCR-3731 URL: https://issues.apache.org/jira/browse/JCR-3731 Project: Jackrabbit Content Repository Issue Type: Sub-task Components: jackrabbit-core Affects Versions: 2.7.4 Reporter: Shashank Gupta Fix For: 2.7.5 Attachments: JCR-3651.patch As per today, when we switch repository from FileDataStore to S3DataStore all binary files are migrated from local file system to S3Datastore. As per today this process is single threaded and takes lot of time. For e.g. for 1G intial content, it takes around 5 min to migrated from ec2 instance to S3. It can be made faster by migrating content in multi-threaded environment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCR-3732) Externalize S3 endpoints
[ https://issues.apache.org/jira/browse/JCR-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930027#comment-13930027 ] Thomas Mueller commented on JCR-3732: - [~dpfister] will review the patch. Externalize S3 endpoints Key: JCR-3732 URL: https://issues.apache.org/jira/browse/JCR-3732 Project: Jackrabbit Content Repository Issue Type: Sub-task Components: jackrabbit-core Affects Versions: 2.7.4 Reporter: Shashank Gupta Fix For: 2.7.5 Attachments: JCR-3732.patch Currently S3 connector uses S3 region ( already externalized via aws.properties) to configure S3 endpoint as per the mapping [1]. There are cases where single S3 region may contains multiple endpoints. for e. US Standard region has two endpoints: s3.amazonaws.com (Northern Virginia or Pacific Northwest) s3-external-1.amazonaws.com (Northern Virginia only) To handle these cases, S3 connector should externalize endpoint configuration (as optional) and has higher precedence over endpoint derived via S3 region. [1] http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCR-3735) Efficient copying of binaries in Jackrabbit DataStores
[ https://issues.apache.org/jira/browse/JCR-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911375#comment-13911375 ] Thomas Mueller commented on JCR-3735: - I wonder why you need to optimize the Jackrabbit 2.x DataStore? I think we should rather optimize Oak, and should not spend too much time trying to optimize Jackrabbit 2.x. Please note that in Oak, the BlobStores that are based on the AbstractBlobStore are not creating temporary files. They do that by splitting large binaries into chunks. Similar for the SegmentNodeStore. Efficient copying of binaries in Jackrabbit DataStores -- Key: JCR-3735 URL: https://issues.apache.org/jira/browse/JCR-3735 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Affects Versions: 2.7.4 Reporter: Amit Jain In the DataStore implementations an additional temporary file is created for every binary uploaded. This step is an additional overhead when the upload process itself creates a temporary file. So, the solution proposed is to check if the input stream passed is a FileInputStream and then use the FileChannel object associated with the input stream to copy the file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (JCR-3735) Efficient copying of binaries in Jackrabbit DataStores
[ https://issues.apache.org/jira/browse/JCR-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13910211#comment-13910211 ] Thomas Mueller commented on JCR-3735: - Is this for the FileDataStore? Is this issue about calculating the content hash from the existing file, so that one less copy is needed? But a temporary file would still be needed, right? Or do you suggest to still copy the file, but use FileChannel instead of FileInputStream? Efficient copying of binaries in Jackrabbit DataStores -- Key: JCR-3735 URL: https://issues.apache.org/jira/browse/JCR-3735 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Affects Versions: 2.7.4 Reporter: Amit Jain In the DataStore implementations an additional temporary file is created for every binary uploaded. This step is an additional overhead when the upload process itself creates a temporary file. So, the solution proposed is to check if the input stream passed is a FileInputStream and then use the FileChannel object associated with the input stream to copy the file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (JCR-3735) Efficient copying of binaries in Jackrabbit DataStores
[
https://issues.apache.org/jira/browse/JCR-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13910300#comment-13910300
]
Thomas Mueller commented on JCR-3735:
-
Hm, you mean we create a new variant of FileDataStore that doesn't do
de-duplication? OK, that's an idea.
And of course the user might decide to pass a wrapped input stream
(BufferedInputStream or similar). I don't know of a good solution for this.
One item to not forget is that the input stream might not be positioned at the
very beginning. But this can be supported. I wrote some proof of concept code,
maybe it is helpful:
{noformat}
public static void main(String... args) throws Exception {
String fileName = System.getProperty(user.home) + /temp/test.txt;
FileOutputStream out = new FileOutputStream(fileName);
out.write(Hello World.getBytes(UTF-8));
InputStream in = new FileInputStream(fileName);
// skip the first byte
in.read();
process(in);
}
static void process(InputStream in) throws Exception {
if (!(in instanceof FileInputStream)) {
// use default
}
FileInputStream fin = (FileInputStream) in;
FileChannel c = fin.getChannel();
long start = c.position();
System.out.println(start: + start);
long length = c.size() - start;
MessageDigest digest = MessageDigest.getInstance(SHA-1);
ByteBuffer buff = ByteBuffer.allocate(64 * 1024);
long pos = start;
while (true) {
long len = c.read(buff, pos);
if (len 0) {
break;
}
pos += len;
digest.update(buff.array(), 0, buff.remaining());
buff.clear();
}
byte[] sha1 = digest.digest(new byte[0]);
String outFileName = System.getProperty(user.home) +
/temp/ + new BigInteger(sha1).toString(16) + .txt;
FileChannel out = new RandomAccessFile(outFileName, rw).getChannel();
while (length 0) {
long len = c.transferTo(start, length, out);
length -= len;
}
out.close();
c.close();
}
{noformat}
Efficient copying of binaries in Jackrabbit DataStores
--
Key: JCR-3735
URL: https://issues.apache.org/jira/browse/JCR-3735
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-core
Affects Versions: 2.7.4
Reporter: Amit Jain
In the DataStore implementations an additional temporary file is created for
every binary uploaded. This step is an additional overhead when the upload
process itself creates a temporary file.
So, the solution proposed is to check if the input stream passed is a
FileInputStream and then use the FileChannel object associated with the input
stream to copy the file.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (JCR-3705) Extract data store API and implementations from jackrabbit-core
[ https://issues.apache.org/jira/browse/JCR-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13891939#comment-13891939 ] Thomas Mueller commented on JCR-3705: - OK, the patch looks good to me. I will commit it. Extract data store API and implementations from jackrabbit-core --- Key: JCR-3705 URL: https://issues.apache.org/jira/browse/JCR-3705 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Assignee: Thomas Mueller Labels: patch Attachments: JCR-3705.patch In Oak we'd like to use the Jackrabbit data stores (OAK-805). Doing so would currently require a direct dependency to jackrabbit-core, which is troublesome for various reasons. Since the DataStore interface and its implementations are mostly independent of the rest of Jackrabbit internals, it should be possible to avoid that dependency by moving the data store bits to some other component. One alternative would be to place them in jackrabbit-jcr-commons, another to create a separate new jackrabbit-data component for this purpose. WDYT? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (JCR-3705) Extract data store API and implementations from jackrabbit-core
[ https://issues.apache.org/jira/browse/JCR-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned JCR-3705: --- Assignee: Thomas Mueller Extract data store API and implementations from jackrabbit-core --- Key: JCR-3705 URL: https://issues.apache.org/jira/browse/JCR-3705 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Assignee: Thomas Mueller Labels: patch Attachments: JCR-3705.patch In Oak we'd like to use the Jackrabbit data stores (OAK-805). Doing so would currently require a direct dependency to jackrabbit-core, which is troublesome for various reasons. Since the DataStore interface and its implementations are mostly independent of the rest of Jackrabbit internals, it should be possible to avoid that dependency by moving the data store bits to some other component. One alternative would be to place them in jackrabbit-jcr-commons, another to create a separate new jackrabbit-data component for this purpose. WDYT? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (JCR-3722) Query: an index is used even where traversing is faster
Thomas Mueller created JCR-3722:
---
Summary: Query: an index is used even where traversing is faster
Key: JCR-3722
URL: https://issues.apache.org/jira/browse/JCR-3722
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: query
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Currently, for queries that can use an index, the index is always preferred
over traversing over the nodes. For joins, sometimes is much faster to
traverse, specially the exact path is known. Example:
{noformat}
/jcr:root/testroot/b[@jcr:uuid]
{noformat}
This query will use the index on jcr:uuid, and traverse over all nodes with
the property jcr:uuid, even thought in fact only one node would need to be
read when using the TraversingIndex.
The problems are: Currently, the TraversingIndex is not even asked to estimate
the cost. Also, the cost estimation of the TraversingIndex is incorrect for
such cases.
We will also need to verify and fix the cost estimation of the other indexes
(for example the PropertyIndex) conforms the QueryIndex API (getCost is
supposed to return the estimated number of entries to traverse).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (JCR-3722) Query: an index is used even where traversing is faster
[
https://issues.apache.org/jira/browse/JCR-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-3722:
Description:
Currently, for queries that can use an index, the index is always preferred
over traversing over the nodes. For joins, sometimes is much faster to
traverse, specially the exact path is known. Example:
/jcr:root/testroot/b[@jcr:uuid]
This query will use the index on jcr:uuid, and traverse over all nodes with
the property jcr:uuid, even thought in fact only one node would need to be
read when using the TraversingIndex.
The problems are: Currently, the TraversingIndex is not even asked to estimate
the cost. Also, the cost estimation of the TraversingIndex is incorrect for
such cases.
We will also need to verify and fix the cost estimation of the other indexes
(for example the PropertyIndex) conforms the QueryIndex API (getCost is
supposed to return the estimated number of entries to traverse).
was:
Currently, for queries that can use an index, the index is always preferred
over traversing over the nodes. For joins, sometimes is much faster to
traverse, specially the exact path is known. Example:
{noformat}
/jcr:root/testroot/b[@jcr:uuid]
{noformat}
This query will use the index on jcr:uuid, and traverse over all nodes with
the property jcr:uuid, even thought in fact only one node would need to be
read when using the TraversingIndex.
The problems are: Currently, the TraversingIndex is not even asked to estimate
the cost. Also, the cost estimation of the TraversingIndex is incorrect for
such cases.
We will also need to verify and fix the cost estimation of the other indexes
(for example the PropertyIndex) conforms the QueryIndex API (getCost is
supposed to return the estimated number of entries to traverse).
Query: an index is used even where traversing is faster
---
Key: JCR-3722
URL: https://issues.apache.org/jira/browse/JCR-3722
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: query
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Currently, for queries that can use an index, the index is always preferred
over traversing over the nodes. For joins, sometimes is much faster to
traverse, specially the exact path is known. Example:
/jcr:root/testroot/b[@jcr:uuid]
This query will use the index on jcr:uuid, and traverse over all nodes with
the property jcr:uuid, even thought in fact only one node would need to be
read when using the TraversingIndex.
The problems are: Currently, the TraversingIndex is not even asked to
estimate the cost. Also, the cost estimation of the TraversingIndex is
incorrect for such cases.
We will also need to verify and fix the cost estimation of the other indexes
(for example the PropertyIndex) conforms the QueryIndex API (getCost is
supposed to return the estimated number of entries to traverse).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (JCR-3705) Extract data store API and implementations from jackrabbit-core
[ https://issues.apache.org/jira/browse/JCR-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890628#comment-13890628 ] Thomas Mueller commented on JCR-3705: - Hi [~ajain], I think we are close now to apply the patch. However, I think you made some changes that are not reflected in the patch. There is a new reference to +import org.apache.jackrabbit.core.gc.GarbageCollector;, but I couldn't find this class in the patch. Could you re-create and upload the patch again please? Extract data store API and implementations from jackrabbit-core --- Key: JCR-3705 URL: https://issues.apache.org/jira/browse/JCR-3705 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Labels: patch Attachments: JCR-3705.patch In Oak we'd like to use the Jackrabbit data stores (OAK-805). Doing so would currently require a direct dependency to jackrabbit-core, which is troublesome for various reasons. Since the DataStore interface and its implementations are mostly independent of the rest of Jackrabbit internals, it should be possible to avoid that dependency by moving the data store bits to some other component. One alternative would be to place them in jackrabbit-jcr-commons, another to create a separate new jackrabbit-data component for this purpose. WDYT? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (JCR-3705) Extract data store API and implementations from jackrabbit-core
[ https://issues.apache.org/jira/browse/JCR-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886452#comment-13886452 ] Thomas Mueller commented on JCR-3705: - Is it a good idea to copy this classes to jackrabbit-data I think we move classes, we don't copy them. The problem is the dependencies Yes. So let's move the classes now, and if somebody comes up with a way to move them back to jackrabbit-core let's do that (later). we have a package split here as the following 2 packages are also in jackrabbit-core I think that's a bit problematic for OSGi, right? If yes, I would like to rename packages as follows: in oak-core: org.apache.jackrabbit.data to org.apache.jackrabbit.core.data; in oak-data: org.apache.jackrabbit.core to org.apache.jackrabbit.data.core. I have to admit that's weird, but I don't see another way. Extract data store API and implementations from jackrabbit-core --- Key: JCR-3705 URL: https://issues.apache.org/jira/browse/JCR-3705 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Labels: patch Attachments: JCR-3705.patch In Oak we'd like to use the Jackrabbit data stores (OAK-805). Doing so would currently require a direct dependency to jackrabbit-core, which is troublesome for various reasons. Since the DataStore interface and its implementations are mostly independent of the rest of Jackrabbit internals, it should be possible to avoid that dependency by moving the data store bits to some other component. One alternative would be to place them in jackrabbit-jcr-commons, another to create a separate new jackrabbit-data component for this purpose. WDYT? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (JCR-3705) Extract data store API and implementations from jackrabbit-core
[
https://issues.apache.org/jira/browse/JCR-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883996#comment-13883996
]
Thomas Mueller commented on JCR-3705:
-
Thanks a lot! The patch moves many classes from jackrabbit-core to
jackrabbit-jcr-commons, I'm not sure if that's the right way to do it.
To get an overview of the changes, here the result of svn patch (sorted; oaj
means org/apache/jackrabbit):
{code}
Added files
jackrabbit-data/pom.xml
jackrabbit-data/src/main/java/oaj/core/data/AbstractDataRecord.java
jackrabbit-data/src/main/java/oaj/core/data/AbstractDataStore.java
jackrabbit-data/src/main/java/oaj/core/data/DataIdentifier.java
jackrabbit-data/src/main/java/oaj/core/data/DataRecord.java
jackrabbit-data/src/main/java/oaj/core/data/DataStore.java
jackrabbit-data/src/main/java/oaj/core/data/DataStoreException.java
jackrabbit-data/src/main/java/oaj/core/data/DataStoreFactory.java
jackrabbit-data/src/main/java/oaj/core/data/db/DbDataRecord.java
jackrabbit-data/src/main/java/oaj/core/data/db/DbDataStore.java
jackrabbit-data/src/main/java/oaj/core/data/db/DbInputStream.java
jackrabbit-data/src/main/java/oaj/core/data/db/DerbyDataStore.java
jackrabbit-data/src/main/java/oaj/core/data/FileDataRecord.java
jackrabbit-data/src/main/java/oaj/core/data/FileDataStore.java
jackrabbit-data/src/main/java/oaj/core/data/LazyFileInputStream.java
jackrabbit-data/src/main/java/oaj/core/data/LocalCache.java
jackrabbit-data/src/main/java/oaj/core/data/MultiDataStore.java
jackrabbit-data/src/main/java/oaj/core/data/MultiDataStoreAware.java
jackrabbit-data/src/main/java/oaj/core/data/ScanEventListener.java
jackrabbit-data/src/main/java/oaj/data/cache/Backend.java
jackrabbit-data/src/main/java/oaj/data/cache/CachingDataRecord.java
jackrabbit-data/src/main/java/oaj/data/cache/CachingDataStore.java
jackrabbit-data/src/main/resources/oaj/core/data/db/azure.properties
jackrabbit-data/src/main/resources/oaj/core/data/db/db2.properties
jackrabbit-data/src/main/resources/oaj/core/data/db/derby.properties
jackrabbit-data/src/main/resources/oaj/core/data/db/h2.properties
jackrabbit-data/src/main/resources/oaj/core/data/db/ingres.properties
jackrabbit-data/src/main/resources/oaj/core/data/db/mssql.properties
jackrabbit-data/src/main/resources/oaj/core/data/db/mysql.properties
jackrabbit-data/src/main/resources/oaj/core/data/db/oracle.properties
jackrabbit-data/src/main/resources/oaj/core/data/db/postgresql.properties
jackrabbit-data/src/main/resources/oaj/core/data/db/sqlserver.properties
jackrabbit-jcr-commons/src/main/java/oaj/core/config/ConfigurationException.java
jackrabbit-jcr-commons/src/main/java/oaj/core/config/DataSourceConfig.java
jackrabbit-jcr-commons/src/main/java/oaj/core/fs/BasedFileSystem.java
jackrabbit-jcr-commons/src/main/java/oaj/core/fs/FileSystem.java
jackrabbit-jcr-commons/src/main/java/oaj/core/fs/FileSystemException.java
jackrabbit-jcr-commons/src/main/java/oaj/core/fs/FileSystemFactory.java
jackrabbit-jcr-commons/src/main/java/oaj/core/fs/FileSystemPathUtil.java
jackrabbit-jcr-commons/src/main/java/oaj/core/fs/FileSystemResource.java
jackrabbit-jcr-commons/src/main/java/oaj/core/fs/local/FileUtil.java
jackrabbit-jcr-commons/src/main/java/oaj/core/fs/local/HandleMonitor.java
jackrabbit-jcr-commons/src/main/java/oaj/core/fs/local/LocalFileSystem.java
jackrabbit-jcr-commons/src/main/java/oaj/core/fs/RandomAccessOutputStream.java
jackrabbit-jcr-commons/src/main/java/oaj/core/InternalXAResource.java
jackrabbit-jcr-commons/src/main/java/oaj/core/TransactionContext.java
jackrabbit-jcr-commons/src/main/java/oaj/core/TransactionException.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/CheckSchemaOperation.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/ConnectionFactory.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/ConnectionHelper.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/DatabaseAware.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/DataSourceWrapper.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/DbUtility.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/DerbyConnectionHelper.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/Oracle10R1ConnectionHelper.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/OracleConnectionHelper.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/PostgreSQLConnectionHelper.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/ResultSetWrapper.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/StreamWrapper.java
jackrabbit-jcr-commons/src/main/java/oaj/core/util/db/TempFileInputStream.java
Removed files
jackrabbit-aws-ext/src/main/java/oaj/aws/ext/ds/Backend.java
jackrabbit-aws-ext/src/main/java/oaj/aws/ext/ds/CachingDataRecord.java
jackrabbit-aws-ext/src/main/java/oaj/aws/ext/ds/CachingDataStore.java
[jira] [Commented] (JCR-3705) Extract data store API and implementations from jackrabbit-core
[ https://issues.apache.org/jira/browse/JCR-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13871926#comment-13871926 ] Thomas Mueller commented on JCR-3705: - [~ajain], I think there is a problem with the patch. It contains duplicated changes (for example, the class jackrabbit-data/src/main/java/org/apache/jackrabbit/data/cache/Backend.java is added multiple times). More problematic, there seem to be line break changes (jackrabbit-aws-ext/src/main/java/org/apache/jackrabbit/aws/ext/ds/S3Backend.java for example) where all lines of a class are removed but then added back. I guess the patch file was created by a tool you used, but to verify the patch it would be nice to have a small patch. Would it be possible for you to shrink the patch (remove duplications, not change line break style)? Extract data store API and implementations from jackrabbit-core --- Key: JCR-3705 URL: https://issues.apache.org/jira/browse/JCR-3705 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Labels: patch Attachments: JCR-3705.patch In Oak we'd like to use the Jackrabbit data stores (OAK-805). Doing so would currently require a direct dependency to jackrabbit-core, which is troublesome for various reasons. Since the DataStore interface and its implementations are mostly independent of the rest of Jackrabbit internals, it should be possible to avoid that dependency by moving the data store bits to some other component. One alternative would be to place them in jackrabbit-jcr-commons, another to create a separate new jackrabbit-data component for this purpose. WDYT? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (JCRVLT-18) Set default autosave threshold based on repository implementation
[ https://issues.apache.org/jira/browse/JCRVLT-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800400#comment-13800400 ] Thomas Mueller commented on JCRVLT-18: -- with jackrabbit 3.0 the transient space is more or less unlimited in size, and we can install large packages in 1 save, which improves installation atomicity. Yes. Please note it does not necessarily improve installation *performance* when using one very large transaction (autosave threshold of -1) for the MongoDB case. In fact large transactions might be slower than small ones. The reason is that MongoMK does not support large transactions (and MongoDB doesn't support transactions at all), so that large transactions require more work than multiple smaller transactions. Set default autosave threshold based on repository implementation - Key: JCRVLT-18 URL: https://issues.apache.org/jira/browse/JCRVLT-18 Project: Jackrabbit FileVault Issue Type: Improvement Reporter: Tobias Bocanegra Priority: Minor with jackrabbit 2.0 we had a limitation of the size of the transient space as it is held in memory. in order to support large packages, the AutoSave threshold is set to 1024 nodes. with jackrabbit 3.0 the transient space is more or less unlimited in size, and we can install large packages in 1 save, which improves installation atomicity. however, the bigger the transient size, the higher the chance for collisions during installation of large packages, so saving in chunks yields to a more robust installation behavior. suggestions: - autosave threshold of 0 should mean 'auto' - autosave threshold of -1 should mean 'never' - packages can provide their desired autosave threshold via properties -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (JCRVLT-18) Set default autosave threshold based on repository implementation
[ https://issues.apache.org/jira/browse/JCRVLT-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800400#comment-13800400 ] Thomas Mueller edited comment on JCRVLT-18 at 10/21/13 6:36 AM: with jackrabbit 3.0 the transient space is more or less unlimited in size, and we can install large packages in 1 save, which improves installation atomicity. Yes. Please note it does not necessarily improve installation *performance* when using one very large transaction (autosave threshold of -1) for the MongoDB case. In fact large transactions might be slower than small ones. The reason is that MongoMK does not support large transactions efficiently (and MongoDB doesn't support transactions at all), so that large transactions require more work than multiple smaller transactions. was (Author: tmueller): with jackrabbit 3.0 the transient space is more or less unlimited in size, and we can install large packages in 1 save, which improves installation atomicity. Yes. Please note it does not necessarily improve installation *performance* when using one very large transaction (autosave threshold of -1) for the MongoDB case. In fact large transactions might be slower than small ones. The reason is that MongoMK does not support large transactions (and MongoDB doesn't support transactions at all), so that large transactions require more work than multiple smaller transactions. Set default autosave threshold based on repository implementation - Key: JCRVLT-18 URL: https://issues.apache.org/jira/browse/JCRVLT-18 Project: Jackrabbit FileVault Issue Type: Improvement Reporter: Tobias Bocanegra Priority: Minor with jackrabbit 2.0 we had a limitation of the size of the transient space as it is held in memory. in order to support large packages, the AutoSave threshold is set to 1024 nodes. with jackrabbit 3.0 the transient space is more or less unlimited in size, and we can install large packages in 1 save, which improves installation atomicity. however, the bigger the transient size, the higher the chance for collisions during installation of large packages, so saving in chunks yields to a more robust installation behavior. suggestions: - autosave threshold of 0 should mean 'auto' - autosave threshold of -1 should mean 'never' - packages can provide their desired autosave threshold via properties -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JCRVLT-18) Set default autosave threshold based on repository implementation
[ https://issues.apache.org/jira/browse/JCRVLT-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800521#comment-13800521 ] Thomas Mueller commented on JCRVLT-18: -- [~fmeschbe] I understand. I would suggest to remove auto save alltogether and rather instruct users to use smaller packages. That would be best - fast and secure, even for CRX 2.x that doesn't support large transactions :-) Set default autosave threshold based on repository implementation - Key: JCRVLT-18 URL: https://issues.apache.org/jira/browse/JCRVLT-18 Project: Jackrabbit FileVault Issue Type: Improvement Reporter: Tobias Bocanegra Priority: Minor with jackrabbit 2.0 we had a limitation of the size of the transient space as it is held in memory. in order to support large packages, the AutoSave threshold is set to 1024 nodes. with jackrabbit 3.0 the transient space is more or less unlimited in size, and we can install large packages in 1 save, which improves installation atomicity. however, the bigger the transient size, the higher the chance for collisions during installation of large packages, so saving in chunks yields to a more robust installation behavior. suggestions: - autosave threshold of 0 should mean 'auto' - autosave threshold of -1 should mean 'never' - packages can provide their desired autosave threshold via properties -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (JCR-3684) BundleWriter: Unexpected error while writing NAME value.
Thomas Mueller created JCR-3684:
---
Summary: BundleWriter: Unexpected error while writing NAME value.
Key: JCR-3684
URL: https://issues.apache.org/jira/browse/JCR-3684
Project: Jackrabbit Content Repository
Issue Type: Bug
Reporter: Thomas Mueller
Assignee: Thomas Mueller
I saw the following exception in a log file:
{code}
Unexpected error while writing NAME value.
at
org.apache.jackrabbit.core.persistence.util.BundleWriter.writeState(BundleWriter.java:312)
at
org.apache.jackrabbit.core.persistence.util.BundleWriter.writeBundle(BundleWriter.java:131)
at
org.apache.jackrabbit.core.persistence.util.BundleBinding.writeBundle(BundleBinding.java:164)
{code}
Unfortunately, the class BundleWriter swallows the root cause of the exception.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (JCR-3684) BundleWriter: Unexpected error while writing NAME value.
[
https://issues.apache.org/jira/browse/JCR-3684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-3684:
Description:
I saw the following exception in a log file:
Unexpected error while writing NAME value.
at
org.apache.jackrabbit.core.persistence.util.BundleWriter.writeState(BundleWriter.java:312)
at
org.apache.jackrabbit.core.persistence.util.BundleWriter.writeBundle(BundleWriter.java:131)
at
org.apache.jackrabbit.core.persistence.util.BundleBinding.writeBundle(BundleBinding.java:164)
Unfortunately, the class BundleWriter swallows the root cause of the exception.
was:
I saw the following exception in a log file:
{code}
Unexpected error while writing NAME value.
at
org.apache.jackrabbit.core.persistence.util.BundleWriter.writeState(BundleWriter.java:312)
at
org.apache.jackrabbit.core.persistence.util.BundleWriter.writeBundle(BundleWriter.java:131)
at
org.apache.jackrabbit.core.persistence.util.BundleBinding.writeBundle(BundleBinding.java:164)
{code}
Unfortunately, the class BundleWriter swallows the root cause of the exception.
BundleWriter: Unexpected error while writing NAME value.
Key: JCR-3684
URL: https://issues.apache.org/jira/browse/JCR-3684
Project: Jackrabbit Content Repository
Issue Type: Bug
Reporter: Thomas Mueller
Assignee: Thomas Mueller
I saw the following exception in a log file:
Unexpected error while writing NAME value.
at
org.apache.jackrabbit.core.persistence.util.BundleWriter.writeState(BundleWriter.java:312)
at
org.apache.jackrabbit.core.persistence.util.BundleWriter.writeBundle(BundleWriter.java:131)
at
org.apache.jackrabbit.core.persistence.util.BundleBinding.writeBundle(BundleBinding.java:164)
Unfortunately, the class BundleWriter swallows the root cause of the
exception.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (JCR-3684) BundleWriter: Unexpected error while writing NAME value.
[ https://issues.apache.org/jira/browse/JCR-3684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13796822#comment-13796822 ] Thomas Mueller commented on JCR-3684: - Revision 1532775 (trunk - don't swallow the root cause) BundleWriter: Unexpected error while writing NAME value. Key: JCR-3684 URL: https://issues.apache.org/jira/browse/JCR-3684 Project: Jackrabbit Content Repository Issue Type: Bug Reporter: Thomas Mueller Assignee: Thomas Mueller I saw the following exception in a log file: Unexpected error while writing NAME value. at org.apache.jackrabbit.core.persistence.util.BundleWriter.writeState(BundleWriter.java:312) at org.apache.jackrabbit.core.persistence.util.BundleWriter.writeBundle(BundleWriter.java:131) at org.apache.jackrabbit.core.persistence.util.BundleBinding.writeBundle(BundleBinding.java:164) Unfortunately, the class BundleWriter swallows the root cause of the exception. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JCR-3652) Bundle serialization broken
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13781667#comment-13781667 ] Thomas Mueller commented on JCR-3652: - [~rah003] I believe 2.6 is also affected. I will try to fix it there as well. Bundle serialization broken --- Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 2.4.4, 2.7.1 Attachments: JCR-3652-b.patch, JCR-3652.patch, JCR-3652-test-case.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (JCR-3652) Bundle serialization broken
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-3652: Fix Version/s: 2.6.4 Bundle serialization broken --- Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 2.4.4, 2.6.4, 2.7.1 Attachments: JCR-3652-b.patch, JCR-3652.patch, JCR-3652-test-case.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JCR-3652) Bundle serialization broken
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13781728#comment-13781728 ] Thomas Mueller commented on JCR-3652: - Revision 1527505: fixed in the 2.6 branch Bundle serialization broken --- Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 2.4.4, 2.6.4, 2.7.1 Attachments: JCR-3652-b.patch, JCR-3652.patch, JCR-3652-test-case.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JCR-3651) S3 Datastore implementation
[
https://issues.apache.org/jira/browse/JCR-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13764314#comment-13764314
]
Thomas Mueller commented on JCR-3651:
-
Thanks a lot! I have a few more comments:
- The code currently doesn't use {{@Override}}
- There are some unused imports
- There is a lot of duplicate code in TestCaseBase
- CachingDataStore.addRecord: length is not used
- CachingDataStore.mkdirs can be declared static
- S3Backend.write: uploadResult is not used
- S3Backend.getKeyName can be declared static
- S3Backend.getIdentifierName can be declared static
- TestS3Ds and TestInMemDsCacheOff LOG is not used
- if (...) should use {}
- I have changed the visibility of some fields and methods
to avoid synthetic accessor methods
I will try to commit the patch now.
S3 Datastore implementation
---
Key: JCR-3651
URL: https://issues.apache.org/jira/browse/JCR-3651
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-core
Affects Versions: 2.7
Reporter: Shashank Gupta
Attachments: JCR-3651.patch, JCR-3651-svn.patch,
JCR-3651-svn-updated.patch
S3 Datastore provides capability to use Amazon S3 as datastore, thus
leveraging all benefits of Amazon S3 like low cost, infinite, reliable,
scalable storage.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3651) S3 Datastore implementation
[ https://issues.apache.org/jira/browse/JCR-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13764363#comment-13764363 ] Thomas Mueller commented on JCR-3651: - After a little fight with SVN I have committed the patch in revision 1521876. I'm not quite sure yet if everything is correct, specially the pom file. But I guess it should be possible to fix that. S3 Datastore implementation --- Key: JCR-3651 URL: https://issues.apache.org/jira/browse/JCR-3651 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Affects Versions: 2.7 Reporter: Shashank Gupta Attachments: JCR-3651.patch, JCR-3651-svn.patch, JCR-3651-svn-updated.patch S3 Datastore provides capability to use Amazon S3 as datastore, thus leveraging all benefits of Amazon S3 like low cost, infinite, reliable, scalable storage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3651) S3 Datastore implementation
[
https://issues.apache.org/jira/browse/JCR-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757627#comment-13757627
]
Thomas Mueller commented on JCR-3651:
-
Hi,
Some more comments. There are many Java beginners errors in the code.
Don't initialize fields to their default value (null, false,...) :
{code}
protected String config = null;
{code}
Instead, simply use:
{code}
protected String config;
{code}
In the test class hierarchy there are duplicate fields, similar to:
{code}
class TestBase {
protected String config;
}
class TestExtends extends TestBase {
protected String config;
}
{code}
The second field hides the field in TestBase.
Many of the Javadocs comments are low quality; they don't add any valuable
information. They should either be removed or a meaningful description should
be added. Example:
{code}
+ * @param store
+ * @param homeDir
+ * @param config
+ * @throws DataStoreException
+ */
+void init(CachingDataStore store, String homeDir, String config) throws
DataStoreException;
{code}
Also, javadocs of the following type are basically no-ops and should be removed:
{code}
+/**
+ * @inheritDoc
+ */
{code}
There are some comments // TODO Auto-generated method stub, they should be
removed.
I suggest to use an IDE such as Eclipse or IntelliJ, enable code warnings and
go though that list and fix the warnings. Also, I suggest to use Checkstyle.
S3 Datastore implementation
---
Key: JCR-3651
URL: https://issues.apache.org/jira/browse/JCR-3651
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-core
Affects Versions: 2.7
Reporter: Shashank Gupta
Fix For: 2.7.1
Attachments: JCR-3651.patch, JCR-3651-svn.patch
S3 Datastore provides capability to use Amazon S3 as datastore, thus
leveraging all benefits of Amazon S3 like low cost, infinite, reliable,
scalable storage.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3652) Bundle serialization broken
[
https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752183#comment-13752183
]
Thomas Mueller commented on JCR-3652:
-
I think I have a test case now that can reproduce the problem with very simple
operations (only one workspace):
{code}
public void testCopyCheckedOut() throws Exception {
Node root = superuser.getRootNode();
String nodeName = testCopyCheckedOut + System.currentTimeMillis();
if (root.hasNode(nodeName)) {
root.getNode(nodeName).remove();
superuser.save();
}
Node test = root.addNode(nodeName);
Node a = test.addNode(a);
Node b = test.addNode(b);
b.addMixin(mix:versionable);
superuser.save();
Value v = b.getProperty(jcr:isCheckedOut).getValue();
try {
a.setProperty(jcr:isCheckedOut, v);
} catch (ArrayIndexOutOfBoundsException e) {
System.out.println(set failed strangely: + e);
}
System.out.println(a.getProperty(jcr:isCheckedOut).getValue().getString());
System.out.println(b.getProperty(jcr:isCheckedOut).getValue().getString());
}
{code}
This test prints set failed strangely:
java.lang.ArrayIndexOutOfBoundsException: 0 and then fails with
{code}
javax.jcr.RepositoryException: property
/testCopyCheckedOut1377674810028/a/jcr:isCheckedOut: single-valued property
with no value
at
org.apache.jackrabbit.core.PropertyImpl.internalGetValue(PropertyImpl.java:492)
at
org.apache.jackrabbit.core.PropertyImpl.getValue(PropertyImpl.java:510)
{code}
This is with my current version of Jackrabbit (that has added checks)
Bundle serialization broken
---
Key: JCR-3652
URL: https://issues.apache.org/jira/browse/JCR-3652
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-core
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Priority: Minor
Fix For: 2.4.4, 2.7.1
Attachments: JCR-3652.patch, JCR-3652-test-case.patch
I have got a strange case where some node bundle is broken, seemingly because
a byte is missing. I can't explain the missing byte, but it is reproducible,
meaning that writing the bundles again will break them again. There are 11
broken bundles, 10 of them have the size 480 bytes and one is slightly
larger. It is always a boolean property value that is missing, always the
value for the property jcr:isCheckedOut.
As a (temporary) solution, and to help analyze what the problem might be, I
will create a patch that does the following:
* When serializing a bundle, check if the byte array can be de-serialized. If
not, then try again. Starting with the 3th try, use a slower variant where
before and after writing the boolean value the buffer is flushed. I'm aware
that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the
problem (let's see) if the problem is related to a JVM issue.
* If de-serializing a bundle fails, check if it's because of a missing
boolean property value. If yes, insert the missing byte.
I have also added some log messages (warning / error) to help analyze the
problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3652) Bundle serialization broken
[
https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752202#comment-13752202
]
Thomas Mueller commented on JCR-3652:
-
A simpler test case:
{code}
Node node = root.addNode(nodeName);
superuser.save();
try {
node.setProperty(jcr:isCheckedOut, true);
} catch (ArrayIndexOutOfBoundsException e) {
System.out.println(set failed strangely: + e);
}
System.out.println(node.getProperty(jcr:isCheckedOut).getValue().getString());
{code}
I think what happens is: the property is half-way added (in
NodeImpl.SetPropertyOperation.perform, PropertyImpl property =
getOrCreateProperty(name, type, false, enforceType, status);). The property is
non-multi-valued, and the values array is 0. This seems to be always done like
that. Then it tries to set the value, with a try { property.setValue(value); }
catch(RepositoryException) { ... revert ... }. The setValue checks if setting
the value is allowed (via checkSetValue, which calls ItemValidator.checkModify,
which calls ItemValidator.checkCondition). At some point this verification
calls NodeImpl.isCheckedOut(). There is a // FIXME should not only rely on
existence of jcr:isCheckedOut property in the code, but for performance reason
it just gets the value of the jcr:isCheckedOut property, using return
ps.getValues()[0].getBoolean();. Now, as the property is half-way set, this
throws an ArrayOutOfBoundsException (half-way set properties have an empty
values array). Because this isn't a RepositoryException, this is thrown back to
the user, and the property remains half-way set. The internal state of the node
is corrupt.
One solution is to change NodeImpl.isCheckedOut() to deal with a half-way set
property, and throw a RepositoryException instead of a
ArrayOutOfBoundsException. However, there might be more checks that don't deal
with half-way set properties.
In addition to the above, instead of just catching RepositoryException, the
code could catch Exception or even Throwable (that is, also Error). Usually
catching Throwable isn't a good idea, however the alternative (having a corrupt
node) is much worse, so I guess this should also be done.
The best solution would be not to have half-way set properties at all, but that
would be quite a big change, so I will not try to do that.
Bundle serialization broken
---
Key: JCR-3652
URL: https://issues.apache.org/jira/browse/JCR-3652
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-core
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Priority: Minor
Fix For: 2.4.4, 2.7.1
Attachments: JCR-3652.patch, JCR-3652-test-case.patch
I have got a strange case where some node bundle is broken, seemingly because
a byte is missing. I can't explain the missing byte, but it is reproducible,
meaning that writing the bundles again will break them again. There are 11
broken bundles, 10 of them have the size 480 bytes and one is slightly
larger. It is always a boolean property value that is missing, always the
value for the property jcr:isCheckedOut.
As a (temporary) solution, and to help analyze what the problem might be, I
will create a patch that does the following:
* When serializing a bundle, check if the byte array can be de-serialized. If
not, then try again. Starting with the 3th try, use a slower variant where
before and after writing the boolean value the buffer is flushed. I'm aware
that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the
problem (let's see) if the problem is related to a JVM issue.
* If de-serializing a bundle fails, check if it's because of a missing
boolean property value. If yes, insert the missing byte.
I have also added some log messages (warning / error) to help analyze the
problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (JCR-3652) Bundle serialization broken
[
https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752202#comment-13752202
]
Thomas Mueller edited comment on JCR-3652 at 8/28/13 8:32 AM:
--
A simpler test case:
{code}
Node node = root.addNode(nodeName);
superuser.save();
try {
node.setProperty(jcr:isCheckedOut, true);
} catch (ArrayIndexOutOfBoundsException e) {
System.out.println(set failed strangely: + e);
}
System.out.println(node.getProperty(jcr:isCheckedOut).getValue().getString());
{code}
I think what happens is: the property is half-way added (in
NodeImpl.SetPropertyOperation.perform, PropertyImpl property =
getOrCreateProperty(name, type, false, enforceType, status)). The property is
non-multi-valued, and the values array is 0. This seems to be always done like
that. Then it tries to set the value, with
{code}
try {
property.setValue(value);
} catch(RepositoryException) {
... revert ...
}
{code}
The setValue checks if setting the value is allowed (via checkSetValue, which
calls ItemValidator.checkModify, which calls ItemValidator.checkCondition). At
some point this verification calls NodeImpl.isCheckedOut(). There is a //
FIXME should not only rely on existence of jcr:isCheckedOut property in the
code, but for performance reason it just gets the value of the jcr:isCheckedOut
property, using return ps.getValues()[0].getBoolean();. Now, as the property
is half-way set, this throws an ArrayOutOfBoundsException (half-way set
properties have an empty values array). Because this isn't a
RepositoryException, this is thrown back to the user, and the property remains
half-way set. The internal state of the node is corrupt.
One solution is to change NodeImpl.isCheckedOut() to deal with a half-way set
property, and throw a RepositoryException instead of a
ArrayOutOfBoundsException. However, there might be more checks that don't deal
with half-way set properties.
In addition to the above, instead of just catching RepositoryException, the
code could catch Exception or even Throwable (that is, also Error). Usually
catching Throwable isn't a good idea, however the alternative (having a corrupt
node) is much worse, so I guess this should also be done.
The best solution would be not to have half-way set properties at all, but that
would be quite a big change, so I will not try to do that.
was (Author: tmueller):
A simpler test case:
{code}
Node node = root.addNode(nodeName);
superuser.save();
try {
node.setProperty(jcr:isCheckedOut, true);
} catch (ArrayIndexOutOfBoundsException e) {
System.out.println(set failed strangely: + e);
}
System.out.println(node.getProperty(jcr:isCheckedOut).getValue().getString());
{code}
I think what happens is: the property is half-way added (in
NodeImpl.SetPropertyOperation.perform, PropertyImpl property =
getOrCreateProperty(name, type, false, enforceType, status);). The property is
non-multi-valued, and the values array is 0. This seems to be always done like
that. Then it tries to set the value, with a try { property.setValue(value); }
catch(RepositoryException) { ... revert ... }. The setValue checks if setting
the value is allowed (via checkSetValue, which calls ItemValidator.checkModify,
which calls ItemValidator.checkCondition). At some point this verification
calls NodeImpl.isCheckedOut(). There is a // FIXME should not only rely on
existence of jcr:isCheckedOut property in the code, but for performance reason
it just gets the value of the jcr:isCheckedOut property, using return
ps.getValues()[0].getBoolean();. Now, as the property is half-way set, this
throws an ArrayOutOfBoundsException (half-way set properties have an empty
values array). Because this isn't a RepositoryException, this is thrown back to
the user, and the property remains half-way set. The internal state of the node
is corrupt.
One solution is to change NodeImpl.isCheckedOut() to deal with a half-way set
property, and throw a RepositoryException instead of a
ArrayOutOfBoundsException. However, there might be more checks that don't deal
with half-way set properties.
In addition to the above, instead of just catching RepositoryException, the
code could catch Exception or even Throwable (that is, also Error). Usually
catching Throwable isn't a good idea, however the alternative (having a corrupt
node) is much worse, so I guess this should also be done.
The best solution would be not to have half-way set properties at all, but that
would be quite a big change, so I will not try to do that.
Bundle serialization broken
---
Key: JCR-3652
URL: https://issues.apache.org/jira/browse/JCR-3652
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-core
[jira] [Updated] (JCR-3652) Bundle serialization broken
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-3652: Attachment: JCR-3652-b.patch Proposed patch. Bundle serialization broken --- Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 2.4.4, 2.7.1 Attachments: JCR-3652-b.patch, JCR-3652.patch, JCR-3652-test-case.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCR-3652) Bundle serialization broken
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-3652. - Resolution: Fixed (Reading broken bundles is still supported, but only in the 2.4 branch) Bundle serialization broken --- Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 2.7.1, 2.4.4 Attachments: JCR-3652-b.patch, JCR-3652.patch, JCR-3652-test-case.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3652) Bundle serialization broken
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752315#comment-13752315 ] Thomas Mueller commented on JCR-3652: - Fixed in revision 1518170 (trunk), revision 1518118, 1518122 (2.4 branch). Bundle serialization broken --- Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 2.4.4, 2.7.1 Attachments: JCR-3652-b.patch, JCR-3652.patch, JCR-3652-test-case.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3652) Bundle serialization broken
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-3652: Environment: (was: Windows java version 1.6.0_38 Java(TM) SE Runtime Environment (build 1.6.0_38-b05) Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode)) Fix Version/s: 2.7.1 Summary: Bundle serialization broken (was: Bundle serialization broken due to missing byte for boolean property) Bundle serialization broken --- Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 2.4.4, 2.7.1 Attachments: JCR-3652.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3652) Bundle serialization broken
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-3652: Attachment: JCR-3652-test-case.patch Test case to create a corrupt bundle. Bundle serialization broken --- Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 2.4.4, 2.7.1 Attachments: JCR-3652.patch, JCR-3652-test-case.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3652) Bundle serialization broken
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13751211#comment-13751211 ] Thomas Mueller commented on JCR-3652: - The main problem seems to be that in PropertyState, the fields multiValued and values are set independently, even thought they depend on each other. To avoid problems, it would be better if the fields can not be changed independently. (Or if there is only one field, for example Object x which can be a Value or a Value[]). There are also problems in the BundleWriter class, mainly dangerous assertions. For example, the assertion that the values array is one for single-value properties is only checked if assertions are enabled. Or, names with an empty local name break the bundle serialization. Also, the assert on the property type is only check if assertions are enabled, and the switch for property types doesn't throw an exception for an unknown property type. There are also not enough test cases. I am preparing a patch for this. Bundle serialization broken --- Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 2.4.4, 2.7.1 Attachments: JCR-3652.patch, JCR-3652-test-case.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3652) Bundle serialization broken due to missing byte for boolean property
[
https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13749883#comment-13749883
]
Thomas Mueller commented on JCR-3652:
-
It turned out there is a property named jcr:isCheckedOut of type boolean,
non-multi-valued, but with a values array of length 0. The toString
representation of this property is:
{code}
582b5739-0696-4fa8-904f-eade273feab0/{http://www.jcp.org/jcr/1.0}isCheckedOut(Boolean)
= []
{code}
Now the question is, how could the property get an empty (zero-length) values
array.
In theory that could be caused by out-of-memory after setting the property type
and isMultiValued flag, and before setting the values array. But I don't see
any out-of-memory errors, and there are 11 such nodes. So I think there has to
be a different explanation, like a repository exception after setting the
property type and isMultiValued flag, and before setting the values array.
Bundle serialization broken due to missing byte for boolean property
Key: JCR-3652
URL: https://issues.apache.org/jira/browse/JCR-3652
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-core
Environment: Windows
java version 1.6.0_38
Java(TM) SE Runtime Environment (build 1.6.0_38-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode)
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Priority: Minor
Fix For: 2.4.4
Attachments: JCR-3652.patch
I have got a strange case where some node bundle is broken, seemingly because
a byte is missing. I can't explain the missing byte, but it is reproducible,
meaning that writing the bundles again will break them again. There are 11
broken bundles, 10 of them have the size 480 bytes and one is slightly
larger. It is always a boolean property value that is missing, always the
value for the property jcr:isCheckedOut.
As a (temporary) solution, and to help analyze what the problem might be, I
will create a patch that does the following:
* When serializing a bundle, check if the byte array can be de-serialized. If
not, then try again. Starting with the 3th try, use a slower variant where
before and after writing the boolean value the buffer is flushed. I'm aware
that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the
problem (let's see) if the problem is related to a JVM issue.
* If de-serializing a bundle fails, check if it's because of a missing
boolean property value. If yes, insert the missing byte.
I have also added some log messages (warning / error) to help analyze the
problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3652) Bundle serialization broken due to missing byte for boolean property
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13749949#comment-13749949 ] Thomas Mueller commented on JCR-3652: - One potential code path is: NodeStateEx.setPropertyValues. When updating an existing property, the type and values array is set, but the multiple flag is ignored. So it seems to be possible to set the property values to an empty array, for an existing, non-multi-valued property state. The question is, when and why is this method called for the property isCheckedOut with an empty values array. Bundle serialization broken due to missing byte for boolean property Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Environment: Windows java version 1.6.0_38 Java(TM) SE Runtime Environment (build 1.6.0_38-b05) Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode) Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 2.4.4 Attachments: JCR-3652.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3652) Bundle serialization broken due to missing byte for boolean property
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13747392#comment-13747392 ] Thomas Mueller commented on JCR-3652: - Revision 1516397: Committed to the 2.4 branch. The feature is enabled using the jackrabbit.verifyBundles system property. To verify it is used, see the log file for the message Please note reading and writing bundles is slightly slower... Bundle serialization broken due to missing byte for boolean property Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Environment: Windows java version 1.6.0_38 Java(TM) SE Runtime Environment (build 1.6.0_38-b05) Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode) Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Attachments: JCR-3652.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3652) Bundle serialization broken due to missing byte for boolean property
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-3652: Fix Version/s: 2.4.4 Bundle serialization broken due to missing byte for boolean property Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Environment: Windows java version 1.6.0_38 Java(TM) SE Runtime Environment (build 1.6.0_38-b05) Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode) Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 2.4.4 Attachments: JCR-3652.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Moved] (JCR-3652) Bundle serialization broken due to missing byte for boolean property
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller moved OAK-973 to JCR-3652: - Workflow: no-reopen-closed, patch-avail (was: no-reopen-closed) Key: JCR-3652 (was: OAK-973) Project: Jackrabbit Content Repository (was: Jackrabbit Oak) Bundle serialization broken due to missing byte for boolean property Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3652) Bundle serialization broken due to missing byte for boolean property
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-3652: Component/s: jackrabbit-core Environment: Windows java version 1.6.0_38 Java(TM) SE Runtime Environment (build 1.6.0_38-b05) Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode) Bundle serialization broken due to missing byte for boolean property Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Environment: Windows java version 1.6.0_38 Java(TM) SE Runtime Environment (build 1.6.0_38-b05) Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode) Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3652) Bundle serialization broken due to missing byte for boolean property
[ https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-3652: Attachment: JCR-3652.patch There is also a system property jackrabbit.allowBrokenBundleWrites. If enabled, broken bundles are written if re-try writing them failed and if they can be patched by inserting the missing byte. The inserted byte is always 1 (the property value is always true). Bundle serialization broken due to missing byte for boolean property Key: JCR-3652 URL: https://issues.apache.org/jira/browse/JCR-3652 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Environment: Windows java version 1.6.0_38 Java(TM) SE Runtime Environment (build 1.6.0_38-b05) Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode) Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Attachments: JCR-3652.patch I have got a strange case where some node bundle is broken, seemingly because a byte is missing. I can't explain the missing byte, but it is reproducible, meaning that writing the bundles again will break them again. There are 11 broken bundles, 10 of them have the size 480 bytes and one is slightly larger. It is always a boolean property value that is missing, always the value for the property jcr:isCheckedOut. As a (temporary) solution, and to help analyze what the problem might be, I will create a patch that does the following: * When serializing a bundle, check if the byte array can be de-serialized. If not, then try again. Starting with the 3th try, use a slower variant where before and after writing the boolean value the buffer is flushed. I'm aware that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the problem (let's see) if the problem is related to a JVM issue. * If de-serializing a bundle fails, check if it's because of a missing boolean property value. If yes, insert the missing byte. I have also added some log messages (warning / error) to help analyze the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3652) Bundle serialization broken due to missing byte for boolean property
[
https://issues.apache.org/jira/browse/JCR-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13746050#comment-13746050
]
Thomas Mueller commented on JCR-3652:
-
Additional change to help verify the patch is installed:
{code}
#P jackrabbit-core-r-1372412
Index:
src/main/java/org/apache/jackrabbit/core/persistence/util/BundleBinding.java
===
---
src/main/java/org/apache/jackrabbit/core/persistence/util/BundleBinding.java
(revision 1372412)
+++
src/main/java/org/apache/jackrabbit/core/persistence/util/BundleBinding.java
(working copy)
@@ -23,11 +25,21 @@
import org.apache.jackrabbit.core.data.DataStore;
import org.apache.jackrabbit.core.id.NodeId;
import org.apache.jackrabbit.core.util.StringIndex;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
/**
* This Class implements efficient serialization methods for item states.
*/
public class BundleBinding {
+
+private static boolean ALLOW_BROKEN_BUNDLES =
Boolean.getBoolean(jackrabbit.allowBrokenBundleWrites);
+
+private static Logger log = LoggerFactory.getLogger(BundleBinding.class);
+
+static {
+log.warn(Please note this is a patched version of Jackrabbit which is
slightly slower. See JCR-3652.);
+}
{code}
Bundle serialization broken due to missing byte for boolean property
Key: JCR-3652
URL: https://issues.apache.org/jira/browse/JCR-3652
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-core
Environment: Windows
java version 1.6.0_38
Java(TM) SE Runtime Environment (build 1.6.0_38-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode)
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Priority: Minor
Attachments: JCR-3652.patch
I have got a strange case where some node bundle is broken, seemingly because
a byte is missing. I can't explain the missing byte, but it is reproducible,
meaning that writing the bundles again will break them again. There are 11
broken bundles, 10 of them have the size 480 bytes and one is slightly
larger. It is always a boolean property value that is missing, always the
value for the property jcr:isCheckedOut.
As a (temporary) solution, and to help analyze what the problem might be, I
will create a patch that does the following:
* When serializing a bundle, check if the byte array can be de-serialized. If
not, then try again. Starting with the 3th try, use a slower variant where
before and after writing the boolean value the buffer is flushed. I'm aware
that ByteArrayOutputStream.flush doesn't do much, but maybe it solves the
problem (let's see) if the problem is related to a JVM issue.
* If de-serializing a bundle fails, check if it's because of a missing
boolean property value. If yes, insert the missing byte.
I have also added some log messages (warning / error) to help analyze the
problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3638) Search indexing takes longer time
[ https://issues.apache.org/jira/browse/JCR-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731880#comment-13731880 ] Thomas Mueller commented on JCR-3638: - One solution that I think should work is: change the index configuration, restart, and then touch (modify the node so it is re-indexed) each node in the repository (well, actually only those nodes you care about). Search indexing takes longer time - Key: JCR-3638 URL: https://issues.apache.org/jira/browse/JCR-3638 Project: Jackrabbit Content Repository Issue Type: Wish Components: indexing Affects Versions: 2.6 Environment: windows server 2003, java 1.7 64bit Reporter: Nilay Parmar We have 700GB of datastore in production. we have upgraded jackrabbit from 2.2.7 to 2.6.0. though there is a backward compatibility as far as indexes are concerned, we want to re-build the indexes from scratch. because we were not indexing XLSX type of documents previously but now we will going to support that in 2.6.0. as datastore size if large, index creation process was not completed in 36Hrs of time. is there any way, we can increase the speed of indexing process or create the indexes in chunks? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3634) New method: JackrabbitRepository.login(Credentials, MapString, Object)
[
https://issues.apache.org/jira/browse/JCR-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723660#comment-13723660
]
Thomas Mueller commented on JCR-3634:
-
The JCR standard doesn't currently define a separate attributes parameter,
there is only {{login(Credentials credentials, String workspaceName)}}. For the
next version of the standard, maybe we should consider adding this method?
New method: JackrabbitRepository.login(Credentials, MapString, Object)
Key: JCR-3634
URL: https://issues.apache.org/jira/browse/JCR-3634
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api
Affects Versions: 2.7.1
Reporter: Michael Dürig
As discussed [1] we need a way for passing session attributes on login
without having to fall back to credentials. The latter might not support
credentials or not be present at all when authentication is handled
externally.
I suggest to add the following method to JackrabbitRepository:
/**
* Equivalent to codelogin(credentials, workspace)/code where
* ul
* licodeworkspace = attributes.get(ATT_WORKSPACE_NAME)/code,/li
* licodecredentials/code carry all and only the attributes passed
* through the codeattributes/code map./li
* /ul
*
* @param credentials the credentials of the user
* @param attributes the attributes to put into the session
* @return a valid session for the user to access the repository.
* @throws javax.jcr.LoginException if authentication or authorization for
the
* specified workspace fails.
* @throws javax.jcr.NoSuchWorkspaceException if the specified workspace is
not recognized.
* @throws javax.jcr.RepositoryException if another error occurs.
*/
Session login(Credentials credentials, MapString, Object attributes);
See also OAK-803 for some more background.
[1] http://markmail.org/message/lwhpglehee3jgpip
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (JCR-3634) New method: JackrabbitRepository.login(Credentials, MapString, Object)
[
https://issues.apache.org/jira/browse/JCR-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723660#comment-13723660
]
Thomas Mueller edited comment on JCR-3634 at 7/30/13 10:19 AM:
---
The JCR standard doesn't currently define a separate attributes parameter,
there is only login(Credentials credentials, String workspaceName). For the
next version of the standard, maybe we should consider adding this method?
was (Author: tmueller):
The JCR standard doesn't currently define a separate attributes parameter,
there is only {{login(Credentials credentials, String workspaceName)}}. For the
next version of the standard, maybe we should consider adding this method?
New method: JackrabbitRepository.login(Credentials, MapString, Object)
Key: JCR-3634
URL: https://issues.apache.org/jira/browse/JCR-3634
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api
Affects Versions: 2.7.1
Reporter: Michael Dürig
As discussed [1] we need a way for passing session attributes on login
without having to fall back to credentials. The latter might not support
credentials or not be present at all when authentication is handled
externally.
I suggest to add the following method to JackrabbitRepository:
/**
* Equivalent to codelogin(credentials, workspace)/code where
* ul
* licodeworkspace = attributes.get(ATT_WORKSPACE_NAME)/code,/li
* licodecredentials/code carry all and only the attributes passed
* through the codeattributes/code map./li
* /ul
*
* @param credentials the credentials of the user
* @param attributes the attributes to put into the session
* @return a valid session for the user to access the repository.
* @throws javax.jcr.LoginException if authentication or authorization for
the
* specified workspace fails.
* @throws javax.jcr.NoSuchWorkspaceException if the specified workspace is
not recognized.
* @throws javax.jcr.RepositoryException if another error occurs.
*/
Session login(Credentials credentials, MapString, Object attributes);
See also OAK-803 for some more background.
[1] http://markmail.org/message/lwhpglehee3jgpip
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JCR-3599) Lucene: colliding concurrency node creation
Thomas Mueller created JCR-3599: --- Summary: Lucene: colliding concurrency node creation Key: JCR-3599 URL: https://issues.apache.org/jira/browse/JCR-3599 Project: Jackrabbit Content Repository Issue Type: Bug Components: query Reporter: Thomas Mueller It seems the Lucene index tries to create the same node concurrently when using multiple threads (one session per thread). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3547) Datastore GC doesn't reset updateModifiedDateOnAccess on datastore
[ https://issues.apache.org/jira/browse/JCR-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658156#comment-13658156 ] Thomas Mueller commented on JCR-3547: - Sorry for the delay. The patch looks good, I will run the tests and commit it then (to the trunk for now). Datastore GC doesn't reset updateModifiedDateOnAccess on datastore -- Key: JCR-3547 URL: https://issues.apache.org/jira/browse/JCR-3547 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.4, 2.5 Reporter: Shashank Gupta Attachments: GarbageCollector.java.patch, GC_prevent_concurrent_run_app2.patch, GC_prevent_concurrent_run_final.patch, GC_prevent_concurrnet_run_app1.patch In mark phase, GC updates store.updateModifiedDateOnAccess with current time, so that datastore updates record’s lastModified timestamp upon subsequent read/scan. But GC doesn't reset it to 0. So even after GC completes, datastore will continue updating lastModified timestamp on read invocations and it will have performance impact. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3547) Datastore GC doesn't reset updateModifiedDateOnAccess on datastore
[ https://issues.apache.org/jira/browse/JCR-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658185#comment-13658185 ] Thomas Mueller commented on JCR-3547: - Committed in revision 1482732 Datastore GC doesn't reset updateModifiedDateOnAccess on datastore -- Key: JCR-3547 URL: https://issues.apache.org/jira/browse/JCR-3547 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.4, 2.5 Reporter: Shashank Gupta Attachments: GarbageCollector.java.patch, GC_prevent_concurrent_run_app2.patch, GC_prevent_concurrent_run_final.patch, GC_prevent_concurrnet_run_app1.patch In mark phase, GC updates store.updateModifiedDateOnAccess with current time, so that datastore updates record’s lastModified timestamp upon subsequent read/scan. But GC doesn't reset it to 0. So even after GC completes, datastore will continue updating lastModified timestamp on read invocations and it will have performance impact. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (JCR-3547) Datastore GC doesn't reset updateModifiedDateOnAccess on datastore
[ https://issues.apache.org/jira/browse/JCR-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned JCR-3547: --- Assignee: Thomas Mueller Datastore GC doesn't reset updateModifiedDateOnAccess on datastore -- Key: JCR-3547 URL: https://issues.apache.org/jira/browse/JCR-3547 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.4, 2.5 Reporter: Shashank Gupta Assignee: Thomas Mueller Attachments: GarbageCollector.java.patch, GC_prevent_concurrent_run_app2.patch, GC_prevent_concurrent_run_final.patch, GC_prevent_concurrnet_run_app1.patch In mark phase, GC updates store.updateModifiedDateOnAccess with current time, so that datastore updates record’s lastModified timestamp upon subsequent read/scan. But GC doesn't reset it to 0. So even after GC completes, datastore will continue updating lastModified timestamp on read invocations and it will have performance impact. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3547) Datastore GC doesn't reset updateModifiedDateOnAccess on datastore
[ https://issues.apache.org/jira/browse/JCR-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-3547: Resolution: Fixed Fix Version/s: 2.7.1 Status: Resolved (was: Patch Available) Datastore GC doesn't reset updateModifiedDateOnAccess on datastore -- Key: JCR-3547 URL: https://issues.apache.org/jira/browse/JCR-3547 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.4, 2.5 Reporter: Shashank Gupta Assignee: Thomas Mueller Fix For: 2.7.1 Attachments: GarbageCollector.java.patch, GC_prevent_concurrent_run_app2.patch, GC_prevent_concurrent_run_final.patch, GC_prevent_concurrnet_run_app1.patch In mark phase, GC updates store.updateModifiedDateOnAccess with current time, so that datastore updates record’s lastModified timestamp upon subsequent read/scan. But GC doesn't reset it to 0. So even after GC completes, datastore will continue updating lastModified timestamp on read invocations and it will have performance impact. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13644389#comment-13644389
]
Thomas Mueller commented on JCR-3534:
-
we may defer the salt / expiry stuff as possible further improvement
Yes. Implementing this would be rather easy and can be done later.
Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.6
Reporter: Felix Meschberger
Attachments: JCR-3534.patch
we have a couple of use cases, where we would like to leverage the global
data store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use
the same DataStore (for the sake of this discussion assume we have the
problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send
potentially large binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether
the such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread
http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method
[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641512#comment-13641512
]
Thomas Mueller commented on JCR-3534:
-
the price of parsing JSON ... Not worth it IMHO
I'm not worried about the speed of parsing: verifying the signature is the slow
part. Sure, it should be simple to implement, but shouldn't prevent us from
changing the algorithm in the future. A key-value list would be nice, or
something similar to the format used in PasswordUtility.
What is the problem with this message leaking
Well, this message is an access token. It provides access to more than just the
leaked data. It's kind of like a password to get more data.
Add JackrabbitSession.getValueByContentId method
Key: JCR-3534
URL: https://issues.apache.org/jira/browse/JCR-3534
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-api, jackrabbit-core
Affects Versions: 2.6
Reporter: Felix Meschberger
Attachments: JCR-3534.patch
we have a couple of use cases, where we would like to leverage the global
data store to prevent sending around and copying around large binary data
unnecessarily: We have two separate Jackrabbit instances configured to use
the same DataStore (for the sake of this discussion assume we have the
problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send
potentially large binary data (e.g. video files) if not needed.
The idea is for the sender to just send the content identity from
JackrabbitValue.getContentIdentity(). The receiver would then check whether
the such content already exists and would reuse if so:
String ci = contentIdentity_from_sender;
try {
Value v = session.getValueByContentIdentity(ci);
Property p = targetNode.setProperty(propName, v);
} catch (ItemNotFoundException ie) {
// unknown or invalid content Identity
} catch (RepositoryException re) {
// some other exception
}
Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
would allow for round tripping the JackrabbitValue.getContentIdentity()
preventing superfluous binary data copying and moving.
See also the dev@ thread
http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
