[jira] [Updated] (OAK-2644) Lift the 150 character limit on item names
[ https://issues.apache.org/jira/browse/OAK-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-2644: Component/s: (was: core) rdbmk mongomk Lift the 150 character limit on item names -- Key: OAK-2644 URL: https://issues.apache.org/jira/browse/OAK-2644 Project: Jackrabbit Oak Issue Type: Wish Components: mongomk, rdbmk Affects Versions: 1.0.12, 1.1.7 Reporter: Felix Meschberger Currently -- as of Oak 1.1.7 and 1.0.12 releases -- there is a limit on the length of 150 characters for item names in Oak. This limit seems to be based upon a limitation in the MongoDB MK implementation because MongoDB has a limit of 1024 bytes (I think) for indexable properties. I think this limitation is highly unexpected and seems to be largeyl undocumented. For previous users of Jackrabbit it should probably at least be documented on the [Backwards Compatibility|http://jackrabbit.apache.org/oak/docs/differences.html] page. The main problem, though, I have with this limit is, that it is based on a limitation of a particular MK implementation and hits through the full stack. I would have rather expected such a persistence limitation to be fully hidden and handled inside the MK implementation. Granted this limitation does not seem to violate the JCR 2.1 specification which clearly states in section 3.2.4 Naming Restrictions: bq. This definition of JCR name represents the least restrictive set of constraints permitted for the naming of items and other entities. A repository may further restrict the names of entities to a subset of JCR names and in most cases is encouraged to do so. and bq. A writable repository may enforce any implementation-specific constraint by causing an exception to be thrown on an invalid JCR write method call. Still I think it is a questionable limitation for a generic repository where such names may be auto-generated and thus be quite long depending on the use case. I understand this may be hard to fix but would still be happy to be able to have (virtually) unlimited name length again as it was the case in Jackrabbit 2. Thanks. See also OAK-333 for a previous discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2644) Lift the 150 character limit on node names
[ https://issues.apache.org/jira/browse/OAK-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2644: -- Affects Version/s: (was: 1.1.7) (was: 1.0.12) 1.0 Issue Type: Improvement (was: Wish) Changed affected versions. This limitation is present since 1.0. Lift the 150 character limit on node names -- Key: OAK-2644 URL: https://issues.apache.org/jira/browse/OAK-2644 Project: Jackrabbit Oak Issue Type: Improvement Components: mongomk, rdbmk Affects Versions: 1.0 Reporter: Felix Meschberger Currently -- as of Oak 1.1.7 and 1.0.12 releases -- there is a limit on the length of 150 characters for item names in Oak. This limit seems to be based upon a limitation in the MongoDB MK implementation because MongoDB has a limit of 1024 bytes (I think) for indexable properties. I think this limitation is highly unexpected and seems to be largeyl undocumented. For previous users of Jackrabbit it should probably at least be documented on the [Backwards Compatibility|http://jackrabbit.apache.org/oak/docs/differences.html] page. The main problem, though, I have with this limit is, that it is based on a limitation of a particular MK implementation and hits through the full stack. I would have rather expected such a persistence limitation to be fully hidden and handled inside the MK implementation. Granted this limitation does not seem to violate the JCR 2.1 specification which clearly states in section 3.2.4 Naming Restrictions: bq. This definition of JCR name represents the least restrictive set of constraints permitted for the naming of items and other entities. A repository may further restrict the names of entities to a subset of JCR names and in most cases is encouraged to do so. and bq. A writable repository may enforce any implementation-specific constraint by causing an exception to be thrown on an invalid JCR write method call. Still I think it is a questionable limitation for a generic repository where such names may be auto-generated and thus be quite long depending on the use case. I understand this may be hard to fix but would still be happy to be able to have (virtually) unlimited name length again as it was the case in Jackrabbit 2. Thanks. See also OAK-333 for a previous discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[
https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366926#comment-14366926
]
Michael Dürig commented on OAK-2476:
Update on where we stand (build 24 \[1]):
* 3 builds failing because of the problem with the {{geronimo-jta_1.0.1B_spec}}
dependency reported earlier. Tommaso followed up on builds@.
* 5 builds timed out after 50mins. These where all Windows builds. All other
Windows builds failed because of test failures before the 50mins. timeout. -
Increased the timeout to 90mins.
* 1 build (pedantic) failed because of a missing license. Added the license.
* *20!* builds fail because of test failures. Will follow up separately on
this.
\[1] https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/24/
Move our CI to Jenkins
--
Key: OAK-2476
URL: https://issues.apache.org/jira/browse/OAK-2476
Project: Jackrabbit Oak
Issue Type: Task
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Critical
Labels: CI, build, infrastructure
Fix For: 1.2
We should strive for stabilization of our CI setup, as of now we had Buildbot
and Travis.
It seems ASF Jenkins can perform jobs on different environments (*nix,
Windows and others) so we can evaluate that and check if it better address
our needs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2628) RDB: convenience tool for dumping table creation statements
[ https://issues.apache.org/jira/browse/OAK-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-2628. - Resolution: Fixed RDB: convenience tool for dumping table creation statements --- Key: OAK-2628 URL: https://issues.apache.org/jira/browse/OAK-2628 Project: Jackrabbit Oak Issue Type: Sub-task Components: rdbmk Affects Versions: 1.0.12, 1.1.7 Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.1.8, 1.0.13 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2642) DocumentNodeStore.dispose() may leave repository in an inconsistent state
[ https://issues.apache.org/jira/browse/OAK-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-2642. --- Resolution: Fixed Fixed in trunk: http://svn.apache.org/r1667498 DocumentNodeStore.dispose() may leave repository in an inconsistent state - Key: OAK-2642 URL: https://issues.apache.org/jira/browse/OAK-2642 Project: Jackrabbit Oak Issue Type: Bug Components: core, mongomk Affects Versions: 1.0 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Critical Fix For: 1.1.8 The repository may become inconsistent when a commit happens while the DocumentNodeStore is disposed. The node store writes back pending _lastRevs and then unset the active flag in the clusterNodes collection. It is possible a commit gets through even after the _lastRevs had been updated and the active flag is cleared. This means the missing _lastRev updates will not be recovered on a restart or by another cluster node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-1881) support RDB in oak-run benchmarks
[ https://issues.apache.org/jira/browse/OAK-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-1881. - Resolution: Fixed Fix Version/s: (was: 1.2) 1.0.12 1.1.7 support RDB in oak-run benchmarks - Key: OAK-1881 URL: https://issues.apache.org/jira/browse/OAK-1881 Project: Jackrabbit Oak Issue Type: Sub-task Components: run Affects Versions: 1.1.0 Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 1.1.7, 1.0.12 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2648) ObservationTest.observationDispose() restarts repository after test finished
[ https://issues.apache.org/jira/browse/OAK-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2648: -- Fix Version/s: 1.0.13 Merged into 1.0 branch: http://svn.apache.org/r1667504 ObservationTest.observationDispose() restarts repository after test finished Key: OAK-2648 URL: https://issues.apache.org/jira/browse/OAK-2648 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.0.12, 1.1.7 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor Fix For: 1.1.8, 1.0.13 The test schedules a tasks at a fixed delay, which calls getNode(TEST_PATH). The task is not canceled at the end of the test. This means the task is still running after the test ends and will start a new repository at some point. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2644) Lift the 150 character limit on item names
[ https://issues.apache.org/jira/browse/OAK-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366800#comment-14366800 ] Thomas Mueller commented on OAK-2644: - The problem is node names. The limit on property names is much higher (for MongoDB, the maximum BSON document size is 16 megabytes). According to http://docs.mongodb.org/manual/reference/limits , the limit for a shard key is 512 bytes. If sharding is not used, the limit is 1024 bytes. Lift the 150 character limit on item names -- Key: OAK-2644 URL: https://issues.apache.org/jira/browse/OAK-2644 Project: Jackrabbit Oak Issue Type: Wish Components: mongomk, rdbmk Affects Versions: 1.0.12, 1.1.7 Reporter: Felix Meschberger Currently -- as of Oak 1.1.7 and 1.0.12 releases -- there is a limit on the length of 150 characters for item names in Oak. This limit seems to be based upon a limitation in the MongoDB MK implementation because MongoDB has a limit of 1024 bytes (I think) for indexable properties. I think this limitation is highly unexpected and seems to be largeyl undocumented. For previous users of Jackrabbit it should probably at least be documented on the [Backwards Compatibility|http://jackrabbit.apache.org/oak/docs/differences.html] page. The main problem, though, I have with this limit is, that it is based on a limitation of a particular MK implementation and hits through the full stack. I would have rather expected such a persistence limitation to be fully hidden and handled inside the MK implementation. Granted this limitation does not seem to violate the JCR 2.1 specification which clearly states in section 3.2.4 Naming Restrictions: bq. This definition of JCR name represents the least restrictive set of constraints permitted for the naming of items and other entities. A repository may further restrict the names of entities to a subset of JCR names and in most cases is encouraged to do so. and bq. A writable repository may enforce any implementation-specific constraint by causing an exception to be thrown on an invalid JCR write method call. Still I think it is a questionable limitation for a generic repository where such names may be auto-generated and thus be quite long depending on the use case. I understand this may be hard to fix but would still be happy to be able to have (virtually) unlimited name length again as it was the case in Jackrabbit 2. Thanks. See also OAK-333 for a previous discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2644) Lift the 150 character limit on node names
[ https://issues.apache.org/jira/browse/OAK-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-2644: Summary: Lift the 150 character limit on node names (was: Lift the 150 character limit on item names) Lift the 150 character limit on node names -- Key: OAK-2644 URL: https://issues.apache.org/jira/browse/OAK-2644 Project: Jackrabbit Oak Issue Type: Wish Components: mongomk, rdbmk Affects Versions: 1.0.12, 1.1.7 Reporter: Felix Meschberger Currently -- as of Oak 1.1.7 and 1.0.12 releases -- there is a limit on the length of 150 characters for item names in Oak. This limit seems to be based upon a limitation in the MongoDB MK implementation because MongoDB has a limit of 1024 bytes (I think) for indexable properties. I think this limitation is highly unexpected and seems to be largeyl undocumented. For previous users of Jackrabbit it should probably at least be documented on the [Backwards Compatibility|http://jackrabbit.apache.org/oak/docs/differences.html] page. The main problem, though, I have with this limit is, that it is based on a limitation of a particular MK implementation and hits through the full stack. I would have rather expected such a persistence limitation to be fully hidden and handled inside the MK implementation. Granted this limitation does not seem to violate the JCR 2.1 specification which clearly states in section 3.2.4 Naming Restrictions: bq. This definition of JCR name represents the least restrictive set of constraints permitted for the naming of items and other entities. A repository may further restrict the names of entities to a subset of JCR names and in most cases is encouraged to do so. and bq. A writable repository may enforce any implementation-specific constraint by causing an exception to be thrown on an invalid JCR write method call. Still I think it is a questionable limitation for a generic repository where such names may be auto-generated and thus be quite long depending on the use case. I understand this may be hard to fix but would still be happy to be able to have (virtually) unlimited name length again as it was the case in Jackrabbit 2. Thanks. See also OAK-333 for a previous discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1832) RdbDocumentStore's create should batch more inserts
[ https://issues.apache.org/jira/browse/OAK-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-1832: Fix Version/s: (was: 1.2) 1.0.12 1.1.7 RdbDocumentStore's create should batch more inserts --- Key: OAK-1832 URL: https://issues.apache.org/jira/browse/OAK-1832 Project: Jackrabbit Oak Issue Type: Sub-task Components: rdbmk Affects Versions: 1.1.0 Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.0.12, 1.1.7 check whether doing more inserts in a single commit will improve performance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1832) RdbDocumentStore's create should batch more inserts
[ https://issues.apache.org/jira/browse/OAK-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-1832: Component/s: (was: mongomk) rdbmk RdbDocumentStore's create should batch more inserts --- Key: OAK-1832 URL: https://issues.apache.org/jira/browse/OAK-1832 Project: Jackrabbit Oak Issue Type: Sub-task Components: rdbmk Affects Versions: 1.1.0 Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.0.12, 1.1.7 check whether doing more inserts in a single commit will improve performance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-1913) RDB: MariaDB (MySQL) support
[ https://issues.apache.org/jira/browse/OAK-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-1913. - Resolution: Fixed Fix Version/s: (was: 1.2) 1.0.12 1.1.7 RDB: MariaDB (MySQL) support Key: OAK-1913 URL: https://issues.apache.org/jira/browse/OAK-1913 Project: Jackrabbit Oak Issue Type: Sub-task Components: rdbmk Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.1.7, 1.0.12 Attachments: OAK-1913-v2.patch, OAK-1913.patch, my.ini -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-1914) RDB: Oracle support
[ https://issues.apache.org/jira/browse/OAK-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-1914. - Resolution: Fixed Fix Version/s: (was: 1.2) 1.0.12 1.1.7 Support for Oracle 12 appears to work. Earlier versions are not supported for now. RDB: Oracle support --- Key: OAK-1914 URL: https://issues.apache.org/jira/browse/OAK-1914 Project: Jackrabbit Oak Issue Type: Sub-task Components: rdbmk Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.1.7, 1.0.12 Attachments: OAK-1914.patch, insert2.log, oak_20150127.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-1832) RdbDocumentStore's create should batch more inserts
[ https://issues.apache.org/jira/browse/OAK-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-1832. - Resolution: Fixed The implementation has been chunking inserts for quite some time. RdbDocumentStore's create should batch more inserts --- Key: OAK-1832 URL: https://issues.apache.org/jira/browse/OAK-1832 Project: Jackrabbit Oak Issue Type: Sub-task Components: rdbmk Affects Versions: 1.1.0 Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.1.7, 1.0.12 check whether doing more inserts in a single commit will improve performance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2647) QueryBuilder.setSelector(Authorizable.class) only returns Groups when using Java 1.8
Ben Helleman created OAK-2647: - Summary: QueryBuilder.setSelector(Authorizable.class) only returns Groups when using Java 1.8 Key: OAK-2647 URL: https://issues.apache.org/jira/browse/OAK-2647 Project: Jackrabbit Oak Issue Type: Bug Components: query Affects Versions: 1.1.7 Environment: Java 1.8 Reporter: Ben Helleman Using org.apache.jackrabbit.api.security.user.QueryBuilder.setSelector(Authorizable.class) the docs state that it should return both Groups and Users, however when using Java 1.8, only Groups are returned. Using Java 1.7, setSelector(Authorizable.class) works as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2648) ObservationTest.observationDispose() restarts repository after test finished
Marcel Reutegger created OAK-2648: - Summary: ObservationTest.observationDispose() restarts repository after test finished Key: OAK-2648 URL: https://issues.apache.org/jira/browse/OAK-2648 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.1.7, 1.0.12 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor The test schedules a tasks at a fixed delay, which calls getNode(TEST_PATH). The task is not canceled at the end of the test. This means the task is still running after the test ends and will start a new repository at some point. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2644) Lift the 150 character limit on node names
[ https://issues.apache.org/jira/browse/OAK-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366818#comment-14366818 ] Felix Meschberger commented on OAK-2644: bq. The problem is node names. The limit on property names is much higher Thanks for the clarification. And yes, roughly 15MB for a property name is probably sufficient ;-) Lift the 150 character limit on node names -- Key: OAK-2644 URL: https://issues.apache.org/jira/browse/OAK-2644 Project: Jackrabbit Oak Issue Type: Wish Components: mongomk, rdbmk Affects Versions: 1.0.12, 1.1.7 Reporter: Felix Meschberger Currently -- as of Oak 1.1.7 and 1.0.12 releases -- there is a limit on the length of 150 characters for item names in Oak. This limit seems to be based upon a limitation in the MongoDB MK implementation because MongoDB has a limit of 1024 bytes (I think) for indexable properties. I think this limitation is highly unexpected and seems to be largeyl undocumented. For previous users of Jackrabbit it should probably at least be documented on the [Backwards Compatibility|http://jackrabbit.apache.org/oak/docs/differences.html] page. The main problem, though, I have with this limit is, that it is based on a limitation of a particular MK implementation and hits through the full stack. I would have rather expected such a persistence limitation to be fully hidden and handled inside the MK implementation. Granted this limitation does not seem to violate the JCR 2.1 specification which clearly states in section 3.2.4 Naming Restrictions: bq. This definition of JCR name represents the least restrictive set of constraints permitted for the naming of items and other entities. A repository may further restrict the names of entities to a subset of JCR names and in most cases is encouraged to do so. and bq. A writable repository may enforce any implementation-specific constraint by causing an exception to be thrown on an invalid JCR write method call. Still I think it is a questionable limitation for a generic repository where such names may be auto-generated and thus be quite long depending on the use case. I understand this may be hard to fix but would still be happy to be able to have (virtually) unlimited name length again as it was the case in Jackrabbit 2. Thanks. See also OAK-333 for a previous discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2647) QueryBuilder.setSelector(Authorizable.class) only returns Groups when using Java 1.8
[ https://issues.apache.org/jira/browse/OAK-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-2647: Component/s: core QueryBuilder.setSelector(Authorizable.class) only returns Groups when using Java 1.8 Key: OAK-2647 URL: https://issues.apache.org/jira/browse/OAK-2647 Project: Jackrabbit Oak Issue Type: Bug Components: core, query Affects Versions: 1.1.7 Environment: Java 1.8 Reporter: Ben Helleman Using org.apache.jackrabbit.api.security.user.QueryBuilder.setSelector(Authorizable.class) the docs state that it should return both Groups and Users, however when using Java 1.8, only Groups are returned. Using Java 1.7, setSelector(Authorizable.class) works as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-2647) QueryBuilder.setSelector(Authorizable.class) only returns Groups when using Java 1.8
[ https://issues.apache.org/jira/browse/OAK-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reassigned OAK-2647: --- Assignee: angela QueryBuilder.setSelector(Authorizable.class) only returns Groups when using Java 1.8 Key: OAK-2647 URL: https://issues.apache.org/jira/browse/OAK-2647 Project: Jackrabbit Oak Issue Type: Bug Components: core, query Affects Versions: 1.1.7 Environment: Java 1.8 Reporter: Ben Helleman Assignee: angela Using org.apache.jackrabbit.api.security.user.QueryBuilder.setSelector(Authorizable.class) the docs state that it should return both Groups and Users, however when using Java 1.8, only Groups are returned. Using Java 1.7, setSelector(Authorizable.class) works as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367122#comment-14367122 ] Davide Giannella commented on OAK-2476: --- that's great. It shows it's working and I find it easier to read than the travis. It seems to me we're getting to a stable situation with the build. Didn't look at the details of test failures. Move our CI to Jenkins -- Key: OAK-2476 URL: https://issues.apache.org/jira/browse/OAK-2476 Project: Jackrabbit Oak Issue Type: Task Reporter: Tommaso Teofili Assignee: Tommaso Teofili Priority: Critical Labels: CI, build, infrastructure Fix For: 1.2 We should strive for stabilization of our CI setup, as of now we had Buildbot and Travis. It seems ASF Jenkins can perform jobs on different environments (*nix, Windows and others) so we can evaluate that and check if it better address our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2642) DocumentNodeStore.dispose() may leave repository in an inconsistent state
[ https://issues.apache.org/jira/browse/OAK-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2642: -- Fix Version/s: 1.0.13 Merged into 1.0 branch: http://svn.apache.org/r1667543 DocumentNodeStore.dispose() may leave repository in an inconsistent state - Key: OAK-2642 URL: https://issues.apache.org/jira/browse/OAK-2642 Project: Jackrabbit Oak Issue Type: Bug Components: core, mongomk Affects Versions: 1.0 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Critical Fix For: 1.1.8, 1.0.13 The repository may become inconsistent when a commit happens while the DocumentNodeStore is disposed. The node store writes back pending _lastRevs and then unset the active flag in the clusterNodes collection. It is possible a commit gets through even after the _lastRevs had been updated and the active flag is cleared. This means the missing _lastRev updates will not be recovered on a restart or by another cluster node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1589) MongoDocumentStore fails to report error for keys that are too long
[ https://issues.apache.org/jira/browse/OAK-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-1589: Fix Version/s: (was: 1.3.0) 1.1.8 MongoDocumentStore fails to report error for keys that are too long --- Key: OAK-1589 URL: https://issues.apache.org/jira/browse/OAK-1589 Project: Jackrabbit Oak Issue Type: Bug Components: mongomk Reporter: Julian Reschke Fix For: 1.1.8 The MongoDocumentStore fails to report an error when the key length exceeds the allowable width in MongoDB. This can be fixed by using a newer version of MongoDB (mongodb 2.5.5 -- see https://jira.mongodb.org/browse/SERVER-5290) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-1589) MongoDocumentStore fails to report error for keys that are too long
[ https://issues.apache.org/jira/browse/OAK-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke reassigned OAK-1589: --- Assignee: Julian Reschke MongoDocumentStore fails to report error for keys that are too long --- Key: OAK-1589 URL: https://issues.apache.org/jira/browse/OAK-1589 Project: Jackrabbit Oak Issue Type: Bug Components: mongomk Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 1.1.8 The MongoDocumentStore fails to report an error when the key length exceeds the allowable width in MongoDB. This can be fixed by using a newer version of MongoDB (mongodb 2.5.5 -- see https://jira.mongodb.org/browse/SERVER-5290) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2619) Support merging content during upgrade
[ https://issues.apache.org/jira/browse/OAK-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367363#comment-14367363 ] Julian Sedding commented on OAK-2619: - Note: I'm currently working on refining this. I will provide a new patch within a week. Support merging content during upgrade -- Key: OAK-2619 URL: https://issues.apache.org/jira/browse/OAK-2619 Project: Jackrabbit Oak Issue Type: New Feature Components: upgrade Affects Versions: 1.1.7 Reporter: Julian Sedding Priority: Minor Attachments: OAK-2619-patch When upgrading from Jackrabbit 2 to Oak there are several scenarios that could benefit from the ability to merge content rather than overwrite it. Especially in combination with OAK-2586, i.e. support to include/exclude selected paths from the copy operation, merging can become very useful. # Start vanilla product with an empty repo that writes some initial content, then copy content from a Jackrabbit 2 repo into this instance # Unify content from several Jackrabbit 2 repositories into a single Oak repo # Copy all content 1 week before the actual migration, then merge in the diff on migration day -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367369#comment-14367369 ] Michael Dürig commented on OAK-2476: The most [recent build | https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/27/] didn't reveal any new platform problems. Increasing the time out helped the windows builds and the pedantic build works now. With 6h the build takes IMO to long though. And that time will likely go up once builds stop failing prematurely. As the Ubuntu builds where done within roughly 2h and the rest of the time was spent with the Windows builds, an option would be to split the Matrix into 2 jobs, one for Ubuntu and one for Windows. WDYT? Move our CI to Jenkins -- Key: OAK-2476 URL: https://issues.apache.org/jira/browse/OAK-2476 Project: Jackrabbit Oak Issue Type: Task Reporter: Tommaso Teofili Assignee: Tommaso Teofili Priority: Critical Labels: CI, build, infrastructure Fix For: 1.2 We should strive for stabilization of our CI setup, as of now we had Buildbot and Travis. It seems ASF Jenkins can perform jobs on different environments (*nix, Windows and others) so we can evaluate that and check if it better address our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1589) MongoDocumentStore fails to report error for keys that are too long
[ https://issues.apache.org/jira/browse/OAK-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-1589: Fix Version/s: 1.0.13 MongoDocumentStore fails to report error for keys that are too long --- Key: OAK-1589 URL: https://issues.apache.org/jira/browse/OAK-1589 Project: Jackrabbit Oak Issue Type: Bug Components: mongomk Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 1.1.8, 1.0.13 The MongoDocumentStore fails to report an error when the key length exceeds the allowable width in MongoDB. This can be fixed by using a newer version of MongoDB (mongodb 2.5.5 -- see https://jira.mongodb.org/browse/SERVER-5290) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2647) QueryBuilder.setSelector(Authorizable.class) only returns Groups when using Java 1.8
[
https://issues.apache.org/jira/browse/OAK-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367348#comment-14367348
]
angela commented on OAK-2647:
-
[~bhellema], i extracted the following test case (basically a duplicate of
{{testSelector}} in the
{{org.apache.jackrabbit.oak.jcr.security.user.UserQueryTest}}:
{code}
/**
* @see a
href=https://issues.apache.org/jira/browse/OAK-2647;OAK-2647/a
*/
@Test
public void testAuthorizableSelector() throws RepositoryException {
IteratorAuthorizable result = userMgr.findAuthorizables(new Query() {
public T void build(QueryBuilderT builder) {
builder.setSelector(Authorizable.class);
}
});
assertSameElements(result, authorizables.iterator());
}
{code}
so far i couldn't reproduce the issue. having a quick chat with [~mduerig], we
also looked at the new jenkins build at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ which didn't
reveal any failure for {{UserQueryTest#testSelector}} on Java 1.8.
maybe you can provide more info or a test-case that allows me to reproduce the
problem? thanks
QueryBuilder.setSelector(Authorizable.class) only returns Groups when using
Java 1.8
Key: OAK-2647
URL: https://issues.apache.org/jira/browse/OAK-2647
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, query
Affects Versions: 1.1.7
Environment: Java 1.8
Reporter: Ben Helleman
Assignee: angela
Using
org.apache.jackrabbit.api.security.user.QueryBuilder.setSelector(Authorizable.class)
the docs state that it should return both Groups and Users, however when
using Java 1.8, only Groups are returned.
Using Java 1.7, setSelector(Authorizable.class) works as expected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-1589) MongoDocumentStore fails to report error for keys that are too long
[ https://issues.apache.org/jira/browse/OAK-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-1589. - Resolution: Fixed Tests pass with Mongo 2.6. Re-enabled tests. MongoDocumentStore fails to report error for keys that are too long --- Key: OAK-1589 URL: https://issues.apache.org/jira/browse/OAK-1589 Project: Jackrabbit Oak Issue Type: Bug Components: mongomk Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 1.1.8, 1.0.13 The MongoDocumentStore fails to report an error when the key length exceeds the allowable width in MongoDB. This can be fixed by using a newer version of MongoDB (mongodb 2.5.5 -- see https://jira.mongodb.org/browse/SERVER-5290) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2586) Support including and excluding paths during upgrade
[ https://issues.apache.org/jira/browse/OAK-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367364#comment-14367364 ] Julian Sedding commented on OAK-2586: - Note: I'm currently working on refining this. I will provide a new patch within a week. Support including and excluding paths during upgrade Key: OAK-2586 URL: https://issues.apache.org/jira/browse/OAK-2586 Project: Jackrabbit Oak Issue Type: Improvement Components: upgrade Affects Versions: 1.1.6 Reporter: Julian Sedding Labels: patch Attachments: OAK-2586.patch When upgrading a Jackrabbit 2 to an Oak repository it can be desirable to constrain which paths/sub-trees should be copied from the source repository. Not least because this can (drastically) reduce the amount of content that needs to be traversed, copied and indexed. I suggest to allow filtering the content visible from the source repository by wrapping the JackrabbitNodeState instance and hiding selected paths. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2420) DocumentNodeStore revision GC may lead to NPE
[
https://issues.apache.org/jira/browse/OAK-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367479#comment-14367479
]
Marcel Reutegger commented on OAK-2420:
---
Added a test (currently ignored): http://svn.apache.org/r1667590
DocumentNodeStore revision GC may lead to NPE
-
Key: OAK-2420
URL: https://issues.apache.org/jira/browse/OAK-2420
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 1.0
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Priority: Minor
Fix For: 1.1.9
The DocumentNodeStore revision GC may cause a NPE in a reader thread when the
GC deletes documents currently accessed by the reader. The
{{docChildrenCache}} is invalidated in
{{VersionGarbageCollector.collectDeletedDocuments()}} after documents are
removed in the DocumentStore. The NPE may occur if removed documents are
access in between.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[
https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14367507#comment-14367507
]
Davide Giannella commented on OAK-2476:
---
[~mduerig]
{quote}
As the Ubuntu builds where done within roughly 2h and the rest of the time was
spent with the Windows builds, an option would be to split the Matrix into 2
jobs, one for Ubuntu and one for Windows. WDYT?
{quote}
I thought we already had two separate jobs one for each platform. +1 otherwise
for the split.
Another check, as I don't know how to do it, do the various IT profiles ship
the variable {{-Dsurefire.skip.ut=true}}? The IT profile was instructed to not
run UT if such settings is passed into. Useful as we already run all the unit
test in a separate profile.
Move our CI to Jenkins
--
Key: OAK-2476
URL: https://issues.apache.org/jira/browse/OAK-2476
Project: Jackrabbit Oak
Issue Type: Task
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Critical
Labels: CI, build, infrastructure
Fix For: 1.2
We should strive for stabilization of our CI setup, as of now we had Buildbot
and Travis.
It seems ASF Jenkins can perform jobs on different environments (*nix,
Windows and others) so we can evaluate that and check if it better address
our needs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2646) Look for alternative cache invalidation logic for better performance
[
https://issues.apache.org/jira/browse/OAK-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366744#comment-14366744
]
Julian Reschke commented on OAK-2646:
-
Just for the record: the RDBDocumentStore simply marks all cache entries as
to-be-revalidated; next time they are used, the modcount in the DB is
verified.
Look for alternative cache invalidation logic for better performance
Key: OAK-2646
URL: https://issues.apache.org/jira/browse/OAK-2646
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mongomk
Reporter: Chetan Mehrotra
Fix For: 1.2
Current cache invalidation logic has a higher cost. For e.g. in one of the
deployment following log was seen
{noformat}
12.03.2015 09:24:25.579 *INFO* [DocumentNodeStore background thread]
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore Background
operations stats (clean:0, split:0, write:0, read:11848
ReadStats{cacheStats:InvalidationResult{invalidationCount=4,
upToDateCount=286761, cacheSize=300411, timeTaken=10589, queryCount=654,
cacheEntriesProcessedCount=138633}, head:1, cache:11842, dispatch:5, purge:0}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2476) Move our CI to Jenkins
[ https://issues.apache.org/jira/browse/OAK-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14368141#comment-14368141 ] Michael Dürig commented on OAK-2476: Thanks for the pointer. UTs are now skipped: https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/29/ Move our CI to Jenkins -- Key: OAK-2476 URL: https://issues.apache.org/jira/browse/OAK-2476 Project: Jackrabbit Oak Issue Type: Task Reporter: Tommaso Teofili Assignee: Tommaso Teofili Priority: Critical Labels: CI, build, infrastructure Fix For: 1.2 We should strive for stabilization of our CI setup, as of now we had Buildbot and Travis. It seems ASF Jenkins can perform jobs on different environments (*nix, Windows and others) so we can evaluate that and check if it better address our needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
