[jira] [Commented] (OAK-3476) Memory leak caused by using marker names based on non static session id
[
https://issues.apache.org/jira/browse/OAK-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948122#comment-14948122
]
Chetan Mehrotra commented on OAK-3476:
--
Most likely debug level for audit logger is enabled. Anyway use of Marker is
not appropriate here. Session Id if to be used should be done more with MDC.
Marker are meant to be used with few known names and not with dynamic names
[1]. So what I have done here is "misuse" of the feature. Thinking again we do
not require marker based logging here
[1]
http://stackoverflow.com/questions/4165558/best-practices-for-using-markers-in-slf4j-logback/10231016
> Memory leak caused by using marker names based on non static session id
> ---
>
> Key: OAK-3476
> URL: https://issues.apache.org/jira/browse/OAK-3476
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.8, 1.0.23, 1.2.8
>
>
> {{SessionDelegate}} creates marker based on session id. As session id is
> variable such markers can get accumulated over time resulting in memory leak
> [1]
> {code}
> private static void logOperationDetails(ContentSession session,
> SessionOperation ops) {
> if (readOperationLogger.isTraceEnabled()
> || writeOperationLogger.isTraceEnabled()
> || auditLogger.isDebugEnabled()) {
> Marker sessionMarker =
> MarkerFactory.getMarker(session.toString());
> Logger log = ops.isUpdate() ? writeOperationLogger :
> readOperationLogger;
> log.trace(sessionMarker, "[{}] {}", session, ops);
> {code}
> *Workaround*
> Untill we fix it in code user should just set log level to info for following
> loggers
> * org.apache.jackrabbit.oak.audit
> * org.apache.jackrabbit.oak.jcr.operations.reads
> [1] http://stackoverflow.com/q/31524084/1035417
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3494) MemoryDiffCache should also check parent paths before falling to Loader (or returning null)
[
https://issues.apache.org/jira/browse/OAK-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-3494:
--
Assignee: Marcel Reutegger
Issue Type: Improvement (was: Bug)
Thanks for the patches Vikas. I think it would be good to have the JSOP parsing
in a single place. That is, reuse the existing parsing in
DocumentNodeStore.dispatch().
> MemoryDiffCache should also check parent paths before falling to Loader (or
> returning null)
> ---
>
> Key: OAK-3494
> URL: https://issues.apache.org/jira/browse/OAK-3494
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Marcel Reutegger
> Labels: performance
> Attachments: OAK-3494-TestCase.patch, OAK-3494.patch
>
>
> Each entry in {{MemoryDiffCache}} is keyed with {{(path, fromRev, toRev)}}
> for the list of modified children at {{path}}. A diff calcualted by
> {{DocumentNodeStore.diffImpl}} at '/' (passively via loader) or
> {{JournalEntry.applyTo}} (actively) fill each path for which there are
> modified children (including the hierarchy)
> But, if an observer calls {{compareWithBaseState}} on a unmodified sub-tree,
> the observer will still go down to {{diffImpl}} although cached parent entry
> can be used to answer the query.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3489) DocumentStore: introduce a "NotEquals" condition
[ https://issues.apache.org/jira/browse/OAK-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948213#comment-14948213 ] Marcel Reutegger commented on OAK-3489: --- What is the expected behavior if a property or map entry does not exist for a given notEquals condition and is 'null' a valid value to test against? I think the test in BasicDocumentStoreTest should cover these cases as well. > DocumentStore: introduce a "NotEquals" condition > > > Key: OAK-3489 > URL: https://issues.apache.org/jira/browse/OAK-3489 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0.21, 1.2.6, 1.3.7 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: OAK-3489.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3464) Release Oak 1.0.22
[ https://issues.apache.org/jira/browse/OAK-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella resolved OAK-3464. --- Resolution: Fixed > Release Oak 1.0.22 > -- > > Key: OAK-3464 > URL: https://issues.apache.org/jira/browse/OAK-3464 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Davide Giannella >Assignee: Davide Giannella > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3495) Query engine: disable or restrict built-in full-text engine (backport to 1.0)
[ https://issues.apache.org/jira/browse/OAK-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-3495: Fix Version/s: 1.0.23 > Query engine: disable or restrict built-in full-text engine (backport to 1.0) > - > > Key: OAK-3495 > URL: https://issues.apache.org/jira/browse/OAK-3495 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.0.23 > > > With Oak 1.0.x, the built-in full-text engine is used if no other full-text > index is available. This is different than in newer versions of Oak, where > the built-in engine is disabled in that case by default. > I think it makes sense to backport this to Oak 1.0.x, so that all versions > behave the same way. > This is to prevent out-of-memory problems if no full-text index is configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3495) Query engine: disable or restrict built-in full-text engine (backport to 1.0)
Thomas Mueller created OAK-3495: --- Summary: Query engine: disable or restrict built-in full-text engine (backport to 1.0) Key: OAK-3495 URL: https://issues.apache.org/jira/browse/OAK-3495 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Thomas Mueller Assignee: Thomas Mueller With Oak 1.0.x, the built-in full-text engine is used if no other full-text index is available. This is different than in newer versions of Oak, where the built-in engine is disabled in that case by default. I think it makes sense to backport this to Oak 1.0.x, so that all versions behave the same way. This is to prevent out-of-memory problems if no full-text index is configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3494) MemoryDiffCache should also check parent paths before falling to Loader (or returning null)
[
https://issues.apache.org/jira/browse/OAK-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948335#comment-14948335
]
Stefan Egli commented on OAK-3494:
--
I was gonna suggest to add more test cases as false-positives would mean wrong
diff calculation..
> MemoryDiffCache should also check parent paths before falling to Loader (or
> returning null)
> ---
>
> Key: OAK-3494
> URL: https://issues.apache.org/jira/browse/OAK-3494
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Marcel Reutegger
> Labels: performance
> Attachments: OAK-3494-TestCase.patch, OAK-3494.patch
>
>
> Each entry in {{MemoryDiffCache}} is keyed with {{(path, fromRev, toRev)}}
> for the list of modified children at {{path}}. A diff calcualted by
> {{DocumentNodeStore.diffImpl}} at '/' (passively via loader) or
> {{JournalEntry.applyTo}} (actively) fill each path for which there are
> modified children (including the hierarchy)
> But, if an observer calls {{compareWithBaseState}} on a unmodified sub-tree,
> the observer will still go down to {{diffImpl}} although cached parent entry
> can be used to answer the query.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3496) Release Oak 1.3.8
Davide Giannella created OAK-3496: - Summary: Release Oak 1.3.8 Key: OAK-3496 URL: https://issues.apache.org/jira/browse/OAK-3496 Project: Jackrabbit Oak Issue Type: Task Reporter: Davide Giannella Assignee: Davide Giannella - release oak - update website - update javadoc -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3476) Memory leak caused by using marker names based on non static session id
[
https://issues.apache.org/jira/browse/OAK-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-3476.
--
Resolution: Fixed
Removed use of marker
* trunk - 1707435
* 1.0 - 1707436
* 1.2 - 1707437
> Memory leak caused by using marker names based on non static session id
> ---
>
> Key: OAK-3476
> URL: https://issues.apache.org/jira/browse/OAK-3476
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.3.8, 1.0.23, 1.2.8
>
>
> {{SessionDelegate}} creates marker based on session id. As session id is
> variable such markers can get accumulated over time resulting in memory leak
> [1]
> {code}
> private static void logOperationDetails(ContentSession session,
> SessionOperation ops) {
> if (readOperationLogger.isTraceEnabled()
> || writeOperationLogger.isTraceEnabled()
> || auditLogger.isDebugEnabled()) {
> Marker sessionMarker =
> MarkerFactory.getMarker(session.toString());
> Logger log = ops.isUpdate() ? writeOperationLogger :
> readOperationLogger;
> log.trace(sessionMarker, "[{}] {}", session, ops);
> {code}
> *Workaround*
> Untill we fix it in code user should just set log level to info for following
> loggers
> * org.apache.jackrabbit.oak.audit
> * org.apache.jackrabbit.oak.jcr.operations.reads
> [1] http://stackoverflow.com/q/31524084/1035417
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-3453) Adapt the default configuration of SecurityProviderRegistration for older versions of Oak
[
https://issues.apache.org/jira/browse/OAK-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-3453.
-
Bulk close for 1.0.22
> Adapt the default configuration of SecurityProviderRegistration for older
> versions of Oak
> -
>
> Key: OAK-3453
> URL: https://issues.apache.org/jira/browse/OAK-3453
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.0.21
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.0.22
>
>
> The default OSGi configuration of {{SecurityProviderRegistration}} lists some
> PIDs that are not available across every version of Oak. In particular,
> {{o.a.j.o.security.user.UserAuthenticationFactoryImpl}} is not available in
> Oak 1.0.x. The default configuration should be adapted to the default
> security component currently exposed by the given version of Oak.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (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:all-tabpanel
]
Davide Giannella closed OAK-2929.
-
Bulk close for 1.0.22
> 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.3.8, 1.2.7, 1.0.22
>
> 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] [Closed] (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
]
Davide Giannella closed OAK-3396.
-
Bulk close for 1.0.22
> 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: Blocker
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> 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] [Closed] (OAK-3388) Inconsistent read in cluster with clock differences
[ https://issues.apache.org/jira/browse/OAK-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-3388. - Bulk close for 1.0.22 > 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 > Labels: resilience > Fix For: 1.3.8, 1.2.7, 1.0.22 > > Attachments: OAK-3388.patch, OAK-3388.patch > > > 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] [Closed] (OAK-3454) Improve the logging capabilities of offline compaction
[
https://issues.apache.org/jira/browse/OAK-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-3454.
-
Bulk close for 1.0.22
> Improve the logging capabilities of offline compaction
> --
>
> Key: OAK-3454
> URL: https://issues.apache.org/jira/browse/OAK-3454
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, run
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Labels: compaction, gc
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: OAK-3454-01.patch
>
>
> The offline compaction instantiates {{FileStore}} using a deprecated
> constructor. This constructor forces a no-op {{GCMonitor}} that swallows log
> messages and caught exception.
> It would be more appropriate to create the {{FileStore}} using the
> corresponding {{Builder}}. This has the side effect of configuring a
> {{LoggingGCMonitor}}, which provides way more information than the current
> default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-3417) oak-run OakFixture might set incorrect clusterIDs
[
https://issues.apache.org/jira/browse/OAK-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-3417.
-
Bulk close for 1.0.22
> oak-run OakFixture might set incorrect clusterIDs
> -
>
> Key: OAK-3417
> URL: https://issues.apache.org/jira/browse/OAK-3417
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Affects Versions: 1.0.21, 1.2.6, 1.3.7
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
>
> Seen in OakFixture.java:
> {code}
> @Override
> public Oak[] setUpCluster(int n) throws Exception {
> Oak[] cluster = new Oak[n];
> kernels = new DocumentMK[cluster.length];
> for (int i = 0; i < cluster.length; i++) {
> MongoConnection mongo = new MongoConnection(uri);
> DocumentMK.Builder mkBuilder = new DocumentMK.Builder().
> setMongoDB(mongo.getDB()).
> memoryCacheSize(cacheSize).
> setPersistentCache("target/persistentCache,time").
> setClusterId(i).
> setLogging(false);
> setupBlobStore(mkBuilder);
> kernels[i] = mkBuilder.open();
> cluster[i] = newOak(kernels[i].getNodeStore());
> }
> return cluster;
> }
> {code}
> ...however, {{setClusterId(0)}} is special (it generates it automatically}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process
[
https://issues.apache.org/jira/browse/OAK-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-3311.
-
Bulk close for 1.0.22
> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is
> an uncaught NPE.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3489) DocumentStore: introduce a "NotEquals" condition
[ https://issues.apache.org/jira/browse/OAK-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948257#comment-14948257 ] Julian Reschke commented on OAK-3489: - It would evaluate to true. Will add documentation and more tests. > DocumentStore: introduce a "NotEquals" condition > > > Key: OAK-3489 > URL: https://issues.apache.org/jira/browse/OAK-3489 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0.21, 1.2.6, 1.3.7 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: OAK-3489.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3494) MemoryDiffCache should also check parent paths before falling to Loader (or returning null)
[
https://issues.apache.org/jira/browse/OAK-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948279#comment-14948279
]
Marcel Reutegger commented on OAK-3494:
---
Yes, we have to extract the parsing. We cannot reuse the dispatch method as is
in MemoryDiffCache.
> MemoryDiffCache should also check parent paths before falling to Loader (or
> returning null)
> ---
>
> Key: OAK-3494
> URL: https://issues.apache.org/jira/browse/OAK-3494
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Marcel Reutegger
> Labels: performance
> Attachments: OAK-3494-TestCase.patch, OAK-3494.patch
>
>
> Each entry in {{MemoryDiffCache}} is keyed with {{(path, fromRev, toRev)}}
> for the list of modified children at {{path}}. A diff calcualted by
> {{DocumentNodeStore.diffImpl}} at '/' (passively via loader) or
> {{JournalEntry.applyTo}} (actively) fill each path for which there are
> modified children (including the hierarchy)
> But, if an observer calls {{compareWithBaseState}} on a unmodified sub-tree,
> the observer will still go down to {{diffImpl}} although cached parent entry
> can be used to answer the query.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3497) Remove DocumentNodeStore.diff()
Marcel Reutegger created OAK-3497: - Summary: Remove DocumentNodeStore.diff() Key: OAK-3497 URL: https://issues.apache.org/jira/browse/OAK-3497 Project: Jackrabbit Oak Issue Type: Improvement Components: core, mongomk Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor Fix For: 1.3.8 The method is only used by the DocumentMK class, which is now considered a test helper and part of the API anymore. The method should be removed from the DocumentNodeStore and functionality moved to the DocumentMK.find() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3497) Remove DocumentNodeStore.diff()
[ https://issues.apache.org/jira/browse/OAK-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3497: -- Description: The method is only used by the DocumentMK class, which is now considered a test helper (OAK-2907) and part of the API anymore. The method should be removed from the DocumentNodeStore and functionality moved to the DocumentMK.find() method. was: The method is only used by the DocumentMK class, which is now considered a test helper and part of the API anymore. The method should be removed from the DocumentNodeStore and functionality moved to the DocumentMK.find() method. > Remove DocumentNodeStore.diff() > --- > > Key: OAK-3497 > URL: https://issues.apache.org/jira/browse/OAK-3497 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: technical_debt > Fix For: 1.3.8 > > > The method is only used by the DocumentMK class, which is now considered a > test helper (OAK-2907) and part of the API anymore. > The method should be removed from the DocumentNodeStore and functionality > moved to the DocumentMK.find() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3494) MemoryDiffCache should also check parent paths before falling to Loader (or returning null)
[
https://issues.apache.org/jira/browse/OAK-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948220#comment-14948220
]
Vikas Saurabh edited comment on OAK-3494 at 10/8/15 7:45 AM:
-
[~mreutegg], I'm not sure if I follow. DocumentNodeStore.dispath() deals with
node state and sends childNodeState as well while calling back
diff.childNodeAdded/Changed. Memory diff cache only is dealing with paths and
child names as strings. Did you mean that we should extract parsing logic out
to some *Util and both DocumentNodeStore and MemoryDiff should use that?
was (Author: catholicon):
I'm not sure if I follow. DocumentNodeStore.dispath() deals with node state and
sends childNodeState as well while calling back diff.childNodeAdded/Changed.
Memory diff cache only is dealing with paths and child names as strings. Did
you mean that we should extract parsing logic out to some *Util and both
DocumentNodeStore and MemoryDiff should use that?
> MemoryDiffCache should also check parent paths before falling to Loader (or
> returning null)
> ---
>
> Key: OAK-3494
> URL: https://issues.apache.org/jira/browse/OAK-3494
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Marcel Reutegger
> Labels: performance
> Attachments: OAK-3494-TestCase.patch, OAK-3494.patch
>
>
> Each entry in {{MemoryDiffCache}} is keyed with {{(path, fromRev, toRev)}}
> for the list of modified children at {{path}}. A diff calcualted by
> {{DocumentNodeStore.diffImpl}} at '/' (passively via loader) or
> {{JournalEntry.applyTo}} (actively) fill each path for which there are
> modified children (including the hierarchy)
> But, if an observer calls {{compareWithBaseState}} on a unmodified sub-tree,
> the observer will still go down to {{diffImpl}} although cached parent entry
> can be used to answer the query.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3494) MemoryDiffCache should also check parent paths before falling to Loader (or returning null)
[
https://issues.apache.org/jira/browse/OAK-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948220#comment-14948220
]
Vikas Saurabh commented on OAK-3494:
I'm not sure if I follow. DocumentNodeStore.dispath() deals with node state and
sends childNodeState as well while calling back diff.childNodeAdded/Changed.
Memory diff cache only is dealing with paths and child names as strings. Did
you mean that we should extract parsing logic out to some *Util and both
DocumentNodeStore and MemoryDiff should use that?
> MemoryDiffCache should also check parent paths before falling to Loader (or
> returning null)
> ---
>
> Key: OAK-3494
> URL: https://issues.apache.org/jira/browse/OAK-3494
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Marcel Reutegger
> Labels: performance
> Attachments: OAK-3494-TestCase.patch, OAK-3494.patch
>
>
> Each entry in {{MemoryDiffCache}} is keyed with {{(path, fromRev, toRev)}}
> for the list of modified children at {{path}}. A diff calcualted by
> {{DocumentNodeStore.diffImpl}} at '/' (passively via loader) or
> {{JournalEntry.applyTo}} (actively) fill each path for which there are
> modified children (including the hierarchy)
> But, if an observer calls {{compareWithBaseState}} on a unmodified sub-tree,
> the observer will still go down to {{diffImpl}} although cached parent entry
> can be used to answer the query.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3236) integration test that simulates influence of clock drift
[ https://issues.apache.org/jira/browse/OAK-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated OAK-3236: - Fix Version/s: (was: 1.3.8) 1.3.9 > integration test that simulates influence of clock drift > > > Key: OAK-3236 > URL: https://issues.apache.org/jira/browse/OAK-3236 > Project: Jackrabbit Oak > Issue Type: Test > Components: core >Affects Versions: 1.3.4 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: 1.3.9 > > > Spin-off of OAK-2739 [of this > comment|https://issues.apache.org/jira/browse/OAK-2739?focusedCommentId=14693398=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14693398] > - ie there should be an integration test that show cases the issues with > clock drift and why it is a good idea to have a lease-check (that refuses to > let the document store be used any further once the lease times out locally) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3001) Simplify JournalGarbageCollector using a dedicated timestamp property
[
https://issues.apache.org/jira/browse/OAK-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-3001:
-
Fix Version/s: (was: 1.3.8)
1.3.9
> Simplify JournalGarbageCollector using a dedicated timestamp property
> -
>
> Key: OAK-3001
> URL: https://issues.apache.org/jira/browse/OAK-3001
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, mongomk
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Critical
> Labels: scalability
> Fix For: 1.3.9, 1.2.8
>
>
> This subtask is about spawning out a
> [comment|https://issues.apache.org/jira/browse/OAK-2829?focusedCommentId=14585733=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14585733]
> from [~chetanm] re JournalGC:
> {quote}
> Further looking at JournalGarbageCollector ... it would be simpler if you
> record the journal entry timestamp as an attribute in JournalEntry document
> and then you can delete all the entries which are older than some time by a
> simple query. This would avoid fetching all the entries to be deleted on the
> Oak side
> {quote}
> and a corresponding
> [reply|https://issues.apache.org/jira/browse/OAK-2829?focusedCommentId=14585870=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14585870]
> from myself:
> {quote}
> Re querying by timestamp: that would indeed be simpler. With the current set
> of DocumentStore API however, I believe this is not possible. But:
> [DocumentStore.query|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentStore.java#L127]
> comes quite close: it would probably just require the opposite of that
> method too:
> {code}
> public List query(Collection collection,
> String fromKey,
> String toKey,
> String indexedProperty,
> long endValue,
> int limit) {
> {code}
> .. or what about generalizing this method to have both a {{startValue}} and
> an {{endValue}} - with {{-1}} indicating when one of them is not used?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2844) Introducing a simple document-based discovery-light service (to circumvent documentMk's eventual consistency delays)
[
https://issues.apache.org/jira/browse/OAK-2844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948544#comment-14948544
]
Stefan Egli commented on OAK-2844:
--
Note: OAK-3492 must also be backported once OAK-2844 would be backported to 1.2
branch
> Introducing a simple document-based discovery-light service (to circumvent
> documentMk's eventual consistency delays)
>
>
> Key: OAK-2844
> URL: https://issues.apache.org/jira/browse/OAK-2844
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mongomk
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: resilience
> Fix For: 1.3.5
>
> Attachments: InstanceStateChangeListener.java, OAK-2844.WIP-02.patch,
> OAK-2844.patch, OAK-2844.v3.patch, OAK-2844.v4.patch
>
>
> When running discovery.impl on a mongoMk-backed jcr repository, there are
> risks of hitting problems such as described in "SLING-3432
> pseudo-network-partitioning": this happens when a jcr-level heartbeat does
> not reach peers within the configured heartbeat timeout - it then treats that
> affected instance as dead, removes it from the topology, and continues with
> the remainings, potentially electing a new leader, running the risk of
> duplicate leaders. This happens when delays in mongoMk grow larger than the
> (configured) heartbeat timeout. These problems ultimately are due to the
> 'eventual consistency' nature of, not only mongoDB, but more so of mongoMk.
> The only alternative so far is to increase the heartbeat timeout to match the
> expected or measured delays that mongoMk can produce (under say given
> load/performance scenarios).
> Assuming that mongoMk will always carry a risk of certain delays and a
> maximum, reasonable (for discovery.impl timeout that is) maximum cannot be
> guaranteed, a better solution is to provide discovery with more 'real-time'
> like information and/or privileged access to mongoDb.
> Here's a summary of alternatives that have so far been floating around as a
> solution to circumvent eventual consistency:
> # expose existing (jmx) information about active 'clusterIds' - this has
> been proposed in SLING-4603. The pros: reuse of existing functionality. The
> cons: going via jmx, binding of exposed functionality as 'to be maintained
> API'
> # expose a plain mongo db/collection (via osgi injection) such that a higher
> (sling) level discovery could directly write heartbeats there. The pros:
> heartbeat latency would be minimal (assuming the collection is not sharded).
> The cons: exposes a mongo db/collection potentially also to anyone else, with
> the risk of opening up to unwanted possibilities
> # introduce a simple 'discovery-light' API to oak which solely provides
> information about which instances are active in a cluster. The implementation
> of this is not exposed. The pros: no need to expose a mongoDb/collection,
> allows any other jmx-functionality to remain unchanged. The cons: a new API
> that must be maintained
> This ticket is about the 3rd option, about a new mongo-based discovery-light
> service that is introduced to oak. The functionality in short:
> * it defines a 'local instance id' that is non-persisted, ie can change at
> each bundle activation.
> * it defines a 'view id' that uniquely identifies a particular incarnation
> of a 'cluster view/state' (which is: a list of active instance ids)
> * and it defines a list of active instance ids
> * the above attributes are passed to interested components via a listener
> that can be registered. that listener is called whenever the discovery-light
> notices the cluster view has changed.
> While the actual implementation could in fact be based on the existing
> {{getActiveClusterNodes()}} {{getClusterId()}} of the
> {{DocumentNodeStoreMBean}}, the suggestion is to not fiddle with that part,
> as that has dependencies to other logic. But instead, the suggestion is to
> create a dedicated, other, collection ('discovery') where heartbeats as well
> as the currentView are stored.
> Will attach a suggestion for an initial version of this for review.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3497) Remove DocumentNodeStore.diff()
[ https://issues.apache.org/jira/browse/OAK-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-3497. --- Resolution: Fixed Done in trunk: http://svn.apache.org/r1707467 > Remove DocumentNodeStore.diff() > --- > > Key: OAK-3497 > URL: https://issues.apache.org/jira/browse/OAK-3497 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: technical_debt > Fix For: 1.3.8 > > > The method is only used by the DocumentMK class, which is now considered a > test helper (OAK-2907) and part of the API anymore. > The method should be removed from the DocumentNodeStore and functionality > moved to the DocumentMK.find() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3494) MemoryDiffCache should also check parent paths before falling to Loader (or returning null)
[
https://issues.apache.org/jira/browse/OAK-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948553#comment-14948553
]
Marcel Reutegger commented on OAK-3494:
---
Moved parsing of the diff cache jsop into a static method:
http://svn.apache.org/r1707509
> MemoryDiffCache should also check parent paths before falling to Loader (or
> returning null)
> ---
>
> Key: OAK-3494
> URL: https://issues.apache.org/jira/browse/OAK-3494
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Marcel Reutegger
> Labels: performance
> Attachments: OAK-3494-TestCase.patch, OAK-3494.patch
>
>
> Each entry in {{MemoryDiffCache}} is keyed with {{(path, fromRev, toRev)}}
> for the list of modified children at {{path}}. A diff calcualted by
> {{DocumentNodeStore.diffImpl}} at '/' (passively via loader) or
> {{JournalEntry.applyTo}} (actively) fill each path for which there are
> modified children (including the hierarchy)
> But, if an observer calls {{compareWithBaseState}} on a unmodified sub-tree,
> the observer will still go down to {{diffImpl}} although cached parent entry
> can be used to answer the query.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3492) reduce DocumentDiscoveryLiteService hasBacklog WARNs
[
https://issues.apache.org/jira/browse/OAK-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved OAK-3492.
--
Resolution: Fixed
added a version-check in revision 1707508.
Note: this must be adjusted when backporting the OAK-2844-feature to the 1.2
branch...
/cc [~catholicon]
> reduce DocumentDiscoveryLiteService hasBacklog WARNs
>
>
> Key: OAK-3492
> URL: https://issues.apache.org/jira/browse/OAK-3492
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.7
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.3.8
>
>
> With DocumentDiscoveryLiteService in 1.3.7 the following WARN has been
> noticed:
> {code}
> 07.10.2015 06:38:16.575 *TRACE*
> [DocumentDiscoveryLiteService-BackgroundWorker-[4]]
> org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteService
> hasBacklog: start. clusterNodeId: 1
> 07.10.2015 06:38:16.575 *TRACE*
> [DocumentDiscoveryLiteService-BackgroundWorker-[4]]
> org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteService
> getLastKnownRevision: end. clusterNode:
> 1, lastKnownRevision: r14e0c0898cc-0-1
> 07.10.2015 06:38:16.575 *WARN*
> [DocumentDiscoveryLiteService-BackgroundWorker-[4]]
> org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteService
> hasBacklog: node has lastWrittenRootRev=
> null
> {code}
> This happens every 5sec. While the warning is somewhat legitimate as it
> cannot determine the backlog of a not-active instance - it is spam if it
> occurs every 5sec. So rather than warning constantly, there should only be
> one warning and then a fall-back to log.debug afterwards.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3495) Query engine: disable or restrict built-in full-text engine (backport to 1.0)
[ https://issues.apache.org/jira/browse/OAK-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948637#comment-14948637 ] Thomas Mueller edited comment on OAK-3495 at 10/8/15 1:24 PM: -- [~alex.parvulescu] and [~edivad], could you please review the above patch? It is really just to prevent OOME. First I thought we should also disable the built-in engine, but now I see it would require more changes. The above code should match the Oak 1.2 and newer behavior _if_ the built-in engine would be enabled there, _and_ no (Lucene or Solr) index is available. This is the case for some of the unit tests, and (for a very short time) just after creating a new Oak repository, at the very first startup. was (Author: tmueller): [~alex.parvulescu] and [~edivad], could you please review the above patch? It is really just to prevent OOME. First I thought we should also disable the built-in engine, but now I see it would require more changes. The above code should match the Oak 1.2 and newer behavior _if_ the built-in engine would be enabled there. This is the case for some of the unit tests. > Query engine: disable or restrict built-in full-text engine (backport to 1.0) > - > > Key: OAK-3495 > URL: https://issues.apache.org/jira/browse/OAK-3495 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.0.23 > > > With Oak 1.0.x, the built-in full-text engine is used if no other full-text > index is available. This is different than in newer versions of Oak, where > the built-in engine is disabled in that case by default. > I think it makes sense to backport this to Oak 1.0.x, so that all versions > behave the same way. > This is to prevent out-of-memory problems if no full-text index is configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3498) DN can't be used as the group name in the external auth handler
Tomek Rękawek created OAK-3498:
--
Summary: DN can't be used as the group name in the external auth
handler
Key: OAK-3498
URL: https://issues.apache.org/jira/browse/OAK-3498
Project: Jackrabbit Oak
Issue Type: Bug
Components: auth-external
Affects Versions: 1.0.22, 1.3.7, 1.2.7
Reporter: Tomek Rękawek
Priority: Critical
One of the users wants to migrate his repository from Jackrabbit 2 to Oak. He
uses LDAP for authentication. The LDAP synchronization in Jackrabbit 2 is
configured in such manner, that both principal id and authorizable name is set
to the DN (eg. {{CN=my-group,OU=abc,...}}).
After migration to Oak LDAP users can't login. The reason is that during the
login, the {{DefaultSyncContext}} tries to synchronize all groups memberships
and create missing groups. By default it uses CN as the group name and tries to
find it. It fails, because the migrated group has a name created with its DN.
It assumes that the group doesn't exist and then wants to create it - which
fails as well, because group with the given principal name already exists. As a
result, the whole login process fails.
The LDAP attribute to be used as the group name can be configured. However, the
DN is not an attribute, so setting {{group.nameAttribute="dn"}} in
{{LdapProviderConfig}} results in a {{NullPointerException}}.
I think two things can be improved here:
1. {{DefaultSyncContext}} should try to find a group using its principal name
rather than group id.
2. It should be possible to use DN as the {{group.nameAttribute}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3489) DocumentStore: introduce a "NotEquals" condition
[ https://issues.apache.org/jira/browse/OAK-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3489: Attachment: OAK-3489.diff [~mreutegg]: updated javadoc and test cases > DocumentStore: introduce a "NotEquals" condition > > > Key: OAK-3489 > URL: https://issues.apache.org/jira/browse/OAK-3489 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0.21, 1.2.6, 1.3.7 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: OAK-3489.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3495) Query engine: disable or restrict built-in full-text engine (backport to 1.0)
[
https://issues.apache.org/jira/browse/OAK-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948626#comment-14948626
]
Thomas Mueller commented on OAK-3495:
-
I found out that _disabling_ the built-in full-text engine would require
changing quite many tests (that means, also backport changes to the tests).
That would be possible, but would require more changes.
The following patch just _restricts_ the built-in full-text engine to String
only. That means binaries are not read. This should avoid out-of-memory. It is
the same code as used in Oak 1.2.x and newer.
{noformat}
oak-core
===
--- src/main/java/org/apache/jackrabbit/oak/query/ast/FullTextSearchImpl.java
(revision 1707457)
+++ src/main/java/org/apache/jackrabbit/oak/query/ast/FullTextSearchImpl.java
(working copy)
@@ -215,13 +215,23 @@
private static void appendString(StringBuilder buff, PropertyValue p) {
if (p.isArray()) {
-for (String v : p.getValue(STRINGS)) {
-buff.append(v).append(' ');
+if (p.getType() == Type.BINARIES) {
+// OAK-3495: don't try to load binaries as this would
+// run out of memory
+} else {
+for (String v : p.getValue(STRINGS)) {
+buff.append(v).append(' ');
+}
}
} else {
-buff.append(p.getValue(STRING)).append(' ');
+if (p.getType() == Type.BINARY) {
+// OAK-3495: don't try to load binaries as this would
+// run out of memory
+} else {
+buff.append(p.getValue(STRING)).append(' ');
+}
}
-}
+}
public void bindSelector(SourceImpl source) {
selector = source.getExistingSelector(selectorName);
{noformat}
> Query engine: disable or restrict built-in full-text engine (backport to 1.0)
> -
>
> Key: OAK-3495
> URL: https://issues.apache.org/jira/browse/OAK-3495
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.0.23
>
>
> With Oak 1.0.x, the built-in full-text engine is used if no other full-text
> index is available. This is different than in newer versions of Oak, where
> the built-in engine is disabled in that case by default.
> I think it makes sense to backport this to Oak 1.0.x, so that all versions
> behave the same way.
> This is to prevent out-of-memory problems if no full-text index is configured.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3494) MemoryDiffCache should also check parent paths before falling to Loader (or returning null)
[
https://issues.apache.org/jira/browse/OAK-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948665#comment-14948665
]
Vikas Saurabh commented on OAK-3494:
Thanks for the refactor Marcel. I'd incorporate the changes (using static
JsonParser) and a couple of more tests soon.
> MemoryDiffCache should also check parent paths before falling to Loader (or
> returning null)
> ---
>
> Key: OAK-3494
> URL: https://issues.apache.org/jira/browse/OAK-3494
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Marcel Reutegger
> Labels: performance
> Attachments: OAK-3494-TestCase.patch, OAK-3494.patch
>
>
> Each entry in {{MemoryDiffCache}} is keyed with {{(path, fromRev, toRev)}}
> for the list of modified children at {{path}}. A diff calcualted by
> {{DocumentNodeStore.diffImpl}} at '/' (passively via loader) or
> {{JournalEntry.applyTo}} (actively) fill each path for which there are
> modified children (including the hierarchy)
> But, if an observer calls {{compareWithBaseState}} on a unmodified sub-tree,
> the observer will still go down to {{diffImpl}} although cached parent entry
> can be used to answer the query.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3489) DocumentStore: introduce a "NotEquals" condition
[ https://issues.apache.org/jira/browse/OAK-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3489: Attachment: (was: OAK-3489.diff) > DocumentStore: introduce a "NotEquals" condition > > > Key: OAK-3489 > URL: https://issues.apache.org/jira/browse/OAK-3489 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0.21, 1.2.6, 1.3.7 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3495) Query engine: disable or restrict built-in full-text engine (backport to 1.0)
[ https://issues.apache.org/jira/browse/OAK-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948637#comment-14948637 ] Thomas Mueller commented on OAK-3495: - [~alex.parvulescu] and [~edivad], could you please review the above patch? It is really just to prevent OOME. First I thought we should also disable the built-in engine, but now I see it would require more changes. The above code should match the Oak 1.2 and newer behavior _if_ the built-in engine would be enabled there. This is the case for some of the unit tests. > Query engine: disable or restrict built-in full-text engine (backport to 1.0) > - > > Key: OAK-3495 > URL: https://issues.apache.org/jira/browse/OAK-3495 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.0.23 > > > With Oak 1.0.x, the built-in full-text engine is used if no other full-text > index is available. This is different than in newer versions of Oak, where > the built-in engine is disabled in that case by default. > I think it makes sense to backport this to Oak 1.0.x, so that all versions > behave the same way. > This is to prevent out-of-memory problems if no full-text index is configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3480) Query engine: faster cost calculation (take 2)
[ https://issues.apache.org/jira/browse/OAK-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948710#comment-14948710 ] Thomas Mueller commented on OAK-3480: - Also, the NodeType index is asked unnecessarily if the property index returns cost of 2 (that is, with a unique index, and a lookup). One example is a UUID lookup query (where UUID = x). > Query engine: faster cost calculation (take 2) > -- > > Key: OAK-3480 > URL: https://issues.apache.org/jira/browse/OAK-3480 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.3.8 > > > OAK-2679 improves cost calculation, however there is a small bug in the code > that prevents the usage of getMinimumCost. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3498) DN can't be used as the group name in the external auth handler
[
https://issues.apache.org/jira/browse/OAK-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-3498:
---
Attachment: OAK-3498-trunk.patch
OAK-3498-1.0.patch
Patches attached. The {{-trunk}} version can be applied on the 1.2 branch too.
> DN can't be used as the group name in the external auth handler
> ---
>
> Key: OAK-3498
> URL: https://issues.apache.org/jira/browse/OAK-3498
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.3.7, 1.2.7, 1.0.22
>Reporter: Tomek Rękawek
>Priority: Critical
> Attachments: OAK-3498-1.0.patch, OAK-3498-trunk.patch
>
>
> One of the users wants to migrate his repository from Jackrabbit 2 to Oak. He
> uses LDAP for authentication. The LDAP synchronization in Jackrabbit 2 is
> configured in such manner, that both principal id and authorizable name is
> set to the DN (eg. {{CN=my-group,OU=abc,...}}).
> After migration to Oak LDAP users can't login. The reason is that during the
> login, the {{DefaultSyncContext}} tries to synchronize all groups memberships
> and create missing groups. By default it uses CN as the group name and tries
> to find it. It fails, because the migrated group has a name created with its
> DN. It assumes that the group doesn't exist and then wants to create it -
> which fails as well, because group with the given principal name already
> exists. As a result, the whole login process fails.
> The LDAP attribute to be used as the group name can be configured. However,
> the DN is not an attribute, so setting {{group.nameAttribute="dn"}} in
> {{LdapProviderConfig}} results in a {{NullPointerException}}.
> I think two things can be improved here:
> 1. {{DefaultSyncContext}} should try to find a group using its principal name
> rather than group id.
> 2. It should be possible to use DN as the {{group.nameAttribute}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3489) DocumentStore: introduce a "NotEquals" condition
[ https://issues.apache.org/jira/browse/OAK-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948751#comment-14948751 ] Marcel Reutegger commented on OAK-3489: --- Your proposal does not allow to create a notEquals condition with a null value. Is there a specific reason why this is not possible or just an oversight? An additional exists condition on a property may also be needed, but it's probably better to create a separate issue. Right now the API only allows to check existence of a map entry, which means even with this enhancement it is not possible to create a condition update with a check that a property exists but is not equal to some value. The not equal check is not sufficient because it evaluates to true when the property is absent. WDYT? > DocumentStore: introduce a "NotEquals" condition > > > Key: OAK-3489 > URL: https://issues.apache.org/jira/browse/OAK-3489 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0.21, 1.2.6, 1.3.7 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: OAK-3489.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3498) DN can't be used as the group name in the external auth handler
[
https://issues.apache.org/jira/browse/OAK-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-3498:
Priority: Major (was: Critical)
> DN can't be used as the group name in the external auth handler
> ---
>
> Key: OAK-3498
> URL: https://issues.apache.org/jira/browse/OAK-3498
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.3.7, 1.2.7, 1.0.22
>Reporter: Tomek Rękawek
> Attachments: OAK-3498-1.0.patch, OAK-3498-trunk.patch
>
>
> One of the users wants to migrate his repository from Jackrabbit 2 to Oak. He
> uses LDAP for authentication. The LDAP synchronization in Jackrabbit 2 is
> configured in such manner, that both principal id and authorizable name is
> set to the DN (eg. {{CN=my-group,OU=abc,...}}).
> After migration to Oak LDAP users can't login. The reason is that during the
> login, the {{DefaultSyncContext}} tries to synchronize all groups memberships
> and create missing groups. By default it uses CN as the group name and tries
> to find it. It fails, because the migrated group has a name created with its
> DN. It assumes that the group doesn't exist and then wants to create it -
> which fails as well, because group with the given principal name already
> exists. As a result, the whole login process fails.
> The LDAP attribute to be used as the group name can be configured. However,
> the DN is not an attribute, so setting {{group.nameAttribute="dn"}} in
> {{LdapProviderConfig}} results in a {{NullPointerException}}.
> I think two things can be improved here:
> 1. {{DefaultSyncContext}} should try to find a group using its principal name
> rather than group id.
> 2. It should be possible to use DN as the {{group.nameAttribute}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3498) DN can't be used as the group name in the external auth handler
[
https://issues.apache.org/jira/browse/OAK-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948806#comment-14948806
]
angela commented on OAK-3498:
-
not sure about the patch... according to your description this seems to be a
migration issue... i would rather not make the regular code complicated for
something that should be fixed during upgrade (assuming that it was a conscious
decision to no longer allow to use the dn as the group id). also the patch
looks a bit hacky to me...
so, i would suggest that we first clarify the limitation mentioned in the
subject really needs to be addressed and clearly understand the consequences of
doing this before considering on how to address it.
btw: 'groupname' is a bit confusing as the underlying API doesn't know anything
about the name. you are properly referring to the id, right?
> DN can't be used as the group name in the external auth handler
> ---
>
> Key: OAK-3498
> URL: https://issues.apache.org/jira/browse/OAK-3498
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.3.7, 1.2.7, 1.0.22
>Reporter: Tomek Rękawek
>Priority: Critical
> Attachments: OAK-3498-1.0.patch, OAK-3498-trunk.patch
>
>
> One of the users wants to migrate his repository from Jackrabbit 2 to Oak. He
> uses LDAP for authentication. The LDAP synchronization in Jackrabbit 2 is
> configured in such manner, that both principal id and authorizable name is
> set to the DN (eg. {{CN=my-group,OU=abc,...}}).
> After migration to Oak LDAP users can't login. The reason is that during the
> login, the {{DefaultSyncContext}} tries to synchronize all groups memberships
> and create missing groups. By default it uses CN as the group name and tries
> to find it. It fails, because the migrated group has a name created with its
> DN. It assumes that the group doesn't exist and then wants to create it -
> which fails as well, because group with the given principal name already
> exists. As a result, the whole login process fails.
> The LDAP attribute to be used as the group name can be configured. However,
> the DN is not an attribute, so setting {{group.nameAttribute="dn"}} in
> {{LdapProviderConfig}} results in a {{NullPointerException}}.
> I think two things can be improved here:
> 1. {{DefaultSyncContext}} should try to find a group using its principal name
> rather than group id.
> 2. It should be possible to use DN as the {{group.nameAttribute}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3489) DocumentStore: introduce a "NotEquals" condition
[ https://issues.apache.org/jira/browse/OAK-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948994#comment-14948994 ] Julian Reschke commented on OAK-3489: - notEquals(null) - haven't thought of that. The implemented functionality should be sufficient for acquiring the lock: you want to check that the lock is not taken, right? > DocumentStore: introduce a "NotEquals" condition > > > Key: OAK-3489 > URL: https://issues.apache.org/jira/browse/OAK-3489 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0.21, 1.2.6, 1.3.7 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: OAK-3489.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3499) Test failures when there is no network interface
Marcel Reutegger created OAK-3499:
-
Summary: Test failures when there is no network interface
Key: OAK-3499
URL: https://issues.apache.org/jira/browse/OAK-3499
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, mongomk
Reporter: Marcel Reutegger
Assignee: Julian Reschke
Priority: Minor
There are test failures when no network interface is available.
{noformat}
Tests in error:
purge(org.apache.jackrabbit.oak.plugins.document.CollisionTest): Configured
cluster node id 1 already in use:
inactiveClusterId(org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreTest):
Configured cluster node id 2 already in use:
purgeUnmergedBranch(org.apache.jackrabbit.oak.plugins.document.UnmergedBranchTest):
Configured cluster node id 1 already in use:
{noformat}
I'm quite confident these used to work before.
[~reschke], could this be caused by recent changes for OAK-3449?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3499) Test failures when there is no network interface
[
https://issues.apache.org/jira/browse/OAK-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14949303#comment-14949303
]
Julian Reschke commented on OAK-3499:
-
Potentially. I removed the case where an empty network id (byte[0]) was
considered a unique identifier... Who can I repro this?
> Test failures when there is no network interface
>
>
> Key: OAK-3499
> URL: https://issues.apache.org/jira/browse/OAK-3499
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
>Reporter: Marcel Reutegger
>Assignee: Julian Reschke
>Priority: Minor
>
> There are test failures when no network interface is available.
> {noformat}
> Tests in error:
> purge(org.apache.jackrabbit.oak.plugins.document.CollisionTest): Configured
> cluster node id 1 already in use:
>
> inactiveClusterId(org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreTest):
> Configured cluster node id 2 already in use:
>
> purgeUnmergedBranch(org.apache.jackrabbit.oak.plugins.document.UnmergedBranchTest):
> Configured cluster node id 1 already in use:
> {noformat}
> I'm quite confident these used to work before.
> [~reschke], could this be caused by recent changes for OAK-3449?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3494) MemoryDiffCache should also check parent paths before falling to Loader (or returning null)
[
https://issues.apache.org/jira/browse/OAK-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-3494:
---
Attachment: OAK-3494-2.patch
Added a few cases over Marcel's patch. The [patch|^OAK-3494-2.patch] includes
Marcel's patch and the extra tests.
> MemoryDiffCache should also check parent paths before falling to Loader (or
> returning null)
> ---
>
> Key: OAK-3494
> URL: https://issues.apache.org/jira/browse/OAK-3494
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Marcel Reutegger
> Labels: performance
> Attachments: OAK-3494-1.patch, OAK-3494-2.patch,
> OAK-3494-TestCase.patch, OAK-3494.patch
>
>
> Each entry in {{MemoryDiffCache}} is keyed with {{(path, fromRev, toRev)}}
> for the list of modified children at {{path}}. A diff calcualted by
> {{DocumentNodeStore.diffImpl}} at '/' (passively via loader) or
> {{JournalEntry.applyTo}} (actively) fill each path for which there are
> modified children (including the hierarchy)
> But, if an observer calls {{compareWithBaseState}} on a unmodified sub-tree,
> the observer will still go down to {{diffImpl}} although cached parent entry
> can be used to answer the query.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3494) MemoryDiffCache should also check parent paths before falling to Loader (or returning null)
[
https://issues.apache.org/jira/browse/OAK-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-3494:
--
Attachment: OAK-3494-1.patch
Attaching my proposal for a fix based on Vikas' previous patch. No additional
tests, though.
> MemoryDiffCache should also check parent paths before falling to Loader (or
> returning null)
> ---
>
> Key: OAK-3494
> URL: https://issues.apache.org/jira/browse/OAK-3494
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Marcel Reutegger
> Labels: performance
> Attachments: OAK-3494-1.patch, OAK-3494-TestCase.patch, OAK-3494.patch
>
>
> Each entry in {{MemoryDiffCache}} is keyed with {{(path, fromRev, toRev)}}
> for the list of modified children at {{path}}. A diff calcualted by
> {{DocumentNodeStore.diffImpl}} at '/' (passively via loader) or
> {{JournalEntry.applyTo}} (actively) fill each path for which there are
> modified children (including the hierarchy)
> But, if an observer calls {{compareWithBaseState}} on a unmodified sub-tree,
> the observer will still go down to {{diffImpl}} although cached parent entry
> can be used to answer the query.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
