[jira] [Resolved] (OAK-4354) OAK 1.2: update Jackrabbit dependency to 2.10.3
[ https://issues.apache.org/jira/browse/OAK-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain resolved OAK-4354. Resolution: Fixed Done with http://svn.apache.org/viewvc?rev=1743463&view=rev > OAK 1.2: update Jackrabbit dependency to 2.10.3 > --- > > Key: OAK-4354 > URL: https://issues.apache.org/jira/browse/OAK-4354 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Amit Jain >Assignee: Amit Jain >Priority: Blocker > Fix For: 1.2.15 > > > Once Jackabbit 2.10.3 is released, OAK 1.2 should be updated to 2.10.3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4101) Consider separate external (group) principal management
[
https://issues.apache.org/jira/browse/OAK-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1528#comment-1528
]
Tobias Bocanegra commented on OAK-4101:
---
as far as I can tell, this is ok. I created a temporary pull request with my
comments, mostly minor stuff:
https://github.com/apache/jackrabbit-oak/pull/52
- In general, the {{...impl.principal.External*}} code could benefit from a bit
more commenting :-)
- I ran the tests and they all pass.
- I didn't test it in a real life setup.
> Consider separate external (group) principal management
> ---
>
> Key: OAK-4101
> URL: https://issues.apache.org/jira/browse/OAK-4101
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: auth-external
>Reporter: angela
>Assignee: angela
> Attachments: OAK-4101.patch, OAK-4101_test.patch
>
>
> Given the fact that user management is delegated to an external IDP provider,
> we might reconsider the current approach that attempts to synchronize user
> and particularly group and their membership into the repository.
> What would left with the repository is a dedicated {{PrincipalProvider}} for
> external groups (and maybe even users at a later stage), making sure that
> - the {{Subject}} is properly populated with {{Principal}} s upon login
> - access control can still be properly setup and managed in the repository
> for the principals defined in the external IDP.
> the consequences would be:
> - external groups (and potentially) users would no longer made available to
> the default user management implementation. alternatively: make them
> available as read-only stub i.e. group-membership as defined by the IDP could
> no longer be changed/manipulated in the reposiotry.
> - they are however exposed as principals to assert proper authentication +
> authorization. Note: any UI that properly reflects the fact that access
> control is being edited for principals (and not for users/groups) would not
> be affected at all; others might need to be adjusted to additionally support
> ac management based on the {{PrincipalManager}}
> will try to come up with a POC as soon as I find some time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4361) Reduce performance impact of observation ACFilter
[
https://issues.apache.org/jira/browse/OAK-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280688#comment-15280688
]
Michael Dürig commented on OAK-4361:
{{ACFilter}} part of the patch looks good to me AFAICS. Please have [~anchela]
look at the other part.
> Reduce performance impact of observation ACFilter
> -
>
> Key: OAK-4361
> URL: https://issues.apache.org/jira/browse/OAK-4361
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.6
>
> Attachments: OAK-4361.patch
>
>
> Observation events are filtered with {{ACFilter}} to enforce access controls.
> The performance impact of this filter is rather significant for a moderate
> number of listeners and access control entries, even when changes are done in
> a subtree the listener is not registered for.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4363) SyncMBeanImpl: result lacks 'uid' if error messages has been created from ExternalIdentityRef
[
https://issues.apache.org/jira/browse/OAK-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-4363.
-
Resolution: Fixed
Assignee: angela
Fix Version/s: 1.5.2
[~tripod], thanks for the quick response. very much appreciated. I went ahead
fixing the issue accordingly.
> SyncMBeanImpl: result lacks 'uid' if error messages has been created from
> ExternalIdentityRef
> -
>
> Key: OAK-4363
> URL: https://issues.apache.org/jira/browse/OAK-4363
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.5.2
>
>
> while writing tests for the SyncMBeanImpl I noticed the following method in
> the {{Delegatee}} that writes a sync-result for an error based on an
> {{ExternalIdentityRef}} but sets the 'uid' to empty string:
> {code}
> private static void append(@Nonnull List list, @Nonnull
> ExternalIdentityRef idRef, @Nonnull Exception e) {
> String eid = JsonUtil.getJsonString(idRef.getString());
> String msg = JsonUtil.getJsonString(e.toString());
> String jsonStr = String.format("{op:\"ERR\",uid:\"\",eid:%s,msg:%s}",
> eid, msg);
> list.add(jsonStr);
> }
> {code}
> so, I was wondering why the 'uid' is not retrieved from the
> {{ExternalIdentityRef}} object passed to the method. Something like:
> {code}
> private static void append(@Nonnull List list, @Nonnull
> ExternalIdentityRef idRef, @Nonnull Exception e) {
> String uid = JsonUtil.getJsonString(idRef.getId());
> String eid = JsonUtil.getJsonString(idRef.getString());
> String msg = JsonUtil.getJsonString(e.toString());
> String jsonStr = String.format("{op:\"ERR\",uid:%s,eid:%s,msg:%s}",
> uid, eid, msg);
> list.add(jsonStr);
> }
> {code}
> [~tripod], was there a particular reason for setting 'uid' to empty string?
> or in other words: what was the drawback of setting the uid as exposed by
> {{ExternalIdentityRef.getID()}}?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4363) SyncMBeanImpl: result lacks 'uid' if error messages has been created from ExternalIdentityRef
[
https://issues.apache.org/jira/browse/OAK-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280484#comment-15280484
]
Tobias Bocanegra commented on OAK-4363:
---
I can't remember. maybe an oversight.
> SyncMBeanImpl: result lacks 'uid' if error messages has been created from
> ExternalIdentityRef
> -
>
> Key: OAK-4363
> URL: https://issues.apache.org/jira/browse/OAK-4363
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Priority: Minor
>
> while writing tests for the SyncMBeanImpl I noticed the following method in
> the {{Delegatee}} that writes a sync-result for an error based on an
> {{ExternalIdentityRef}} but sets the 'uid' to empty string:
> {code}
> private static void append(@Nonnull List list, @Nonnull
> ExternalIdentityRef idRef, @Nonnull Exception e) {
> String eid = JsonUtil.getJsonString(idRef.getString());
> String msg = JsonUtil.getJsonString(e.toString());
> String jsonStr = String.format("{op:\"ERR\",uid:\"\",eid:%s,msg:%s}",
> eid, msg);
> list.add(jsonStr);
> }
> {code}
> so, I was wondering why the 'uid' is not retrieved from the
> {{ExternalIdentityRef}} object passed to the method. Something like:
> {code}
> private static void append(@Nonnull List list, @Nonnull
> ExternalIdentityRef idRef, @Nonnull Exception e) {
> String uid = JsonUtil.getJsonString(idRef.getId());
> String eid = JsonUtil.getJsonString(idRef.getString());
> String msg = JsonUtil.getJsonString(e.toString());
> String jsonStr = String.format("{op:\"ERR\",uid:%s,eid:%s,msg:%s}",
> uid, eid, msg);
> list.add(jsonStr);
> }
> {code}
> [~tripod], was there a particular reason for setting 'uid' to empty string?
> or in other words: what was the drawback of setting the uid as exposed by
> {{ExternalIdentityRef.getID()}}?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4154) SynchronizationMBean should optionally not force group sync.
[ https://issues.apache.org/jira/browse/OAK-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280368#comment-15280368 ] angela commented on OAK-4154: - adjusted the subject, which IMO was not properly reflecting the fact that this improvement was intended to be present for _all_ methods that perform a sync. > SynchronizationMBean should optionally not force group sync. > > > Key: OAK-4154 > URL: https://issues.apache.org/jira/browse/OAK-4154 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external >Reporter: Manfred Baedke >Assignee: Manfred Baedke > Fix For: 1.6 > > > SynchronizationMBean.syncUsers(...) and related methods always force group > synchronization. This may have a huge negative impact on the performance of > these methods. > Additional methods should be added to the interface > org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SynchronizationMBean, > featuring an additional boolean argument to enable or disable group sync. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4154) SynchronizationMBean should optionally not force group sync.
[ https://issues.apache.org/jira/browse/OAK-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-4154: Summary: SynchronizationMBean should optionally not force group sync. (was: SynchronizationMBean.syncUsers(...) should optionally not force group sync.) > SynchronizationMBean should optionally not force group sync. > > > Key: OAK-4154 > URL: https://issues.apache.org/jira/browse/OAK-4154 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external >Reporter: Manfred Baedke >Assignee: Manfred Baedke > Fix For: 1.6 > > > SynchronizationMBean.syncUsers(...) and related methods always force group > synchronization. This may have a huge negative impact on the performance of > these methods. > Additional methods should be added to the interface > org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SynchronizationMBean, > featuring an additional boolean argument to enable or disable group sync. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4154) SynchronizationMBean.syncUsers(...) should optionally not force group sync.
[ https://issues.apache.org/jira/browse/OAK-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280363#comment-15280363 ] angela commented on OAK-4154: - [~baedke], once we have additional clarification on the intended behavior and the corresponding fix, the tests should be pretty straight forward to add based on the work I did for OAK-4264. please note however, that I omitted any kind of tests related to this issue (i.e. omitted tests for all extra methods you added) as I felt that we first need to get some clarification. > SynchronizationMBean.syncUsers(...) should optionally not force group sync. > --- > > Key: OAK-4154 > URL: https://issues.apache.org/jira/browse/OAK-4154 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external >Reporter: Manfred Baedke >Assignee: Manfred Baedke > Fix For: 1.6 > > > SynchronizationMBean.syncUsers(...) and related methods always force group > synchronization. This may have a huge negative impact on the performance of > these methods. > Additional methods should be added to the interface > org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SynchronizationMBean, > featuring an additional boolean argument to enable or disable group sync. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4360) SyncMBeanImpl.syncUsers swallows errors
[
https://issues.apache.org/jira/browse/OAK-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-4360:
Priority: Minor (was: Major)
> SyncMBeanImpl.syncUsers swallows errors
> ---
>
> Key: OAK-4360
> URL: https://issues.apache.org/jira/browse/OAK-4360
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.5.2
>
>
> while writing tests for the sync-bean implementation I found that
> {{SyncMBeanImpl.syncUsers}} will swallow all errors that might occur.
> this is inconsistent with other methods that list the errors with a given
> "ERR" operation code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4363) SyncMBeanImpl: result lacks 'uid' if error messages has been created from ExternalIdentityRef
[
https://issues.apache.org/jira/browse/OAK-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-4363:
Description:
while writing tests for the SyncMBeanImpl I noticed the following method in the
{{Delegatee}} that writes a sync-result for an error based on an
{{ExternalIdentityRef}} but sets the 'uid' to empty string:
{code}
private static void append(@Nonnull List list, @Nonnull
ExternalIdentityRef idRef, @Nonnull Exception e) {
String eid = JsonUtil.getJsonString(idRef.getString());
String msg = JsonUtil.getJsonString(e.toString());
String jsonStr = String.format("{op:\"ERR\",uid:\"\",eid:%s,msg:%s}",
eid, msg);
list.add(jsonStr);
}
{code}
so, I was wondering why the 'uid' is not retrieved from the
{{ExternalIdentityRef}} object passed to the method. Something like:
{code}
private static void append(@Nonnull List list, @Nonnull
ExternalIdentityRef idRef, @Nonnull Exception e) {
String uid = JsonUtil.getJsonString(idRef.getId());
String eid = JsonUtil.getJsonString(idRef.getString());
String msg = JsonUtil.getJsonString(e.toString());
String jsonStr = String.format("{op:\"ERR\",uid:%s,eid:%s,msg:%s}",
uid, eid, msg);
list.add(jsonStr);
}
{code}
[~tripod], was there a particular reason for setting 'uid' to empty string?
or in other words: what was the drawback of setting the uid as exposed by
{{ExternalIdentityRef.getID()}}?
was:
while writing tests for the SyncMBeanImpl I noticed the following method in the
{{Delegatee}} that writes a sync-result for an error based on an
{{ExternalIdentityRef}} but sets the 'uid' to empty string:
{code}
private static void append(@Nonnull List list, @Nonnull
ExternalIdentityRef idRef, @Nonnull Exception e) {
String eid = JsonUtil.getJsonString(idRef.getString());
String msg = JsonUtil.getJsonString(e.toString());
String jsonStr = String.format("{op:\"ERR\",uid:\"\",eid:%s,msg:%s}",
eid, msg);
list.add(jsonStr);
}
{code}
so, I was wondering why the 'uid' is not retrieved from the
{{ExternalIdentityRef}} object passed to the method. Something like:
{code}
private static void append(@Nonnull List list, @Nonnull
ExternalIdentityRef idRef, @Nonnull Exception e) {
String uid = JsonUtil.getJsonString(idRef.getId());
String eid = JsonUtil.getJsonString(idRef.getString());
String msg = JsonUtil.getJsonString(e.toString());
String jsonStr = String.format("{op:\"ERR\",uid:%s,eid:%s,msg:%s}",
uid, eid, msg);
list.add(jsonStr);
}
[~tripod], was there a particular reason for setting 'uid' to empty string?
or in other words: what was the drawback of setting the uid as exposed by
{{ExternalIdentityRef.getID()}}?
> SyncMBeanImpl: result lacks 'uid' if error messages has been created from
> ExternalIdentityRef
> -
>
> Key: OAK-4363
> URL: https://issues.apache.org/jira/browse/OAK-4363
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Priority: Minor
>
> while writing tests for the SyncMBeanImpl I noticed the following method in
> the {{Delegatee}} that writes a sync-result for an error based on an
> {{ExternalIdentityRef}} but sets the 'uid' to empty string:
> {code}
> private static void append(@Nonnull List list, @Nonnull
> ExternalIdentityRef idRef, @Nonnull Exception e) {
> String eid = JsonUtil.getJsonString(idRef.getString());
> String msg = JsonUtil.getJsonString(e.toString());
> String jsonStr = String.format("{op:\"ERR\",uid:\"\",eid:%s,msg:%s}",
> eid, msg);
> list.add(jsonStr);
> }
> {code}
> so, I was wondering why the 'uid' is not retrieved from the
> {{ExternalIdentityRef}} object passed to the method. Something like:
> {code}
> private static void append(@Nonnull List list, @Nonnull
> ExternalIdentityRef idRef, @Nonnull Exception e) {
> String uid = JsonUtil.getJsonString(idRef.getId());
> String eid = JsonUtil.getJsonString(idRef.getString());
> String msg = JsonUtil.getJsonString(e.toString());
> String jsonStr = String.format("{op:\"ERR\",uid:%s,eid:%s,msg:%s}",
> uid, eid, msg);
> list.add(jsonStr);
> }
> {code}
> [~tripod], was there a particular reason for setting 'uid' to empty string?
> or in other words: what was the drawback of setting the uid as exposed by
> {{ExternalIdentityRef.getID()}}?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4361) Reduce performance impact of observation ACFilter
[
https://issues.apache.org/jira/browse/OAK-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-4361:
--
Attachment: OAK-4361.patch
The attached patch introduces lazy initialization of {{CompiledPermissions}}
and {{TreePermission}}. With this change the performance of the two test runs
are roughly the same.
> Reduce performance impact of observation ACFilter
> -
>
> Key: OAK-4361
> URL: https://issues.apache.org/jira/browse/OAK-4361
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.6
>
> Attachments: OAK-4361.patch
>
>
> Observation events are filtered with {{ACFilter}} to enforce access controls.
> The performance impact of this filter is rather significant for a moderate
> number of listeners and access control entries, even when changes are done in
> a subtree the listener is not registered for.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4363) SyncMBeanImpl: result lacks 'uid' if error messages has been created from ExternalIdentityRef
angela created OAK-4363:
---
Summary: SyncMBeanImpl: result lacks 'uid' if error messages has
been created from ExternalIdentityRef
Key: OAK-4363
URL: https://issues.apache.org/jira/browse/OAK-4363
Project: Jackrabbit Oak
Issue Type: Bug
Components: auth-external
Reporter: angela
Priority: Minor
while writing tests for the SyncMBeanImpl I noticed the following method in the
{{Delegatee}} that writes a sync-result for an error based on an
{{ExternalIdentityRef}} but sets the 'uid' to empty string:
{code}
private static void append(@Nonnull List list, @Nonnull
ExternalIdentityRef idRef, @Nonnull Exception e) {
String eid = JsonUtil.getJsonString(idRef.getString());
String msg = JsonUtil.getJsonString(e.toString());
String jsonStr = String.format("{op:\"ERR\",uid:\"\",eid:%s,msg:%s}",
eid, msg);
list.add(jsonStr);
}
{code}
so, I was wondering why the 'uid' is not retrieved from the
{{ExternalIdentityRef}} object passed to the method. Something like:
{code}
private static void append(@Nonnull List list, @Nonnull
ExternalIdentityRef idRef, @Nonnull Exception e) {
String uid = JsonUtil.getJsonString(idRef.getId());
String eid = JsonUtil.getJsonString(idRef.getString());
String msg = JsonUtil.getJsonString(e.toString());
String jsonStr = String.format("{op:\"ERR\",uid:%s,eid:%s,msg:%s}",
uid, eid, msg);
list.add(jsonStr);
}
[~tripod], was there a particular reason for setting 'uid' to empty string?
or in other words: what was the drawback of setting the uid as exposed by
{{ExternalIdentityRef.getID()}}?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4264) Improve testing of SyncMBeanImpl
[ https://issues.apache.org/jira/browse/OAK-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-4264. - Resolution: Fixed Fix Version/s: 1.5.2 Please note that the test-cases provided with this issue do _not_ include any tests that would be needed to proper cover the API extensions added with OAK-4154: it has been reopened with the request to provide tests and additional clarification because I am not sure that the fix really does what was the original intention. > Improve testing of SyncMBeanImpl > > > Key: OAK-4264 > URL: https://issues.apache.org/jira/browse/OAK-4264 > Project: Jackrabbit Oak > Issue Type: Test > Components: auth-external >Reporter: angela >Assignee: angela > Fix For: 1.5.2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4362) SyncMBeanImpl.purgeOrphanedUsers swallows sync-error
[
https://issues.apache.org/jira/browse/OAK-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-4362.
-
Resolution: Fixed
> SyncMBeanImpl.purgeOrphanedUsers swallows sync-error
>
>
> Key: OAK-4362
> URL: https://issues.apache.org/jira/browse/OAK-4362
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.5.2
>
>
> while writing tests for the sync-bean implementation I found that
> SyncMBeanImpl.purgeOrphanedUsers will swallow the information if the sync
> (i.e. removal) of an individual orphaned user fails with {{SyncException}}.
> IMO it would be better (and consistent) to list the error with a given "ERR"
> operation code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4362) SyncMBeanImpl.purgeOrphanedUsers swallows sync-error
angela created OAK-4362:
---
Summary: SyncMBeanImpl.purgeOrphanedUsers swallows sync-error
Key: OAK-4362
URL: https://issues.apache.org/jira/browse/OAK-4362
Project: Jackrabbit Oak
Issue Type: Bug
Components: auth-external
Reporter: angela
Assignee: angela
Priority: Minor
Fix For: 1.5.2
while writing tests for the sync-bean implementation I found that
SyncMBeanImpl.purgeOrphanedUsers will swallow the information if the sync (i.e.
removal) of an individual orphaned user fails with {{SyncException}}.
IMO it would be better (and consistent) to list the error with a given "ERR"
operation code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4285) Align cleanup of segment id tables with the new cleanup strategy
[ https://issues.apache.org/jira/browse/OAK-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-4285: --- Attachment: OAK_4285.patch Proposed patch [^OAK_4285.patch] to remove the clean up of the segment id tables. See my last comment for the rational. > Align cleanup of segment id tables with the new cleanup strategy > - > > Key: OAK-4285 > URL: https://issues.apache.org/jira/browse/OAK-4285 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Alex Parvulescu > Labels: cleanup, gc > Fix For: 1.6 > > Attachments: OAK_4285.patch, OAK_4285.patch > > > We need to align cleanup of the segment id tables with the new "brutal" > strategy introduced with OAK-3348. That is, we need to remove those segment > id's from the segment id tables whose segment have actually been gc'ed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4281) Rework memory estimation for compaction
[
https://issues.apache.org/jira/browse/OAK-4281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280273#comment-15280273
]
Michael Dürig commented on OAK-4281:
An alternative solution would be to remove the memory check in {{maybeCompact}}
and move it into the "cancellation supplier" (see
{{FileStore.newCancelCompactionCondition}}). This would have the additional
advantage the compaction would cancel itself should we risk running OOM once it
has been started. In this case I would remove the delta value entirely and only
look at the available space. If this is too low for a couple of subsequent
checks we would just bail out.
> Rework memory estimation for compaction
> ---
>
> Key: OAK-4281
> URL: https://issues.apache.org/jira/browse/OAK-4281
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Alex Parvulescu
> Labels: compaction, gc
> Fix For: 1.6
>
>
> As a result of OAK-3348 we need to partially rework the memory estimation
> step done for deciding whether compaction can run or not. In {{oak-segment}}
> there was a {{delta}} value derived from the compaction map. As the latter is
> gone in {{oak-segment-next}} we need to decide whether there is another way
> to derive this delta or whether we want to drop it entirely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4281) Rework memory estimation for compaction
[
https://issues.apache.org/jira/browse/OAK-4281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280270#comment-15280270
]
Michael Dürig commented on OAK-4281:
One good alternative where we could derive the delta value from is the node
deduplication cache ({{RecordCache.DeduplicationCache}}): compaction
[instantiates a new generation |
https://github.com/apache/jackrabbit-oak/blob/0047f257c2aed16fc38a98f9d8e758991a70f6cd/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/file/FileStore.java#L1066]
of that cache. The memory requirements of the previous (that is, current)
generation of this cache should be a good estimate of the extra memory required
to run compaction.
> Rework memory estimation for compaction
> ---
>
> Key: OAK-4281
> URL: https://issues.apache.org/jira/browse/OAK-4281
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Alex Parvulescu
> Labels: compaction, gc
> Fix For: 1.6
>
>
> As a result of OAK-3348 we need to partially rework the memory estimation
> step done for deciding whether compaction can run or not. In {{oak-segment}}
> there was a {{delta}} value derived from the compaction map. As the latter is
> gone in {{oak-segment-next}} we need to decide whether there is another way
> to derive this delta or whether we want to drop it entirely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4361) Reduce performance impact of observation ACFilter
[
https://issues.apache.org/jira/browse/OAK-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280255#comment-15280255
]
Marcel Reutegger commented on OAK-4361:
---
It's important to note that the listeners never receive any events in this
test. The listeners are registered with a path that does not get changes.
> Reduce performance impact of observation ACFilter
> -
>
> Key: OAK-4361
> URL: https://issues.apache.org/jira/browse/OAK-4361
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.6
>
>
> Observation events are filtered with {{ACFilter}} to enforce access controls.
> The performance impact of this filter is rather significant for a moderate
> number of listeners and access control entries, even when changes are done in
> a subtree the listener is not registered for.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4361) Reduce performance impact of observation ACFilter
[
https://issues.apache.org/jira/browse/OAK-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280250#comment-15280250
]
Marcel Reutegger commented on OAK-4361:
---
Added more parameters to {{ConcurrentCreateNodesTest}} to tweak the test
behaviour.
Using listeners from admin sessions is fast (but not realistic). The number of
listeners is set to 50 and the everyone principal has 100 access control
entries in the permission store.
{noformat}
> java -Xmx1g -DworkerCount=1 -DlistenerCount=50 -DlistenerPath=/nothing-here
> -DaclCount=100 -jar target/oak-run-1.6-SNAPSHOT.jar benchmark
> ConcurrentCreateNodesTest Oak-Tar
Apache Jackrabbit Oak 1.6-SNAPSHOT
# ConcurrentCreateNodesTestC min 10% 50% 90% max
N
Oak-Tar1 23 25 30 39 51
1931
{noformat}
The same test with a non-admin session:
{noformat}
> java -Xmx1g -DnonAdminListener=true -DworkerCount=1 -DlistenerCount=50
> -DlistenerPath=/nothing-here -DaclCount=100 -jar
> target/oak-run-1.6-SNAPSHOT.jar benchmark ConcurrentCreateNodesTest Oak-Tar
Apache Jackrabbit Oak 1.6-SNAPSHOT
# ConcurrentCreateNodesTestC min 10% 50% 90% max
N
Oak-Tar1 81 182 208 252 437
277
{noformat}
There is a significant drop in writes per second, from roughly 2000 to 200 on
my machine. The CPU is mostly busy with initialising the ACFilter for change
processing:
{noformat}
"oak-executor-0" #18 daemon prio=1 os_prio=31 tid=0x7fb768640800 nid=0x6703
runnable [0x000124c28000]
java.lang.Thread.State: RUNNABLE
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getRecordIdV11(SegmentNodeState.java:168)
at
org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getProperty(SegmentNodeState.java:140)
at
org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.getProperty(ReadOnlyBuilder.java:137)
at
org.apache.jackrabbit.oak.plugins.tree.impl.AbstractTree.getProperty(AbstractTree.java:249)
at org.apache.jackrabbit.oak.util.TreeUtil.getBoolean(TreeUtil.java:129)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionStoreImpl.createPermissionEntry(PermissionStoreImpl.java:182)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionStoreImpl.loadPermissionEntries(PermissionStoreImpl.java:154)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionStoreImpl.load(PermissionStoreImpl.java:115)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryCache.getEntries(PermissionEntryCache.java:48)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryCache.load(PermissionEntryCache.java:63)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryProviderImpl.init(PermissionEntryProviderImpl.java:109)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryProviderImpl.(PermissionEntryProviderImpl.java:72)
at
org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl.(CompiledPermissionImpl.java:112)
at
org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl.create(CompiledPermissionImpl.java:126)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionProviderImpl.(PermissionProviderImpl.java:71)
at
org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl.getPermissionProvider(AuthorizationConfigurationImpl.java:185)
at
org.apache.jackrabbit.oak.security.authorization.composite.CompositeAuthorizationConfiguration.getPermissionProvider(CompositeAuthorizationConfiguration.java:135)
at
org.apache.jackrabbit.oak.jcr.observation.ObservationManagerImpl$1.create(ObservationManagerImpl.java:122)
at
org.apache.jackrabbit.oak.plugins.observation.filter.FilterBuilder$ACCondition.createFilter(FilterBuilder.java:457)
at
org.apache.jackrabbit.oak.plugins.observation.filter.FilterBuilder$AllCondition.createFilter(FilterBuilder.java:590)
at
org.apache.jackrabbit.oak.plugins.observation.filter.FilterBuilder$1.getFilter(FilterBuilder.java:386)
at
org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.contentChanged(ChangeProcessor.java:310)
at
org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:131)
at
org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:125)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[jira] [Resolved] (OAK-4280) Compaction cannot be cancelled
[
https://issues.apache.org/jira/browse/OAK-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-4280.
Resolution: Fixed
Fixed at http://svn.apache.org/viewvc?rev=1743381&view=rev
The fix introduces a new method on {{SegmentWriter}}:
{code}
/**
* Write a node state, unless cancelled
* @param state node state to write
* @param cancel supplier to signal cancellation of this write operation
* @return segment node state equal to {@code state} or {@code null} if
cancelled.
* @throws IOException
*/
@CheckForNull
public SegmentNodeState writeNode(final NodeState state, Supplier
cancel)
{code}
This method is used for online compaction. Cancellation can be triggered
through the passed supplier.
Internally the implementation uses an (encapsulated) exception to break out of
the recursive call chain. While this doesn't win any beauty contest, I figured
it to be the most effective way to separate normal code flow from the special
case of cancellation.
> Compaction cannot be cancelled
> ---
>
> Key: OAK-4280
> URL: https://issues.apache.org/jira/browse/OAK-4280
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction, gc
> Fix For: 1.6
>
>
> As a result of the de-duplication cache based online compaction approach from
> OAK-3348 compaction cannot be cancelled any more (in the sense of OAK-3290).
> As I assume we still need this feature we should look into ways to
> re-implement it on top of the current approach.
> Also I figure implementing a [partial compaction |
> https://issues.apache.org/jira/browse/OAK-4122?focusedCommentId=15223924&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15223924]
> approach on top of a commit scheduler (OAK-4122) would need a feature of
> this sort.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4361) Reduce performance impact of observation ACFilter
Marcel Reutegger created OAK-4361:
-
Summary: Reduce performance impact of observation ACFilter
Key: OAK-4361
URL: https://issues.apache.org/jira/browse/OAK-4361
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, security
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Fix For: 1.6
Observation events are filtered with {{ACFilter}} to enforce access controls.
The performance impact of this filter is rather significant for a moderate
number of listeners and access control entries, even when changes are done in a
subtree the listener is not registered for.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3840) Clean up the FileStore constructor
[
https://issues.apache.org/jira/browse/OAK-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280182#comment-15280182
]
Marcel Reutegger commented on OAK-3840:
---
Fixed a NPE within the SegmentFixture in oak-run when blobStore is null:
http://svn.apache.org/r1743375
> Clean up the FileStore constructor
> --
>
> Key: OAK-3840
> URL: https://issues.apache.org/jira/browse/OAK-3840
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Francesco Mari
> Labels: technical_debt
> Fix For: 1.5.2
>
> Attachments: OAK-3840-01.patch
>
>
> The {{FileStore}} constructor consists of more than 150 LoC and is a mess as
> it depends on the order of initialisation, calls overrideable methods handles
> different concerns (read only vs. read / write) etc.
> We should up with a cleaner way of instantiating a file store.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4250) DocumentStore: add test coverage for find() with ultra-long keys
[ https://issues.apache.org/jira/browse/OAK-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4250: Fix Version/s: 1.0.31 > DocumentStore: add test coverage for find() with ultra-long keys > > > Key: OAK-4250 > URL: https://issues.apache.org/jira/browse/OAK-4250 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: documentmk >Affects Versions: 1.4.1, 1.0.30, 1.2.14, 1.5.1 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.5.2, 1.0.31, 1.2.15, 1.4.3 > > > (also make sure that there are no misleading error messages in the system log) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4250) DocumentStore: add test coverage for find() with ultra-long keys
[ https://issues.apache.org/jira/browse/OAK-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15278264#comment-15278264 ] Julian Reschke edited comment on OAK-4250 at 5/11/16 2:00 PM: -- trunk: http://svn.apache.org/r1740116 1.4: http://svn.apache.org/r1743211 1.2: http://svn.apache.org/r1743356 1.0: http://svn.apache.org/r1743367 was (Author: reschke): trunk: http://svn.apache.org/r1740116 1.4: http://svn.apache.org/r1743211 1.2: http://svn.apache.org/r1743356 > DocumentStore: add test coverage for find() with ultra-long keys > > > Key: OAK-4250 > URL: https://issues.apache.org/jira/browse/OAK-4250 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: documentmk >Affects Versions: 1.4.1, 1.0.30, 1.2.14, 1.5.1 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.5.2, 1.0.31, 1.2.15, 1.4.3 > > > (also make sure that there are no misleading error messages in the system log) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4351) Non-root lucene index throws exception if query constraints match root of sub-tree
[
https://issues.apache.org/jira/browse/OAK-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-4351.
Resolution: Fixed
Fix Version/s: 1.5.2
Fixed in trunk at [r1743368|https://svn.apache.org/r1743368].
> Non-root lucene index throws exception if query constraints match root of
> sub-tree
> --
>
> Key: OAK-4351
> URL: https://issues.apache.org/jira/browse/OAK-4351
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.6, 1.5.2
>
>
> LucenePropetyIndexProvider returns incorrect (normalized) path for root of
> sub-tree if index is defined on the sub-tree. e.g.
> {{/jcr:root/test//element(*, nt:base)\[@foo='bar']}} would fail with
> following defn
> {noformat}
> + /test
> - foo="bar"
> + test1
> - foo="bar"
> + oak:index
>- indexRules/nt:base/properties/foo/propertyIndex="true"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4250) DocumentStore: add test coverage for find() with ultra-long keys
[ https://issues.apache.org/jira/browse/OAK-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4250: Labels: (was: candidate_oak_1_0) > DocumentStore: add test coverage for find() with ultra-long keys > > > Key: OAK-4250 > URL: https://issues.apache.org/jira/browse/OAK-4250 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: documentmk >Affects Versions: 1.4.1, 1.0.30, 1.2.14, 1.5.1 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: 1.5.2, 1.0.31, 1.2.15, 1.4.3 > > > (also make sure that there are no misleading error messages in the system log) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4359) Lucene index / compatVersion 2: search for 'a=b=c' does not work
[
https://issues.apache.org/jira/browse/OAK-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-4359.
Resolution: Fixed
> Lucene index / compatVersion 2: search for 'a=b=c' does not work
>
>
> Key: OAK-4359
> URL: https://issues.apache.org/jira/browse/OAK-4359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.6, 1.5.2, 1.2.15, 1.4.3
>
>
> Similar to OAK-3879, we need to escape '=' (althoug lucene
> [escape()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L988]
> apparently doesn't escape it).
> Due to this searching for {{a=b=c}} throws parse exception from lucene query
> parser. Also, searching for {{a=b}} gives incorrect result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4359) Lucene index / compatVersion 2: search for 'a=b=c' does not work
[
https://issues.apache.org/jira/browse/OAK-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4359:
---
Fix Version/s: 1.6
> Lucene index / compatVersion 2: search for 'a=b=c' does not work
>
>
> Key: OAK-4359
> URL: https://issues.apache.org/jira/browse/OAK-4359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.6, 1.5.2, 1.2.15, 1.4.3
>
>
> Similar to OAK-3879, we need to escape '=' (althoug lucene
> [escape()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L988]
> apparently doesn't escape it).
> Due to this searching for {{a=b=c}} throws parse exception from lucene query
> parser. Also, searching for {{a=b}} gives incorrect result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3879) Lucene index / compatVersion 2: search for 'abc!' does not work
[
https://issues.apache.org/jira/browse/OAK-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280142#comment-15280142
]
Vikas Saurabh commented on OAK-3879:
With OAK-4359, the list also contains {{=}} (being lazy and just commenting
here instead of updating docs myself ;) )
> Lucene index / compatVersion 2: search for 'abc!' does not work
> ---
>
> Key: OAK-3879
> URL: https://issues.apache.org/jira/browse/OAK-3879
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Chetan Mehrotra
> Labels: docs-impacting
> Fix For: 1.4, 1.3.15, 1.2.15
>
> Attachments: OAK-3879-v1.patch
>
>
> When using a Lucene fulltext index with compatVersion 2, then the following
> query does not return any results. When using compatVersion 1, the correct
> result is returned.
> {noformat}
> SELECT * FROM [nt:unstructured] AS c
> WHERE CONTAINS(c.[jcr:description], 'abc!')
> AND ISDESCENDANTNODE(c, '/content')
> {noformat}
> With compatVersion 1 and 2, searching for just 'abc' works. Also, searching
> with '=' instead of 'contains' works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4359) Lucene index / compatVersion 2: search for 'a=b=c' does not work
[
https://issues.apache.org/jira/browse/OAK-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4359:
---
Labels: (was: candidate_oak_1_2)
> Lucene index / compatVersion 2: search for 'a=b=c' does not work
>
>
> Key: OAK-4359
> URL: https://issues.apache.org/jira/browse/OAK-4359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.5.2, 1.2.15, 1.4.3
>
>
> Similar to OAK-3879, we need to escape '=' (althoug lucene
> [escape()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L988]
> apparently doesn't escape it).
> Due to this searching for {{a=b=c}} throws parse exception from lucene query
> parser. Also, searching for {{a=b}} gives incorrect result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4359) Lucene index / compatVersion 2: search for 'a=b=c' does not work
[
https://issues.apache.org/jira/browse/OAK-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4359:
---
Fix Version/s: 1.2.15
> Lucene index / compatVersion 2: search for 'a=b=c' does not work
>
>
> Key: OAK-4359
> URL: https://issues.apache.org/jira/browse/OAK-4359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.5.2, 1.2.15, 1.4.3
>
>
> Similar to OAK-3879, we need to escape '=' (althoug lucene
> [escape()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L988]
> apparently doesn't escape it).
> Due to this searching for {{a=b=c}} throws parse exception from lucene query
> parser. Also, searching for {{a=b}} gives incorrect result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4359) Lucene index / compatVersion 2: search for 'a=b=c' does not work
[
https://issues.apache.org/jira/browse/OAK-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280117#comment-15280117
]
Vikas Saurabh edited comment on OAK-4359 at 5/11/16 1:51 PM:
-
Backported to 1.4 branch at [r1743364|https://svn.apache.org/r1743364] and on
1.2 branch at [r1743366|https://svn.apache.org/r1743366].
was (Author: catholicon):
Backported to 1.4 branch at [r1743364|https://svn.apache.org/r1743364].
> Lucene index / compatVersion 2: search for 'a=b=c' does not work
>
>
> Key: OAK-4359
> URL: https://issues.apache.org/jira/browse/OAK-4359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.5.2, 1.2.15, 1.4.3
>
>
> Similar to OAK-3879, we need to escape '=' (althoug lucene
> [escape()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L988]
> apparently doesn't escape it).
> Due to this searching for {{a=b=c}} throws parse exception from lucene query
> parser. Also, searching for {{a=b}} gives incorrect result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4359) Lucene index / compatVersion 2: search for 'a=b=c' does not work
[
https://issues.apache.org/jira/browse/OAK-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4359:
---
Fix Version/s: 1.4.3
> Lucene index / compatVersion 2: search for 'a=b=c' does not work
>
>
> Key: OAK-4359
> URL: https://issues.apache.org/jira/browse/OAK-4359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2
> Fix For: 1.5.2, 1.4.3
>
>
> Similar to OAK-3879, we need to escape '=' (althoug lucene
> [escape()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L988]
> apparently doesn't escape it).
> Due to this searching for {{a=b=c}} throws parse exception from lucene query
> parser. Also, searching for {{a=b}} gives incorrect result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4359) Lucene index / compatVersion 2: search for 'a=b=c' does not work
[
https://issues.apache.org/jira/browse/OAK-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4359:
---
Labels: candidate_oak_1_2 (was: candidate_oak_1_2 candidate_oak_1_4)
> Lucene index / compatVersion 2: search for 'a=b=c' does not work
>
>
> Key: OAK-4359
> URL: https://issues.apache.org/jira/browse/OAK-4359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2
> Fix For: 1.5.2, 1.4.3
>
>
> Similar to OAK-3879, we need to escape '=' (althoug lucene
> [escape()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L988]
> apparently doesn't escape it).
> Due to this searching for {{a=b=c}} throws parse exception from lucene query
> parser. Also, searching for {{a=b}} gives incorrect result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4359) Lucene index / compatVersion 2: search for 'a=b=c' does not work
[
https://issues.apache.org/jira/browse/OAK-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280117#comment-15280117
]
Vikas Saurabh commented on OAK-4359:
Backported to 1.4 branch at [r1743364|https://svn.apache.org/r1743364].
> Lucene index / compatVersion 2: search for 'a=b=c' does not work
>
>
> Key: OAK-4359
> URL: https://issues.apache.org/jira/browse/OAK-4359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.5.2
>
>
> Similar to OAK-3879, we need to escape '=' (althoug lucene
> [escape()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L988]
> apparently doesn't escape it).
> Due to this searching for {{a=b=c}} throws parse exception from lucene query
> parser. Also, searching for {{a=b}} gives incorrect result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4250) DocumentStore: add test coverage for find() with ultra-long keys
[ https://issues.apache.org/jira/browse/OAK-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15278264#comment-15278264 ] Julian Reschke edited comment on OAK-4250 at 5/11/16 1:19 PM: -- trunk: http://svn.apache.org/r1740116 1.4: http://svn.apache.org/r1743211 1.2: http://svn.apache.org/r1743356 was (Author: reschke): trunk: http://svn.apache.org/r1740116 1.4: http://svn.apache.org/r1743211 > DocumentStore: add test coverage for find() with ultra-long keys > > > Key: OAK-4250 > URL: https://issues.apache.org/jira/browse/OAK-4250 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: documentmk >Affects Versions: 1.4.1, 1.0.30, 1.2.14, 1.5.1 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Labels: candidate_oak_1_0 > Fix For: 1.5.2, 1.2.15, 1.4.3 > > > (also make sure that there are no misleading error messages in the system log) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4250) DocumentStore: add test coverage for find() with ultra-long keys
[ https://issues.apache.org/jira/browse/OAK-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4250: Fix Version/s: 1.2.15 > DocumentStore: add test coverage for find() with ultra-long keys > > > Key: OAK-4250 > URL: https://issues.apache.org/jira/browse/OAK-4250 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: documentmk >Affects Versions: 1.4.1, 1.0.30, 1.2.14, 1.5.1 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Labels: candidate_oak_1_0 > Fix For: 1.5.2, 1.2.15, 1.4.3 > > > (also make sure that there are no misleading error messages in the system log) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4250) DocumentStore: add test coverage for find() with ultra-long keys
[ https://issues.apache.org/jira/browse/OAK-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4250: Labels: candidate_oak_1_0 (was: candidate_oak_1_0 candidate_oak_1_2) > DocumentStore: add test coverage for find() with ultra-long keys > > > Key: OAK-4250 > URL: https://issues.apache.org/jira/browse/OAK-4250 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: documentmk >Affects Versions: 1.4.1, 1.0.30, 1.2.14, 1.5.1 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Labels: candidate_oak_1_0 > Fix For: 1.5.2, 1.2.15, 1.4.3 > > > (also make sure that there are no misleading error messages in the system log) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4359) Lucene index / compatVersion 2: search for 'a=b=c' does not work
[
https://issues.apache.org/jira/browse/OAK-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280070#comment-15280070
]
Chetan Mehrotra commented on OAK-4359:
--
+1 commit looks fine. Lets add a section in our docs around what characters we
escape or update the list in OAK-3879
> Lucene index / compatVersion 2: search for 'a=b=c' does not work
>
>
> Key: OAK-4359
> URL: https://issues.apache.org/jira/browse/OAK-4359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.5.2
>
>
> Similar to OAK-3879, we need to escape '=' (althoug lucene
> [escape()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L988]
> apparently doesn't escape it).
> Due to this searching for {{a=b=c}} throws parse exception from lucene query
> parser. Also, searching for {{a=b}} gives incorrect result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-1963) Expose URL for Blob source
[ https://issues.apache.org/jira/browse/OAK-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280065#comment-15280065 ] Thomas Mueller commented on OAK-1963: - I think we should close this issue and open new, cross-linked issues (or a wiki page) with the exact, detailed use cases and problems of the current API. > Expose URL for Blob source > --- > > Key: OAK-1963 > URL: https://issues.apache.org/jira/browse/OAK-1963 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Pralaypati Ta >Assignee: Chetan Mehrotra > Labels: datastore > Fix For: 1.6 > > > In certain scenarios for performance reasons its desirable to have direct > access to the Blob source. > For e.g. if using a FileDataStore having a direct access to the native file > system path of the blob (if not stored in chunks) is more useful than > repository path e.g. native tools don't understand repository path, instead > file system path can be passed directly to native tools for processing binary. > Another usecase being ability exposed signed S3 url which would allow access > to binary content directly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-4346) SyncMBeanImpl.syncExternalUsers doesn't check for foreign IDP
[
https://issues.apache.org/jira/browse/OAK-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reassigned OAK-4346:
---
Assignee: angela
> SyncMBeanImpl.syncExternalUsers doesn't check for foreign IDP
> -
>
> Key: OAK-4346
> URL: https://issues.apache.org/jira/browse/OAK-4346
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: angela
> Fix For: 1.5.2
>
>
> in the light of OAK-4264 i found that {{SyncMBeanImpl.syncExternalUsers}}
> doesn't verify that the given external-ids belong to the same IDP that the
> bean has been created for.
> my expectation for the result-messages was an operation key {{for}} (FOREIGN)
> but instead the user might even be synchronized depending on the behavior of
> the IDP or result in {{nsi}} if the a given userID is (by coincidence) not
> known to the IDP.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4346) SyncMBeanImpl.syncExternalUsers doesn't check for foreign IDP
[
https://issues.apache.org/jira/browse/OAK-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-4346.
-
Resolution: Fixed
Fix Version/s: 1.5.2
> SyncMBeanImpl.syncExternalUsers doesn't check for foreign IDP
> -
>
> Key: OAK-4346
> URL: https://issues.apache.org/jira/browse/OAK-4346
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
> Fix For: 1.5.2
>
>
> in the light of OAK-4264 i found that {{SyncMBeanImpl.syncExternalUsers}}
> doesn't verify that the given external-ids belong to the same IDP that the
> bean has been created for.
> my expectation for the result-messages was an operation key {{for}} (FOREIGN)
> but instead the user might even be synchronized depending on the behavior of
> the IDP or result in {{nsi}} if the a given userID is (by coincidence) not
> known to the IDP.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4360) SyncMBeanImpl.syncUsers swallows errors
[
https://issues.apache.org/jira/browse/OAK-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-4360.
-
Resolution: Fixed
Fix Version/s: 1.5.2
> SyncMBeanImpl.syncUsers swallows errors
> ---
>
> Key: OAK-4360
> URL: https://issues.apache.org/jira/browse/OAK-4360
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: angela
> Fix For: 1.5.2
>
>
> while writing tests for the sync-bean implementation I found that
> {{SyncMBeanImpl.syncUsers}} will swallow all errors that might occur.
> this is inconsistent with other methods that list the errors with a given
> "ERR" operation code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4360) SyncMBeanImpl.syncUsers swallows errors
angela created OAK-4360:
---
Summary: SyncMBeanImpl.syncUsers swallows errors
Key: OAK-4360
URL: https://issues.apache.org/jira/browse/OAK-4360
Project: Jackrabbit Oak
Issue Type: Bug
Components: auth-external
Reporter: angela
Assignee: angela
while writing tests for the sync-bean implementation I found that
{{SyncMBeanImpl.syncUsers}} will swallow all errors that might occur.
this is inconsistent with other methods that list the errors with a given "ERR"
operation code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4359) Lucene index / compatVersion 2: search for 'a=b=c' does not work
[
https://issues.apache.org/jira/browse/OAK-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4359:
---
Fix Version/s: 1.5.2
> Lucene index / compatVersion 2: search for 'a=b=c' does not work
>
>
> Key: OAK-4359
> URL: https://issues.apache.org/jira/browse/OAK-4359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.5.2
>
>
> Similar to OAK-3879, we need to escape '=' (althoug lucene
> [escape()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L988]
> apparently doesn't escape it).
> Due to this searching for {{a=b=c}} throws parse exception from lucene query
> parser. Also, searching for {{a=b}} gives incorrect result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4359) Lucene index / compatVersion 2: search for 'a=b=c' does not work
[
https://issues.apache.org/jira/browse/OAK-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280033#comment-15280033
]
Vikas Saurabh commented on OAK-4359:
Committed to trunk at [r1743343|https://svn.apache.org/r1743343]. [~chetanm]
can you please review. I'd backport to 1.4 and 1.2 post review.
> Lucene index / compatVersion 2: search for 'a=b=c' does not work
>
>
> Key: OAK-4359
> URL: https://issues.apache.org/jira/browse/OAK-4359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2, candidate_oak_1_4
>
> Similar to OAK-3879, we need to escape '=' (althoug lucene
> [escape()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L988]
> apparently doesn't escape it).
> Due to this searching for {{a=b=c}} throws parse exception from lucene query
> parser. Also, searching for {{a=b}} gives incorrect result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4359) Lucene index / compatVersion 2: search for 'a=b=c' does not work
Vikas Saurabh created OAK-4359:
--
Summary: Lucene index / compatVersion 2: search for 'a=b=c' does
not work
Key: OAK-4359
URL: https://issues.apache.org/jira/browse/OAK-4359
Project: Jackrabbit Oak
Issue Type: Bug
Components: lucene
Reporter: Vikas Saurabh
Assignee: Vikas Saurabh
Similar to OAK-3879, we need to escape '=' (althoug lucene
[escape()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L988]
apparently doesn't escape it).
Due to this searching for {{a=b=c}} throws parse exception from lucene query
parser. Also, searching for {{a=b}} gives incorrect result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4280) Compaction cannot be cancelled
[ https://issues.apache.org/jira/browse/OAK-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig reassigned OAK-4280: -- Assignee: Michael Dürig (was: Alex Parvulescu) > Compaction cannot be cancelled > --- > > Key: OAK-4280 > URL: https://issues.apache.org/jira/browse/OAK-4280 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: compaction, gc > Fix For: 1.6 > > > As a result of the de-duplication cache based online compaction approach from > OAK-3348 compaction cannot be cancelled any more (in the sense of OAK-3290). > As I assume we still need this feature we should look into ways to > re-implement it on top of the current approach. > Also I figure implementing a [partial compaction | > https://issues.apache.org/jira/browse/OAK-4122?focusedCommentId=15223924&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15223924] > approach on top of a commit scheduler (OAK-4122) would need a feature of > this sort. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4291) FileStore.flush prone to races leading to corruption
[
https://issues.apache.org/jira/browse/OAK-4291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15279964#comment-15279964
]
Michael Dürig commented on OAK-4291:
Addressing this issue involves some deeper refactorings. Currently the flush
methods 1) persists pending segments, 2) updates the journal and 3) triggers
cleanup. I think we need to first untangle this so we can come up with a clean
solution. As such refactorings most likely interact with OAK-3690, OAK-4102 and
OAK-4103, I want to first get a clearer idea on the bigger picture.
> FileStore.flush prone to races leading to corruption
>
>
> Key: OAK-4291
> URL: https://issues.apache.org/jira/browse/OAK-4291
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Critical
> Labels: resilience
> Fix For: 1.6
>
>
> There is a small window in {{FileStore.flush}} that could lead to data
> corruption: if we crash right after setting the persisted head but before any
> delay-flushed {{SegmentBufferWriter}} instance flushes (see
> {{SegmentBufferWriterPool.returnWriter()}}) then that data is lost although
> it might already be referenced from the persisted head.
> We need to come up with a test case for this.
> A possible fix would be to return a future from {{SegmentWriter.flush}} and
> rely on a completion callback. Such a change would most likely also be useful
> for OAK-3690.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4291) FileStore.flush prone to races leading to corruption
[
https://issues.apache.org/jira/browse/OAK-4291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15279902#comment-15279902
]
Michael Dürig commented on OAK-4291:
TBH I have no idea how to reasonably reproduce this with a test case. For now
I'll try to detail the problem with {{FileStore.flush()}}. Here is the relevant
parts of that method:
{code}
// 1. get the id of the current head state
RecordId after = head.get();
// 2. Flush segment writer to ensure all records currently kept in memory are
on disk
tracker.getWriter().flush();
// 3. Persist the id of the current head state to the journal
journalFile.writeBytes(after.toString10() + " root " +
System.currentTimeMillis()+"\n");
{code}
The problem is with the flush call in 2. being asynchronous. So when we reach
3. flushing might not yet be done. Now if we crash after 3. wrote the id of the
current head node state to the journal but 2. did not yet finish flushing all
respective records we end up corrupted.
The asynchronous flush was introduced as a guard against various dead locks
({{SegmentWriter}} calling {{FileStore#writeSegment}} while holding a lock).
> FileStore.flush prone to races leading to corruption
>
>
> Key: OAK-4291
> URL: https://issues.apache.org/jira/browse/OAK-4291
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Critical
> Labels: resilience
> Fix For: 1.6
>
>
> There is a small window in {{FileStore.flush}} that could lead to data
> corruption: if we crash right after setting the persisted head but before any
> delay-flushed {{SegmentBufferWriter}} instance flushes (see
> {{SegmentBufferWriterPool.returnWriter()}}) then that data is lost although
> it might already be referenced from the persisted head.
> We need to come up with a test case for this.
> A possible fix would be to return a future from {{SegmentWriter.flush}} and
> rely on a completion callback. Such a change would most likely also be useful
> for OAK-3690.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4358) Stale cluster ids can potentially lead to lots of previous docs traversal in NodeDocument.getNewestRevision
Vikas Saurabh created OAK-4358: -- Summary: Stale cluster ids can potentially lead to lots of previous docs traversal in NodeDocument.getNewestRevision Key: OAK-4358 URL: https://issues.apache.org/jira/browse/OAK-4358 Project: Jackrabbit Oak Issue Type: Bug Components: documentmk Reporter: Vikas Saurabh Assignee: Vikas Saurabh When some (actual test case and conditions still being investigated) of the following conditions are met: * There are property value changes from different cluster id * There are very old and stale cluster id (probably older incarnations of current node itself) * A parallel background split removes all _commitRoot, _revision entries such that the latest one (which is less that baseRev) is very old , finding newest revision traverses a lot of previous docs. Since root document gets split a lot and is a very common commitRoot (thus participating during checkConflicts in lot of commits), the issue can slow down commits by a lot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4321) Improve conflict exception message to show if conflict is unexpected
[
https://issues.apache.org/jira/browse/OAK-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277870#comment-15277870
]
Marcel Reutegger edited comment on OAK-4321 at 5/11/16 7:29 AM:
The check is not quite correct, it will report that a revision is older than
the base revision vector when it is actually equal. I think the patch should
look like this:
{noformat}
---
a/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/Commit.java
+++
b/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/Commit.java
@@ -42,6 +42,7 @@ import org.apache.jackrabbit.oak.spi.state.NodeState;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
+import static com.google.common.base.Objects.equal;
import static com.google.common.base.Preconditions.checkNotNull;
import static com.google.common.collect.Iterables.filter;
import static com.google.common.collect.Iterables.transform;
@@ -565,6 +566,10 @@ public class Commit {
private String formatConflictRevision(Revision r) {
if (nodeStore.getHeadRevision().isRevisionNewer(r)) {
return r + " (not yet visible)";
+} else if (baseRevision != null
+&& !baseRevision.isRevisionNewer(r)
+&& !equal(baseRevision.getRevision(r.getClusterId()), r)) {
+return r + " (older than base " + baseRevision + ")";
} else {
return r.toString();
}
{noformat}
was (Author: mreutegg):
The check is not quite correct, it will report that a revision is older than
the base revision vector when it is actually equal. I think the patch should
look like this:
{noformat}
---
a/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/Commit.java
+++
b/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/Commit.java
@@ -42,6 +42,7 @@ import org.apache.jackrabbit.oak.spi.state.NodeState;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
+import static com.google.common.base.Objects.equal;
import static com.google.common.base.Preconditions.checkNotNull;
import static com.google.common.collect.Iterables.filter;
import static com.google.common.collect.Iterables.transform;
@@ -565,6 +566,10 @@ public class Commit {
private String formatConflictRevision(Revision r) {
if (nodeStore.getHeadRevision().isRevisionNewer(r)) {
return r + " (not yet visible)";
+} else if (baseRevision != null
+&& !baseRevision.isRevisionNewer(r)
+&& !equal(baseRevision.getRevision(r.getClusterId()), r)) {
+return r + " (older than base - " + baseRevision + ")";
} else {
return r.toString();
}
{noformat}
> Improve conflict exception message to show if conflict is unexpected
>
>
> Key: OAK-4321
> URL: https://issues.apache.org/jira/browse/OAK-4321
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Vikas Saurabh
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.6, 1.5.2, 1.0.31, 1.2.15, 1.4.3
>
> Attachments: OAK-4321-1.0.diff
>
>
> Merge exception (aka OakMerge) are often expected when concurrent
> sessions do conflicting writes. But in some occasions, we've seen bugs in oak
> which also lead to merge exception.
> This creates confusion during investigation to isolate if it's an issue in
> oak or a genuine concurrent conflict.
> It'd be useful if the exception message has information to distinguish that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4321) Improve conflict exception message to show if conflict is unexpected
[ https://issues.apache.org/jira/browse/OAK-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-4321: -- Labels: (was: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4) Fix Version/s: 1.4.3 1.2.15 1.0.31 Merged into 1.4 branch: http://svn.apache.org/r1743184 Merged into 1.2 branch: http://svn.apache.org/r1743309 Merged into 1.0 branch: http://svn.apache.org/r1743320 > Improve conflict exception message to show if conflict is unexpected > > > Key: OAK-4321 > URL: https://issues.apache.org/jira/browse/OAK-4321 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, documentmk >Reporter: Vikas Saurabh >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.2, 1.0.31, 1.2.15, 1.4.3 > > Attachments: OAK-4321-1.0.diff > > > Merge exception (aka OakMerge) are often expected when concurrent > sessions do conflicting writes. But in some occasions, we've seen bugs in oak > which also lead to merge exception. > This creates confusion during investigation to isolate if it's an issue in > oak or a genuine concurrent conflict. > It'd be useful if the exception message has information to distinguish that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
