[jira] [Commented] (OAK-3388) Inconsistent read in cluster with clock differences
[ https://issues.apache.org/jira/browse/OAK-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747144#comment-14747144 ] Marcel Reutegger commented on OAK-3388: --- I think there is a more fundamental problem with the current use of RevisionComparator and how revisions are compared across cluster nodes. Changes from other cluster nodes are made visible in a bulk operation by adding the _lastRev on the root document of another cluster to the RevisionComparator at a given 'seenAt' revision. This 'seenAt' revision is the same for all new _lastRevs seen from other cluster nodes. The problem now is when two revisions from other cluster nodes are compared and they have the same 'seenAt' revision. The RevisionComparator will simply decide which revision comes first based on the clusterId. Assume we have three cluster nodes A, B and C with clusterIds 1, 2 and 3 respectively. Cluster A does not write, but simply observes changes done by B and C. Consider the following sequence of events: - C adds a node N to the repository - C runs background operations - B runs background operations and sees N - B removes N - B runs background operations - A runs background operations To A changes done by B and C will have the same 'seenAt' revision and the RevisionComparator will decide based on the clusterId. The comparator will tell the change done by B (removing the node) happend before the change done by C (adding the node), because B has a lower clusterId than C. This issue only had a minor impact so far because NodeDocument.getNodeAtRevision() uses a StableRevisionComparator when it goes through the revisions of a property. It only uses the RevisionComparator to decide if a change is visible or not based on a given read revision. In my view there are multiple issue to solve: - The RevisionComparator mechanism to make multiple external changes visible at a given seenAt revision is fragile because the comparison is only based on the clusterId. Taken to the extreme it means an old revision made visible via a background read or on startup may be considered newer than a current revision, just because the clusterId is higher. - The RevisionComparator allows time shifting. That is, the implementation tries to accommodate clock differences on cluster nodes and puts revisions in proper sequence as they were made visible. However, it only remembers this sequence for a one hour time frame. Older revisions are compared only based on the revision timestamp. This make the comparison unstable over time. While the comparator may say a revision R1 happened before R2 while in the one hour time frame, the comparison may later tell the opposite. I see the following solution to these problems: - Prevent changes that happen in the past (by just looking at the revision timestamp). This is what the ignored tests added in this issue do. Due to clock differences a subsequent change has a lower revision timestamp. This is currently allowed because the RevisionComparator accommodates this difference, but it only works reliably within a one hour timeframe. - Detect clock differences in the background read operation. The background read operation must only make external changes visible that have a lower timestamp than the local clock. This is similar to the first item. - The RevisionComparator always uses the revision timestamp to compare revisions, unless a revision is not yet visible. > Inconsistent read in cluster with clock differences > --- > > Key: OAK-3388 > URL: https://issues.apache.org/jira/browse/OAK-3388 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Affects Versions: 1.0, 1.2 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.3.7 > > > This issue is similar to OAK-2929 but related to how the DocumentNodeStore > reads a node state when there is a clock difference between multiple cluster > nodes. The node state read from a NodeDocument may not be correct when there > is a clock difference. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (OAK-3201) Use static references in SecurityProviderImpl for composite services
[
https://issues.apache.org/jira/browse/OAK-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-3201:
Comment: was deleted
(was: I'm also wondering if explicit synchronization could be removed from the
"bind" and "unbind" methods. The state-changing actions performed by those
methods are:
- add a service to or remove a service from the list of referenced services;
- add a candidate to or remove a candidate from the list of prerequisites;
- maybe activate or deactivate the {{SecurityProvider}}.
Given that the last operation is a no-op if the prerequisites are not
satisfied, only the last step should be properly synchronized. [~chetanm], what
do you think?)
> Use static references in SecurityProviderImpl for composite services
>
>
> Key: OAK-3201
> URL: https://issues.apache.org/jira/browse/OAK-3201
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.3.7
>
> Attachments: OAK-3201-01.patch, OAK-3201-02.patch, OAK-3201-03.patch,
> OAK-3201-04.patch, OAK-3201-05.patch, OAK-3201-06.patch, OAK-3201-07.patch,
> mbean-test.log
>
>
> {{SecurityProviderImpl}} has dynamic references to many other services, like
> {{RestrictionProvider}}, that represent the configuration of this component.
> Being these services dynamic, the OSGi runtime has no clear dependency
> relationship between the {{SecurityProviderImpl}} and the required services.
> Thus, it may happen that an instance of {{SecurityProviderImpl}} is published
> before the services it requires are started, creating a window where the
> {{SecurityProviderimpl}} is operating differently from the way it's
> configured.
> I suggest to turn the dynamic references in {{SecurityProviderImpl}} to
> static ones to improve the consistency of the implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3395) RevisionGC fails for JCR paths having line feed characters
[
https://issues.apache.org/jira/browse/OAK-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3395:
-
Attachment: OAK-3395-2.patch
Thanks Thomas for the extensive review!
Attached is [updated patch|^OAK-3395-2.patch]
bq. by the way, even now an exception is throws if the last character if a
backslash
In previous case that was handled as {{unescapingRequired}} had a check to
ensure that any '\' found is at least second last character in the string. So
the out of bound access in unescape would not happen. However your suggestion
on simplifying {{unescapingRequired}} looks better so now added a check there
bq. There should be unit tests for the special cases as well (code coverage
should be 100%).
Done now
In addition I have now used {{RandomStringUtils}} from commons lang (test
scoped dep) as the logic you suggested might not generate valid unicode chars.
Commons Lang util ensure that proper unicode chars would be generated
Further about my concern
bq. I am not very sure if escaping as implemented would work fine for unicode
chars (involving surrogate pair i.e. those not in BMP)
I checked the docs [1] and it mentions following
{quote}
...if an application scans a char sequence for HTML tags, checking each char
individually, it knows that these tags only use characters from the Basic Latin
block. If the text being scanned contains supplementary characters, then these
characters cannot be confused with the tag characters, because UTF-16
represents supplementary characters using code units whose values are not used
for BMP characters.
{quote}
So it confirms that char by char processing approach used would work fine as
char being search are from ASCII set and in case of surrogate pair (using 2
chars) its not possible for first char to have values from ASCII (or more
broader BMP range).
[1] http://www.oracle.com/us/technologies/java/supplementary-142654.html
> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.7, 1.2.6, 1.0.21
>
> Attachments: OAK-3395-1.patch, OAK-3395-2.patch
>
>
> RevisionGC fails with error while processing any id (derived from JCR path)
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort
> which works with line delimited string and having an id with line break would
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
> at
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
> at
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
> at
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
> at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
> at java.util.TimSort.sort(TimSort.java:203)
> at java.util.TimSort.sort(TimSort.java:173)
> at java.util.Arrays.sort(Arrays.java:659)
> at java.util.Collections.sort(Collections.java:217)
> at
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
> at
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
> at
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
> at
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
> at
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
> at
>
[jira] [Commented] (OAK-3395) RevisionGC fails for JCR paths having line feed characters
[
https://issues.apache.org/jira/browse/OAK-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747175#comment-14747175
]
Thomas Mueller commented on OAK-3395:
-
Other than that, it looks good to me.
As for ExternalSort, some cleanup and more tests would be good, for example
there are unused methods, methods that use the default locale (which is
problematic; I would probably force specifying the character set), weird
identifier names (DEFAULTMAXTEMPFILES, filetobesorted), line breaks. Code
coverage of the tests is not that great. But that could be done in a separate
issue.
> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.7, 1.2.6, 1.0.21
>
> Attachments: OAK-3395-1.patch
>
>
> RevisionGC fails with error while processing any id (derived from JCR path)
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort
> which works with line delimited string and having an id with line break would
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
> at
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
> at
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
> at
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
> at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
> at java.util.TimSort.sort(TimSort.java:203)
> at java.util.TimSort.sort(TimSort.java:173)
> at java.util.Arrays.sort(Arrays.java:659)
> at java.util.Collections.sort(Collections.java:217)
> at
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
> at
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
> at
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
> at
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
> at
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
[
https://issues.apache.org/jira/browse/OAK-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-3396:
-
Attachment: OAK-3396.patch.v2
Attached [^OAK-3396.patch.v2] that fixes both createUser and createGroups with
the correct result code, plus it contains a testListUsersWithMissingUid which
tests the createUser case. Note that it also fiddles with the pom.xml, but that
is just to be able to patch based on an oak 1.0.18 (and not meant to go into
svn obviously)
[~tripod], I could not readily find a solution how to test the createGroups
case: when importing a 'faulty' ldif without 'cn' the import already fails...
if you have any idea how to test the createGroups case that would be great
> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Minor
> Fix For: 1.0.20
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been
> encountered. This likely indicates that - for a particular user - there is no
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3201) Use static references in SecurityProviderImpl for composite services
[
https://issues.apache.org/jira/browse/OAK-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-3201:
Attachment: OAK-3201-08.patch
[~chetanm], I implemented the changes we discussed offline in
[^OAK-3201-08.patch]. Please review.
> Use static references in SecurityProviderImpl for composite services
>
>
> Key: OAK-3201
> URL: https://issues.apache.org/jira/browse/OAK-3201
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.3.7
>
> Attachments: OAK-3201-01.patch, OAK-3201-02.patch, OAK-3201-03.patch,
> OAK-3201-04.patch, OAK-3201-05.patch, OAK-3201-06.patch, OAK-3201-07.patch,
> OAK-3201-08.patch, mbean-test.log
>
>
> {{SecurityProviderImpl}} has dynamic references to many other services, like
> {{RestrictionProvider}}, that represent the configuration of this component.
> Being these services dynamic, the OSGi runtime has no clear dependency
> relationship between the {{SecurityProviderImpl}} and the required services.
> Thus, it may happen that an instance of {{SecurityProviderImpl}} is published
> before the services it requires are started, creating a window where the
> {{SecurityProviderimpl}} is operating differently from the way it's
> configured.
> I suggest to turn the dynamic references in {{SecurityProviderImpl}} to
> static ones to improve the consistency of the implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3394) RDBDocumentStore startup: log more DDL information (incl. index information)
[ https://issues.apache.org/jira/browse/OAK-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3394: Fix Version/s: 1.3.7 > RDBDocumentStore startup: log more DDL information (incl. index information) > > > Key: OAK-3394 > URL: https://issues.apache.org/jira/browse/OAK-3394 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.3.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1744) GQL queries with "jcr:primaryType='x'" don't use the node type index
[ https://issues.apache.org/jira/browse/OAK-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-1744: Fix Version/s: (was: 1.3.7) 1.3.8 > GQL queries with "jcr:primaryType='x'" don't use the node type index > > > Key: OAK-1744 > URL: https://issues.apache.org/jira/browse/OAK-1744 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.3.8 > > > GQL queries (org.apache.jackrabbit.commons.query.GQL) with type restrictions > are converted to the XPath condition "jcr:primaryType = 'x'". This conditions > is not currently interpreted as a regular node type restriction in the query > engine or the node type index, as one would expect. > Such restrictions could still be processed efficiently using the property > index on "jcr:primaryType", but if that one is disabled (by setting the cost > manually very high, as it is done now), then such queries don't use the > expected index. > I'm not sure yet where this should be best fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-3148) Online migration process for the binaries
[
https://issues.apache.org/jira/browse/OAK-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller reassigned OAK-3148:
---
Assignee: Thomas Mueller
> Online migration process for the binaries
> -
>
> Key: OAK-3148
> URL: https://issues.apache.org/jira/browse/OAK-3148
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: blob, upgrade
>Reporter: Tomek Rękawek
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.3.7
>
>
> For clients that want to migrate their blob stores, let's add a new feature
> that allows copy them in the background.
> AC:
> # SplitBlobStore
> ## Administrator can configure Oak to use the {{SplitBlobStore}} that
> references the source (old) and the destination (new) blob store.
> ## Data stores can be used as well via the {{DataStoreBlobStore}}.
> ## On the read operation, if the requested blob exists on the new store,
> SplitBlobStore will return it.
> ## Otherwise, SplitBlobStore will try to read the blob from the old store.
> ## All write requests will be directed to the new blob store.
> # Copy process
> ## Administrator can start, stop and resume the copy process using JMX
> command.
> ## Administrator can see the progress in JMX and logs
> ## The process will read the {{SplitBlobStore}} configuration and copy the
> binaries from source to destination
> ## Once a binary is moved, its reference in the {{NodeStore}} is updated and
> commited.
> ## Only the head revision has to be updated.
> The idea is that after all binaries are copied, the old revisions will be
> gradually removed by the compaction mechanisms and then binaries will be
> removed from the source store by the blob garbage collector. Future
> improvements are possible, eg. to invoke the compaction and GC manually.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3410) RDB*Store diagnostics: strip line feeds from product information
Julian Reschke created OAK-3410: --- Summary: RDB*Store diagnostics: strip line feeds from product information Key: OAK-3410 URL: https://issues.apache.org/jira/browse/OAK-3410 Project: Jackrabbit Oak Issue Type: Technical task Components: rdbmk Affects Versions: 1.0.19, 1.3.5, 1.2.4 Reporter: Julian Reschke Assignee: Julian Reschke Priority: Trivial -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3393) NodeStore wrapper implementation
[ https://issues.apache.org/jira/browse/OAK-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-3393: Fix Version/s: 1.4 > NodeStore wrapper implementation > > > Key: OAK-3393 > URL: https://issues.apache.org/jira/browse/OAK-3393 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Thomas Mueller > Fix For: 1.4 > > Attachments: OAK-3393.patch > > > I would like to have a node store wrapper implementation. Initial use cases: > * logging (log all NodeStore API calls, possibly with a filter, to be > analyzed later) > * statistics (counting the number of calls, possibly by path) > * profiling (measuring how long calls take) > Later use cases: > * SegmentStore compaction > * on-the-fly migration from one nodestore to another > * maybe: virtual repository (mounting node stores) > I made a first prototype, and found some problems with the NodeStore API and > the way we have used it in Oak. Repository initialization fails with an > IllegalArgumentException if the NodeBuilder does not extend > MemoryNodeBuilder. Also, I have trouble understanding some of the methods > (for example rebase, merge). I think the NodeStore API is much much harder to > wrap than (for example) the DataStore API. I think we should fix that, to > make Oak more modular. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3410) RDB*Store diagnostics: strip line feeds from product information
[ https://issues.apache.org/jira/browse/OAK-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3410: Fix Version/s: 1.3.7 > RDB*Store diagnostics: strip line feeds from product information > > > Key: OAK-3410 > URL: https://issues.apache.org/jira/browse/OAK-3410 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.4, 1.3.5, 1.0.19 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.3.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1221) Query fails unexpectedly when property conversion is not possible for joins and "in(...)"
[ https://issues.apache.org/jira/browse/OAK-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-1221: Fix Version/s: (was: 1.3.7) 1.3.10 > Query fails unexpectedly when property conversion is not possible for joins > and "in(...)" > - > > Key: OAK-1221 > URL: https://issues.apache.org/jira/browse/OAK-1221 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.3.10 > > > The same as for OAK-1171, however the fix there only solves the problem for > comparisons but not joins and conditions of the form "in(x, y)" (the two > other places where values are converted). > I guess those cases are less common than OAK-1171, but it should be quite > easy to come up with a simple test case. I will try to do that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
[
https://issues.apache.org/jira/browse/OAK-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14768956#comment-14768956
]
Tobias Bocanegra commented on OAK-3396:
---
[~egli] we could import the users and groups normally, but use a different
config for the identifier attribute.
> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Minor
> Fix For: 1.0.20
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been
> encountered. This likely indicates that - for a particular user - there is no
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-321) Deref (jcr:deref) support
[
https://issues.apache.org/jira/browse/OAK-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-321:
---
Fix Version/s: (was: 1.3.7)
1.3.10
> Deref (jcr:deref) support
> -
>
> Key: OAK-321
> URL: https://issues.apache.org/jira/browse/OAK-321
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: jcr, query
>Reporter: Alex Parvulescu
>Assignee: Thomas Mueller
> Labels: CI
> Fix For: 1.3.10
>
>
> Test class DerefTest.
> For now there are just parse exceptions:
> {noformat}
> javax.jcr.query.InvalidQueryException: java.text.ParseException: Query:
> testroot/people/jcr:deref((*)@worksfor, '*'); expected:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3140) DataStore / BlobStore: add a method to pass a "type" when writing
[ https://issues.apache.org/jira/browse/OAK-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-3140: Fix Version/s: (was: 1.3.7) 1.3.8 > DataStore / BlobStore: add a method to pass a "type" when writing > - > > Key: OAK-3140 > URL: https://issues.apache.org/jira/browse/OAK-3140 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: blob >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: performance > Fix For: 1.3.8 > > > Currently, the BlobStore interface has a method "String writeBlob(InputStream > in)". This issue is about adding a new method "String writeBlob(String type, > InputStream in)", for the following reasons (in no particular order): > * Store some binaries (for example Lucene index files) in a different place, > in order to safely and quickly run garbage collection just on those files. > * Store some binaries in a slow, some in a fast storage or location. > * Disable calculating the content hash (de-duplication) for some binaries. > * Store some binaries in a shared storage (for fast cross-repository > copying), and some in local storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3410) RDB*Store diagnostics: strip line feeds from product information
[ https://issues.apache.org/jira/browse/OAK-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3410: Fix Version/s: 1.0.21 1.2.6 > RDB*Store diagnostics: strip line feeds from product information > > > Key: OAK-3410 > URL: https://issues.apache.org/jira/browse/OAK-3410 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.4, 1.3.5, 1.0.19 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.3.7, 1.2.6, 1.0.21 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3411) Inconsistent read on DocumentNodeStore startup
Marcel Reutegger created OAK-3411: - Summary: Inconsistent read on DocumentNodeStore startup Key: OAK-3411 URL: https://issues.apache.org/jira/browse/OAK-3411 Project: Jackrabbit Oak Issue Type: Bug Components: core, mongomk Affects Versions: 1.0.20, 1.3.6, 1.2.5 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Blocker Fix For: 1.3.7, 1.2.6, 1.0.21 This is a regression introduced with OAK-2929. On DocumentNodeStore startup the RevisionComparator of the local instance is initialized with the current _lastRev entries from the other cluster nodes. The external _lastRev entries are 'seenAt' the same revision, which means for those revisions the RevisionComparator will use the clusterId to compare them. This is also described in OAK-3388. OAK-2929 changed the sequence of revisions to check for conflicts from StableRevisionComparator to RevisionComparator. This makes the conflict check susceptible to the RevisionComparison behaviour described in OAK-3388. Commits may be rejected with a conflict, when there isn't really a conflict. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3410) RDB*Store diagnostics: strip line feeds from product information
[ https://issues.apache.org/jira/browse/OAK-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-3410. - Resolution: Fixed > RDB*Store diagnostics: strip line feeds from product information > > > Key: OAK-3410 > URL: https://issues.apache.org/jira/browse/OAK-3410 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.4, 1.3.5, 1.0.19 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.3.7, 1.2.6, 1.0.21 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3394) RDBDocumentStore startup: log more DDL information (incl. index information)
[ https://issues.apache.org/jira/browse/OAK-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3394: Fix Version/s: 1.2.6 > RDBDocumentStore startup: log more DDL information (incl. index information) > > > Key: OAK-3394 > URL: https://issues.apache.org/jira/browse/OAK-3394 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.4, 1.3.5, 1.0.19 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.3.7, 1.2.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3394) RDBDocumentStore startup: log more DDL information (incl. index information)
[ https://issues.apache.org/jira/browse/OAK-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3394: Affects Version/s: 1.2.4 1.3.5 1.0.19 > RDBDocumentStore startup: log more DDL information (incl. index information) > > > Key: OAK-3394 > URL: https://issues.apache.org/jira/browse/OAK-3394 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.4, 1.3.5, 1.0.19 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.3.7, 1.2.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2929) Parent of unseen children must not be removable
[
https://issues.apache.org/jira/browse/OAK-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14790595#comment-14790595
]
Marcel Reutegger commented on OAK-2929:
---
This fix introduced a regression. See OAK-3411. Depending on the release vote,
I will either re-open this issue or create a new one for the proper fix.
> Parent of unseen children must not be removable
> ---
>
> Key: OAK-2929
> URL: https://issues.apache.org/jira/browse/OAK-2929
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
>Affects Versions: 1.0.13, 1.2
>Reporter: Vikas Saurabh
>Assignee: Marcel Reutegger
>Priority: Minor
> Labels: concurrency, technical_debt
> Fix For: 1.0.20, 1.3.6, 1.2.5
>
> Attachments: IgnoredTestCase.patch
>
>
> With OAK-2673, it's now possible to have hidden intermediate nodes created
> concurrently.
> So, a scenario like:
> {noformat}
> start -> /:hidden
> N1 creates /:hiddent/parent/node1
> N2 creates /:hidden/parent/node2
> {noformat}
> is allowed.
> But, if N2's creation of {{parent}} got persisted later than that on N1, then
> N2 is currently able to delete {{parent}} even though there's {{node1}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3395) RevisionGC fails for JCR paths having line feed characters
[
https://issues.apache.org/jira/browse/OAK-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14791572#comment-14791572
]
Chetan Mehrotra commented on OAK-3395:
--
Opened OAK-3412 to track above change
> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.7, 1.2.6, 1.0.21
>
> Attachments: OAK-3395-1.patch, OAK-3395-2.patch
>
>
> RevisionGC fails with error while processing any id (derived from JCR path)
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort
> which works with line delimited string and having an id with line break would
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
> at
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
> at
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
> at
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
> at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
> at java.util.TimSort.sort(TimSort.java:203)
> at java.util.TimSort.sort(TimSort.java:173)
> at java.util.Arrays.sort(Arrays.java:659)
> at java.util.Collections.sort(Collections.java:217)
> at
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
> at
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
> at
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
> at
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
> at
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3395) RevisionGC fails for JCR paths having line feed characters
[
https://issues.apache.org/jira/browse/OAK-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-3395.
--
Resolution: Fixed
Merged to branches
* 1.0 - http://svn.apache.org/r1703489
* 1.2 - http://svn.apache.org/r1703488
> RevisionGC fails for JCR paths having line feed characters
> --
>
> Key: OAK-3395
> URL: https://issues.apache.org/jira/browse/OAK-3395
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk, rdbmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.7, 1.2.6, 1.0.21
>
> Attachments: OAK-3395-1.patch, OAK-3395-2.patch
>
>
> RevisionGC fails with error while processing any id (derived from JCR path)
> having line feed or carriage return char
> This happens because it relies on Oak Commons StringSort and ExternalSort
> which works with line delimited string and having an id with line break would
> break this sorting logic. Error reported is like
> {noformat}
> java.lang.AssertionError: Invalid id /1442211320
> at
> org.apache.jackrabbit.oak.plugins.document.util.Utils.getDepthFromId(Utils.java:337)
> at
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:38)
> at
> org.apache.jackrabbit.oak.plugins.document.NodeDocumentIdComparator.compare(NodeDocumentIdComparator.java:30)
> at java.util.TimSort.countRunAndMakeAscending(TimSort.java:324)
> at java.util.TimSort.sort(TimSort.java:203)
> at java.util.TimSort.sort(TimSort.java:173)
> at java.util.Arrays.sort(Arrays.java:659)
> at java.util.Collections.sort(Collections.java:217)
> at
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortAndSave(ExternalSort.java:279)
> at
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:218)
> at
> org.apache.jackrabbit.oak.commons.sort.ExternalSort.sortInBatch(ExternalSort.java:257)
> at
> org.apache.jackrabbit.oak.commons.sort.StringSort$PersistentState.sort(StringSort.java:191)
> at
> org.apache.jackrabbit.oak.commons.sort.StringSort.sort(StringSort.java:88)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.ensureSorted(VersionGarbageCollector.java:383)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.getDocIdsToDelete(VersionGarbageCollector.java:274)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDeletedDocuments(VersionGarbageCollector.java:296)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector$DeletedDocsGC.removeDocuments(VersionGarbageCollector.java:241)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:154)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:105)
> at
> org.apache.jackrabbit.oak.plugins.document.VersionGCDeletionTest.gcWithPathsHavingNewLine(VersionGCDeletionTest.java:203)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3412) Node name having non space whitspace chars should not be allowed
Chetan Mehrotra created OAK-3412:
Summary: Node name having non space whitspace chars should not be
allowed
Key: OAK-3412
URL: https://issues.apache.org/jira/browse/OAK-3412
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Fix For: 1.3.7, 1.2.6, 1.0.21
Due to the changes done in OAK-1174 node with non space whitespace chars like
'\n', '\r' etc can be created. This is not desirable and also JR2 does not
allow such node to be created so check must be added to prevent such a name
from getting created.
As discussed in [1] this is regression due to usage of incorrect utility method
as part of [2] the fix can be simply using a {{Character#isWhitespace}} instead
of {{Character#isSpaceChar}}
[1]
http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201509.mbox/%3CCAHCW-mkkGtxkn%2B9xfXuvMTfgykewjMPsLwrVH%2B00%2BXaBQjA0sg%40mail.gmail.com%3E
[2]
https://github.com/apache/jackrabbit-oak/commit/342809f7f04221782ca6bbfbde9392ec4ff441c2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
