[jira] [Assigned] (OAK-2401) SegmentNodeStoreService prone to deadlocks
[
https://issues.apache.org/jira/browse/OAK-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra reassigned OAK-2401:
Assignee: Chetan Mehrotra (was: Alex Parvulescu)
> SegmentNodeStoreService prone to deadlocks
> --
>
> Key: OAK-2401
> URL: https://issues.apache.org/jira/browse/OAK-2401
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Chetan Mehrotra
>Priority: Blocker
> Labels: resilience
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-2401-01.patch, OAK-2401-02.patch, OAK-2401-03.patch,
> OAK-2401-04-testcase-fix.patch, OAK-2401.patch
>
>
> The SegmentNodeStoreService is prone to deadlocks because of the way in which
> is synchronizes access to the _SegmentNodeStore_ delegate.
> The issue can now be seen on #deactivate, when the deregistration is being
> synchronously broadcast and if a referring service calls #getNodeStore the
> deadlock happens.
> {code}
> Found one Java-level deadlock:
> =
> "qtp844483043-936":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)":
> waiting to lock monitor 0x01d4d0907c88 (object 0x01d2334be930, a
> java.lang.Object),
> which is held by "pool-5-thread-4"
> "pool-5-thread-4":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> Java stack information for the threads listed above:
> ===
> "qtp844483043-936":
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:144)
> - waiting to lock <0x01d231f52698> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:73)
> at
> org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.getRoot(ProxyNodeStore.java:35)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.(MutableRoot.java:160)
> at
> org.apache.jackrabbit.oak.core.ContentSessionImpl.getLatestRoot(ContentSessionImpl.java:110)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getRoot(AbstractLoginModule.java:403)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.getTokenProvider(TokenLoginModule.java:215)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.login(TokenLoginModule.java:128)
> at
> org.apache.felix.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:52)
> at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595)
> at
> org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:161)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:256)
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:92)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:197)
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.login(AbstractSlingRepository2.java:297)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory.getResourceProviderInternal(JcrResourceProviderFactory.java:289)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory.getResourceProvider(JcrResourceProvider
[jira] [Commented] (OAK-2401) SegmentNodeStoreService prone to deadlocks
[
https://issues.apache.org/jira/browse/OAK-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14591212#comment-14591212
]
Amit Jain commented on OAK-2401:
+1 for test & patch
> SegmentNodeStoreService prone to deadlocks
> --
>
> Key: OAK-2401
> URL: https://issues.apache.org/jira/browse/OAK-2401
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: resilience
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-2401-01.patch, OAK-2401-02.patch, OAK-2401-03.patch,
> OAK-2401-04-testcase-fix.patch, OAK-2401.patch
>
>
> The SegmentNodeStoreService is prone to deadlocks because of the way in which
> is synchronizes access to the _SegmentNodeStore_ delegate.
> The issue can now be seen on #deactivate, when the deregistration is being
> synchronously broadcast and if a referring service calls #getNodeStore the
> deadlock happens.
> {code}
> Found one Java-level deadlock:
> =
> "qtp844483043-936":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)":
> waiting to lock monitor 0x01d4d0907c88 (object 0x01d2334be930, a
> java.lang.Object),
> which is held by "pool-5-thread-4"
> "pool-5-thread-4":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> Java stack information for the threads listed above:
> ===
> "qtp844483043-936":
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:144)
> - waiting to lock <0x01d231f52698> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:73)
> at
> org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.getRoot(ProxyNodeStore.java:35)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.(MutableRoot.java:160)
> at
> org.apache.jackrabbit.oak.core.ContentSessionImpl.getLatestRoot(ContentSessionImpl.java:110)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getRoot(AbstractLoginModule.java:403)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.getTokenProvider(TokenLoginModule.java:215)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.login(TokenLoginModule.java:128)
> at
> org.apache.felix.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:52)
> at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595)
> at
> org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:161)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:256)
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:92)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:197)
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.login(AbstractSlingRepository2.java:297)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory.getResourceProviderInternal(JcrResourceProviderFactory.java:289)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory.getResourceProvider(JcrResourcePro
[jira] [Updated] (OAK-2987) RDBDocumentStore: try PreparedStatement batching
[ https://issues.apache.org/jira/browse/OAK-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-2987: Fix Version/s: 1.3.1 > RDBDocumentStore: try PreparedStatement batching > > > Key: OAK-2987 > URL: https://issues.apache.org/jira/browse/OAK-2987 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: rdbmk >Affects Versions: 1.2.2, 1.3.0, 1.0.15 >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.3.1 > > Attachments: OAK-2987.diff > > > There's at least one place in the code (dbBatchedAppendingUpdate, maybe also > dbInsert) where we could use batching on a single PreparedStatement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-3000.
-
Resolution: Fixed
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000-b.patch, OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2619) Repeated upgrades
[ https://issues.apache.org/jira/browse/OAK-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590092#comment-14590092 ] Manfred Baedke commented on OAK-2619: - Thank you for the patch [~jsedding]. While the approach looks promising, I don't really get the implementation. Shouldn't RepositoryUpgrade somehow make use of NodeStateCopier? > Repeated upgrades > - > > Key: OAK-2619 > URL: https://issues.apache.org/jira/browse/OAK-2619 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: upgrade >Affects Versions: 1.1.7 >Reporter: Julian Sedding >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-2619.patch, > incremental-upgrade-no-changes-mongo.png, > incremental-upgrade-no-changes-tar.png, initial-upgrade-mongo.png, > initial-upgrade-tar.png > > > When upgrading from Jackrabbit 2 to Oak there are several scenarios that > could benefit from the ability to upgrade repeatedly into one target > repository. > E.g. a migration process might look as follows: > # upgrade a backup of a large repository a week before go-live > # run the upgrade again every night (commit-hooks only handle delta) > # run the upgrade one final time before go-live (commit-hooks only handle > delta) > In this scenario each upgrade would require a full traversal of the source > repository. However, if done right, only the delta needs to be written and > the commit-hooks also only need to process the delta. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590091#comment-14590091
]
Thomas Mueller commented on OAK-3000:
-
https://svn.apache.org/r1686076 (1.2 branch)
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000-b.patch, OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2829) Comparing node states for external changes is too slow
[ https://issues.apache.org/jira/browse/OAK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589881#comment-14589881 ] Stefan Egli commented on OAK-2829: -- +1 > Comparing node states for external changes is too slow > -- > > Key: OAK-2829 > URL: https://issues.apache.org/jira/browse/OAK-2829 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Blocker > Labels: scalability > Fix For: 1.3.1, 1.2.3 > > Attachments: CompareAgainstBaseStateTest.java, > OAK-2829-JournalEntry.patch, OAK-2829-gc-bug.patch, > OAK-2829-improved-doc-cache-invaliation.2.patch, > OAK-2829-improved-doc-cache-invaliation.patch, graph-1.png, graph.png > > > Comparing node states for local changes has been improved already with > OAK-2669. But in a clustered setup generating events for external changes > cannot make use of the introduced cache and is therefore slower. This can > result in a growing observation queue, eventually reaching the configured > limit. See also OAK-2683. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2829) Comparing node states for external changes is too slow
[
https://issues.apache.org/jira/browse/OAK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589877#comment-14589877
]
Marcel Reutegger commented on OAK-2829:
---
Hmm, now that I re-read your comment, I think the method
{{TreeNode.isParentOf()}} should be renamed to {{TreeNode.isAncestorOf()}}.
Done in trunk: http://svn.apache.org/r1686032
> Comparing node states for external changes is too slow
> --
>
> Key: OAK-2829
> URL: https://issues.apache.org/jira/browse/OAK-2829
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Blocker
> Labels: scalability
> Fix For: 1.3.1, 1.2.3
>
> Attachments: CompareAgainstBaseStateTest.java,
> OAK-2829-JournalEntry.patch, OAK-2829-gc-bug.patch,
> OAK-2829-improved-doc-cache-invaliation.2.patch,
> OAK-2829-improved-doc-cache-invaliation.patch, graph-1.png, graph.png
>
>
> Comparing node states for local changes has been improved already with
> OAK-2669. But in a clustered setup generating events for external changes
> cannot make use of the introduced cache and is therefore slower. This can
> result in a growing observation queue, eventually reaching the configured
> limit. See also OAK-2683.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2829) Comparing node states for external changes is too slow
[ https://issues.apache.org/jira/browse/OAK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589868#comment-14589868 ] Marcel Reutegger commented on OAK-2829: --- Thanks for the review. Applied the patch to trunk: http://svn.apache.org/r1686023 > Comparing node states for external changes is too slow > -- > > Key: OAK-2829 > URL: https://issues.apache.org/jira/browse/OAK-2829 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Blocker > Labels: scalability > Fix For: 1.3.1, 1.2.3 > > Attachments: CompareAgainstBaseStateTest.java, > OAK-2829-JournalEntry.patch, OAK-2829-gc-bug.patch, > OAK-2829-improved-doc-cache-invaliation.2.patch, > OAK-2829-improved-doc-cache-invaliation.patch, graph-1.png, graph.png > > > Comparing node states for local changes has been improved already with > OAK-2669. But in a clustered setup generating events for external changes > cannot make use of the introduced cache and is therefore slower. This can > result in a growing observation queue, eventually reaching the configured > limit. See also OAK-2683. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2924) DocumentNodeStore background update thread handling of persistence exceptions
[
https://issues.apache.org/jira/browse/OAK-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-2924.
---
Resolution: Fixed
Fix Version/s: 1.3.1
Tuned the log message in trunk: http://svn.apache.org/r1686022
> DocumentNodeStore background update thread handling of persistence exceptions
> -
>
> Key: OAK-2924
> URL: https://issues.apache.org/jira/browse/OAK-2924
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk, rdbmk
>Affects Versions: 1.2.2, 1.3.0, 1.0.14
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
> Labels: resilience
> Fix For: 1.3.1
>
>
> Seen in a log file:
> {noformat}
> 27.05.2015 11:34:48.130 *WARN* [DocumentNodeStore background update thread]
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore Background
> operation failed:
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException:
> com.ibm.db2.jcc.am.SqlTransactionRollbackException: DB2 SQL Error:
> SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68, DRIVER=3.65.77
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException:
> com.ibm.db2.jcc.am.SqlTransactionRollbackException: DB2 SQL Error:
> SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68, DRIVER=3.65.77
> {noformat}
> We need to decide whether these are harmless in that the operation will be
> repeated anyway. If the answer is yes, we may want to tune the log message.
> If the answer is no, we need to dig deeper.
> [~mreutegg] wdyt?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-2924) DocumentNodeStore background update thread handling of persistence exceptions
[
https://issues.apache.org/jira/browse/OAK-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reassigned OAK-2924:
-
Assignee: Marcel Reutegger
> DocumentNodeStore background update thread handling of persistence exceptions
> -
>
> Key: OAK-2924
> URL: https://issues.apache.org/jira/browse/OAK-2924
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk, rdbmk
>Affects Versions: 1.2.2, 1.3.0, 1.0.14
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
> Labels: resilience
>
> Seen in a log file:
> {noformat}
> 27.05.2015 11:34:48.130 *WARN* [DocumentNodeStore background update thread]
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore Background
> operation failed:
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException:
> com.ibm.db2.jcc.am.SqlTransactionRollbackException: DB2 SQL Error:
> SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68, DRIVER=3.65.77
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException:
> com.ibm.db2.jcc.am.SqlTransactionRollbackException: DB2 SQL Error:
> SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68, DRIVER=3.65.77
> {noformat}
> We need to decide whether these are harmless in that the operation will be
> repeated anyway. If the answer is yes, we may want to tune the log message.
> If the answer is no, we need to dig deeper.
> [~mreutegg] wdyt?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589857#comment-14589857
]
Thomas Mueller commented on OAK-3000:
-
https://svn.apache.org/r1686021 (1.0 branch)
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000-b.patch, OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2829) Comparing node states for external changes is too slow
[
https://issues.apache.org/jira/browse/OAK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589848#comment-14589848
]
Stefan Egli commented on OAK-2829:
--
[~mreutegg], yes, looks more OO-like and even though {{isParent}} was
originally meant to be 'isDirectParent', the new implementation is actually
correct as the previous one was generating half-finished entries into the
diffCache because of this (they did get updated later in the loop, but
nevertheless, temporarily it put half-finished entries in). So:
+1
> Comparing node states for external changes is too slow
> --
>
> Key: OAK-2829
> URL: https://issues.apache.org/jira/browse/OAK-2829
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Blocker
> Labels: scalability
> Fix For: 1.3.1, 1.2.3
>
> Attachments: CompareAgainstBaseStateTest.java,
> OAK-2829-JournalEntry.patch, OAK-2829-gc-bug.patch,
> OAK-2829-improved-doc-cache-invaliation.2.patch,
> OAK-2829-improved-doc-cache-invaliation.patch, graph-1.png, graph.png
>
>
> Comparing node states for local changes has been improved already with
> OAK-2669. But in a clustered setup generating events for external changes
> cannot make use of the introduced cache and is therefore slower. This can
> result in a growing observation queue, eventually reaching the configured
> limit. See also OAK-2683.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2681) Update lease without holding lock
[ https://issues.apache.org/jira/browse/OAK-2681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-2681. --- Resolution: Fixed Done in trunk: http://svn.apache.org/r1686020 > Update lease without holding lock > - > > Key: OAK-2681 > URL: https://issues.apache.org/jira/browse/OAK-2681 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: concurrency, technical_debt > Fix For: 1.3.1 > > > A lease update of the DocumentNodeStore on MongoDB will acquire a lock in > MongoDocumentStore to perform the changes. The locking is only necessary for > changes in the 'nodes' collection, because only those documents are cached > and the locking makes sure the cache is consistent. The MongoDocumentStore > must be changed to only acquire a lock when changes are done in the 'nodes' > collection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589801#comment-14589801
]
Thomas Mueller commented on OAK-3000:
-
https://svn.apache.org/r1686015 (trunk)
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000-b.patch, OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589799#comment-14589799
]
angela commented on OAK-2981:
-
my take is totally the opposite: you have to think about your permission setup
upfront and design it. if you just look at a log you will end up just opening
up permission blindly to make everything get green without designing it! this
is asking for privilege escalations and is just the total opposite of what the
security team tries to establish.
so, my -1 still stands. consider this a veto.
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589796#comment-14589796
]
Thomas Mueller commented on OAK-3000:
-
Integration tests passed with my patch, I will commit it and then backport it
(also run integration tests, so this will take some time).
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000-b.patch, OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller reassigned OAK-3000:
---
Assignee: Thomas Mueller
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000-b.patch, OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2987) RDBDocumentStore: try PreparedStatement batching
[ https://issues.apache.org/jira/browse/OAK-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-2987: Attachment: OAK-2987.diff > RDBDocumentStore: try PreparedStatement batching > > > Key: OAK-2987 > URL: https://issues.apache.org/jira/browse/OAK-2987 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: rdbmk >Affects Versions: 1.2.2, 1.3.0, 1.0.15 >Reporter: Julian Reschke >Assignee: Julian Reschke > Attachments: OAK-2987.diff > > > There's at least one place in the code (dbBatchedAppendingUpdate, maybe also > dbInsert) where we could use batching on a single PreparedStatement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-2961) Async index fails with OakState0001: Unresolved conflicts in /:async
[
https://issues.apache.org/jira/browse/OAK-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589757#comment-14589757
]
Davide Giannella edited comment on OAK-2961 at 6/17/15 1:36 PM:
Applied the patch and the /:async conflict goes away. Anyway still
there're warnings which as of now don't know if they are something to
worry about or not.
{noformat}
14:21:53.983 [main] INFO o.a.j.oak.jcr.AsyncConflictsIT - adding 1 nodes
14:21:59.104 [oak-scheduled-executor-5] INFO
o.a.j.o.p.i.l.LuceneIndexEditorContext - Loaded default Tika Config from
classpath
file:/Users/dgiannel/work/sources/apache/jackrabbit-oak/oak-lucene/target/classes/org/apache/jackrabbit/oak/plugins/index/lucene/tika-config.xml
14:21:59.661 [main] INFO o.a.j.oak.jcr.AsyncConflictsIT - Nodes added.
14:21:59.662 [main] INFO o.a.j.oak.jcr.AsyncConflictsIT - issuing re-index and
wait for finish
14:21:59.974 [oak-scheduled-executor-5] DEBUG o.a.j.o.p.i.l.L.perf - Created
IndexWriter for directory Lucene Index : [took
83ms]
14:21:59.980 [oak-scheduled-executor-5] DEBUG o.a.j.o.p.i.l.L.perf - Closed
IndexWriter for directory Lucene Index : [took 6ms]
14:21:59.980 [oak-scheduled-executor-5] DEBUG
o.a.j.o.p.i.l.LuceneIndexEditorContext - Text extraction stats 0 (0 min, 0
sec, 0 B)
14:22:05.387 [oak-scheduled-executor-3] DEBUG o.a.j.o.p.i.l.L.perf - Created
IndexWriter for directory Lucene Index : [took 0ms]
14:22:05.389 [oak-scheduled-executor-3] DEBUG o.a.j.o.p.i.l.L.perf - Closed
IndexWriter for directory Lucene Index : [took 1ms]
14:22:05.389 [oak-scheduled-executor-3] DEBUG
o.a.j.o.p.i.l.LuceneIndexEditorContext - Text extraction stats 0 (0 min, 0
sec, 0 B)
14:22:06.082 [oak-scheduled-executor-7] WARN o.a.j.o.p.index.AsyncIndexUpdate
- [async] Failed to retrieve previously indexed checkpoint r14e01aef4dd-0-1;
re-running the initial index update
14:22:06.259 [oak-scheduled-executor-7] WARN o.a.j.o.p.index.AsyncIndexUpdate
- [async] Failed to retrieve previously indexed checkpoint r14e01aef4dd-0-1;
re-running the initial index update
{noformat}
WARNs are not systematically. They happen something like 2 times over 5 runs.
[~alexparvulescu], [~chetanm] thoughts?
PS: created
https://github.com/davidegiannella/jackrabbit-oak/tree/OAK-2961 for
experimenting in case.
was (Author: edivad):
Applied the patch and the /:async conflict goes away. Anyway still
there're warnings which as of now don't know if they are something to
worry about or not.
{noformat}
14:21:53.983 [main] INFO o.a.j.oak.jcr.AsyncConflictsIT - adding 1 nodes
14:21:59.104 [oak-scheduled-executor-5] INFO
o.a.j.o.p.i.l.LuceneIndexEditorContext - Loaded default Tika Config from
classpath
file:/Users/dgiannel/work/sources/apache/jackrabbit-oak/oak-lucene/target/classes/org/apache/jackrabbit/oak/plugins/index/lucene/tika-config.xml
14:21:59.661 [main] INFO o.a.j.oak.jcr.AsyncConflictsIT - Nodes added.
14:21:59.662 [main] INFO o.a.j.oak.jcr.AsyncConflictsIT - issuing re-index and
wait for finish
14:21:59.974 [oak-scheduled-executor-5] DEBUG o.a.j.o.p.i.l.L.perf - Created
IndexWriter for directory Lucene Index : [took
83ms]
14:21:59.980 [oak-scheduled-executor-5] DEBUG o.a.j.o.p.i.l.L.perf - Closed
IndexWriter for directory Lucene Index : [took 6ms]
14:21:59.980 [oak-scheduled-executor-5] DEBUG
o.a.j.o.p.i.l.LuceneIndexEditorContext - Text extraction stats 0 (0 min, 0
sec, 0 B)
14:22:05.387 [oak-scheduled-executor-3] DEBUG o.a.j.o.p.i.l.L.perf - Created
IndexWriter for directory Lucene Index : [took 0ms]
14:22:05.389 [oak-scheduled-executor-3] DEBUG o.a.j.o.p.i.l.L.perf - Closed
IndexWriter for directory Lucene Index : [took 1ms]
14:22:05.389 [oak-scheduled-executor-3] DEBUG
o.a.j.o.p.i.l.LuceneIndexEditorContext - Text extraction stats 0 (0 min, 0
sec, 0 B)
14:22:06.082 [oak-scheduled-executor-7] WARN o.a.j.o.p.index.AsyncIndexUpdate
- [async] Failed to retrieve previously indexed checkpoint r14e01aef4dd-0-1;
re-running the initial index update
14:22:06.259 [oak-scheduled-executor-7] WARN o.a.j.o.p.index.AsyncIndexUpdate
- [async] Failed to retrieve previously indexed checkpoint r14e01aef4dd-0-1;
re-running the initial index update
{noformat}
[~alexparvulescu], [~chetanm] thoughts?
PS: created
https://github.com/davidegiannella/jackrabbit-oak/tree/OAK-2961 for
experimenting in case.
> Async index fails with OakState0001: Unresolved conflicts in /:async
>
>
> Key: OAK-2961
> URL: https://issues.apache.org/jira/browse/OAK-2961
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk, query
>Affects Versions: 1.2.2, 1.0.14, 1.4
>Reporter: Davide Giannella
>Assignee: Davide Giannella
> Labels: resilience
> Fix For:
[jira] [Issue Comment Deleted] (OAK-2619) Repeated upgrades
[ https://issues.apache.org/jira/browse/OAK-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-2619: Comment: was deleted (was: [~jsedding], your patch to RepositoryUpgrade compares privileges by name, not by using equals(). What if the underlying PrivilegeDefinition changed?) > Repeated upgrades > - > > Key: OAK-2619 > URL: https://issues.apache.org/jira/browse/OAK-2619 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: upgrade >Affects Versions: 1.1.7 >Reporter: Julian Sedding >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-2619.patch, > incremental-upgrade-no-changes-mongo.png, > incremental-upgrade-no-changes-tar.png, initial-upgrade-mongo.png, > initial-upgrade-tar.png > > > When upgrading from Jackrabbit 2 to Oak there are several scenarios that > could benefit from the ability to upgrade repeatedly into one target > repository. > E.g. a migration process might look as follows: > # upgrade a backup of a large repository a week before go-live > # run the upgrade again every night (commit-hooks only handle delta) > # run the upgrade one final time before go-live (commit-hooks only handle > delta) > In this scenario each upgrade would require a full traversal of the source > repository. However, if done right, only the delta needs to be written and > the commit-hooks also only need to process the delta. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2961) Async index fails with OakState0001: Unresolved conflicts in /:async
[
https://issues.apache.org/jira/browse/OAK-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589757#comment-14589757
]
Davide Giannella commented on OAK-2961:
---
Applied the patch and the /:async conflict goes away. Anyway still
there're warnings which as of now don't know if they are something to
worry about or not.
{noformat}
14:21:53.983 [main] INFO o.a.j.oak.jcr.AsyncConflictsIT - adding 1 nodes
14:21:59.104 [oak-scheduled-executor-5] INFO
o.a.j.o.p.i.l.LuceneIndexEditorContext - Loaded default Tika Config from
classpath
file:/Users/dgiannel/work/sources/apache/jackrabbit-oak/oak-lucene/target/classes/org/apache/jackrabbit/oak/plugins/index/lucene/tika-config.xml
14:21:59.661 [main] INFO o.a.j.oak.jcr.AsyncConflictsIT - Nodes added.
14:21:59.662 [main] INFO o.a.j.oak.jcr.AsyncConflictsIT - issuing re-index and
wait for finish
14:21:59.974 [oak-scheduled-executor-5] DEBUG o.a.j.o.p.i.l.L.perf - Created
IndexWriter for directory Lucene Index : [took
83ms]
14:21:59.980 [oak-scheduled-executor-5] DEBUG o.a.j.o.p.i.l.L.perf - Closed
IndexWriter for directory Lucene Index : [took 6ms]
14:21:59.980 [oak-scheduled-executor-5] DEBUG
o.a.j.o.p.i.l.LuceneIndexEditorContext - Text extraction stats 0 (0 min, 0
sec, 0 B)
14:22:05.387 [oak-scheduled-executor-3] DEBUG o.a.j.o.p.i.l.L.perf - Created
IndexWriter for directory Lucene Index : [took 0ms]
14:22:05.389 [oak-scheduled-executor-3] DEBUG o.a.j.o.p.i.l.L.perf - Closed
IndexWriter for directory Lucene Index : [took 1ms]
14:22:05.389 [oak-scheduled-executor-3] DEBUG
o.a.j.o.p.i.l.LuceneIndexEditorContext - Text extraction stats 0 (0 min, 0
sec, 0 B)
14:22:06.082 [oak-scheduled-executor-7] WARN o.a.j.o.p.index.AsyncIndexUpdate
- [async] Failed to retrieve previously indexed checkpoint r14e01aef4dd-0-1;
re-running the initial index update
14:22:06.259 [oak-scheduled-executor-7] WARN o.a.j.o.p.index.AsyncIndexUpdate
- [async] Failed to retrieve previously indexed checkpoint r14e01aef4dd-0-1;
re-running the initial index update
{noformat}
[~alexparvulescu], [~chetanm] thoughts?
PS: created
https://github.com/davidegiannella/jackrabbit-oak/tree/OAK-2961 for
experimenting in case.
> Async index fails with OakState0001: Unresolved conflicts in /:async
>
>
> Key: OAK-2961
> URL: https://issues.apache.org/jira/browse/OAK-2961
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk, query
>Affects Versions: 1.2.2, 1.0.14, 1.4
>Reporter: Davide Giannella
>Assignee: Davide Giannella
> Labels: resilience
> Fix For: 1.3.1, 1.2.3
>
> Attachments: OAK-2961.patch
>
>
> When running on a mongo cluster, in case of high activity the async index
> could fail with the following exception.
> Reproduced with LucenePropertyIndex.
> {noformat}
> 10:55:13.069 [oak-scheduled-executor-5] WARN
> o.a.j.o.p.index.AsyncIndexUpdate - [async] The index update failed
> org.apache.jackrabbit.oak.api.CommitFailedException: OakState0001: Unresolved
> conflicts in /:async
> at
> org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.failOnMergeConflict(ConflictValidator.java:84)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.propertyAdded(ConflictValidator.java:54)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.propertyAdded(EditorDiff.java:82)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:378)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:400)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:55)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:528)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:219)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:171)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:158)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugi
[jira] [Updated] (OAK-2829) Comparing node states for external changes is too slow
[ https://issues.apache.org/jira/browse/OAK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2829: -- Attachment: OAK-2829-JournalEntry.patch As mentioned before, I would like to get rid of the path field in the TreeNode class to reduce the memory usage. See attached patch 'OAK-2829-JournalEntry.patch' for proposed changes. [~egli], WDYT? > Comparing node states for external changes is too slow > -- > > Key: OAK-2829 > URL: https://issues.apache.org/jira/browse/OAK-2829 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Blocker > Labels: scalability > Fix For: 1.3.1, 1.2.3 > > Attachments: CompareAgainstBaseStateTest.java, > OAK-2829-JournalEntry.patch, OAK-2829-gc-bug.patch, > OAK-2829-improved-doc-cache-invaliation.2.patch, > OAK-2829-improved-doc-cache-invaliation.patch, graph-1.png, graph.png > > > Comparing node states for local changes has been improved already with > OAK-2669. But in a clustered setup generating events for external changes > cannot make use of the introduced cache and is therefore slower. This can > result in a growing observation queue, eventually reaching the configured > limit. See also OAK-2683. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589748#comment-14589748
]
Amit Gupta commented on OAK-2981:
-
>having a tool that logs all the paths that are accessed by the application,
>and shows the user and the permissions that are tested, helps >tremendously to
>cleanup and streamline a system. similar to a request or access log that helps
>understand the http traffic.
+1, looks useful
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2619) Repeated upgrades
[ https://issues.apache.org/jira/browse/OAK-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589745#comment-14589745 ] Manfred Baedke commented on OAK-2619: - [~jsedding], your patch to RepositoryUpgrade compares privileges by name, not by using equals(). What if the underlying PrivilegeDefinition changed? > Repeated upgrades > - > > Key: OAK-2619 > URL: https://issues.apache.org/jira/browse/OAK-2619 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: upgrade >Affects Versions: 1.1.7 >Reporter: Julian Sedding >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-2619.patch, > incremental-upgrade-no-changes-mongo.png, > incremental-upgrade-no-changes-tar.png, initial-upgrade-mongo.png, > initial-upgrade-tar.png > > > When upgrading from Jackrabbit 2 to Oak there are several scenarios that > could benefit from the ability to upgrade repeatedly into one target > repository. > E.g. a migration process might look as follows: > # upgrade a backup of a large repository a week before go-live > # run the upgrade again every night (commit-hooks only handle delta) > # run the upgrade one final time before go-live (commit-hooks only handle > delta) > In this scenario each upgrade would require a full traversal of the source > repository. However, if done right, only the delta needs to be written and > the commit-hooks also only need to process the delta. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3002) Optimize docCache and docChildrenCache invalidation by filtering using journal
[
https://issues.apache.org/jira/browse/OAK-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589740#comment-14589740
]
Stefan Egli commented on OAK-3002:
--
bq. I can attach the test case once polished properly, it's a bit hacky atm
Attached [^JournalLoadTest.java] for reference (does not function as junit test
atm however)
> Optimize docCache and docChildrenCache invalidation by filtering using journal
> --
>
> Key: OAK-3002
> URL: https://issues.apache.org/jira/browse/OAK-3002
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, mongomk
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: scalability
> Fix For: 1.3.1, 1.2.3
>
> Attachments: JournalLoadTest.java,
> OAK-3002-improved-doc-and-docChildren-cache-invaliation.3.patch,
> OAK-3002-improved-doc-cache-invaliation.2.patch
>
>
> This subtask is about spawning out a
> [comment|https://issues.apache.org/jira/browse/OAK-2829?focusedCommentId=14588114&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14588114]
> on OAK-2829 re optimizing docCache invalidation using the newly introduced
> external diff journal:
> {quote}
> Attached OAK-2829-improved-doc-cache-invaliation.patch which is a suggestion
> on how to avoid invalidating the entire document cache when doing a
> {{backgroundRead}} but instead making use of the new journal: ie only
> invalidate from the document cache what has actually changed.
> I'd like to get an opinion ([~mreutegg], [~chetanm]?) on this first, I have a
> load test pending locally which found invalidation of the document cache to
> be the slowest part thus wanted to optimize this first.
> Open still/next:
> * also invalidate only necessary parts from the docChildrenCache
> * junits for all of these
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3002) Optimize docCache and docChildrenCache invalidation by filtering using journal
[
https://issues.apache.org/jira/browse/OAK-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-3002:
-
Attachment: JournalLoadTest.java
> Optimize docCache and docChildrenCache invalidation by filtering using journal
> --
>
> Key: OAK-3002
> URL: https://issues.apache.org/jira/browse/OAK-3002
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, mongomk
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: scalability
> Fix For: 1.3.1, 1.2.3
>
> Attachments: JournalLoadTest.java,
> OAK-3002-improved-doc-and-docChildren-cache-invaliation.3.patch,
> OAK-3002-improved-doc-cache-invaliation.2.patch
>
>
> This subtask is about spawning out a
> [comment|https://issues.apache.org/jira/browse/OAK-2829?focusedCommentId=14588114&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14588114]
> on OAK-2829 re optimizing docCache invalidation using the newly introduced
> external diff journal:
> {quote}
> Attached OAK-2829-improved-doc-cache-invaliation.patch which is a suggestion
> on how to avoid invalidating the entire document cache when doing a
> {{backgroundRead}} but instead making use of the new journal: ie only
> invalidate from the document cache what has actually changed.
> I'd like to get an opinion ([~mreutegg], [~chetanm]?) on this first, I have a
> load test pending locally which found invalidation of the document cache to
> be the slowest part thus wanted to optimize this first.
> Open still/next:
> * also invalidate only necessary parts from the docChildrenCache
> * junits for all of these
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2401) SegmentNodeStoreService prone to deadlocks
[
https://issues.apache.org/jira/browse/OAK-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589725#comment-14589725
]
Francesco Mari commented on OAK-2401:
-
I see that the {{SegmentNodeStoreService}} was written with some assumptions in
mind that were not clear to me before submitting my patches. [~chetanm], if you
are confident that your patch solves the problem, given the assumptions you
described, we should better go with it. Do [~amitjain] and [~alexparvulescu]
have something to add?
> SegmentNodeStoreService prone to deadlocks
> --
>
> Key: OAK-2401
> URL: https://issues.apache.org/jira/browse/OAK-2401
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: resilience
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-2401-01.patch, OAK-2401-02.patch, OAK-2401-03.patch,
> OAK-2401-04-testcase-fix.patch, OAK-2401.patch
>
>
> The SegmentNodeStoreService is prone to deadlocks because of the way in which
> is synchronizes access to the _SegmentNodeStore_ delegate.
> The issue can now be seen on #deactivate, when the deregistration is being
> synchronously broadcast and if a referring service calls #getNodeStore the
> deadlock happens.
> {code}
> Found one Java-level deadlock:
> =
> "qtp844483043-936":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)":
> waiting to lock monitor 0x01d4d0907c88 (object 0x01d2334be930, a
> java.lang.Object),
> which is held by "pool-5-thread-4"
> "pool-5-thread-4":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> Java stack information for the threads listed above:
> ===
> "qtp844483043-936":
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:144)
> - waiting to lock <0x01d231f52698> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:73)
> at
> org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.getRoot(ProxyNodeStore.java:35)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.(MutableRoot.java:160)
> at
> org.apache.jackrabbit.oak.core.ContentSessionImpl.getLatestRoot(ContentSessionImpl.java:110)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getRoot(AbstractLoginModule.java:403)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.getTokenProvider(TokenLoginModule.java:215)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.login(TokenLoginModule.java:128)
> at
> org.apache.felix.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:52)
> at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595)
> at
> org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:161)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:256)
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:92)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:197)
> at
> org.apache.sling.jcr.base.AbstractSlingRepo
[jira] [Commented] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589714#comment-14589714
]
Thomas Mueller commented on OAK-3000:
-
> I am not sure weather we should further invest in SimpleExcerptProvider
Well, you already did... I think either we remove the broken code (but I guess
that's not so easy), or we fix it so that it doesn't break apart with even
trivial parameters (for example, highlighting the character "s").
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000-b.patch, OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-3000:
Attachment: OAK-3000-b.patch
OAK-3000-b.patch
This patch fixes all the known issues with the current code. OOM is no longer
possible, and highlighting does not break apart if the search text contains
pieces of the term "".
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000-b.patch, OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-2619) Repeated upgrades
[ https://issues.apache.org/jira/browse/OAK-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned OAK-2619: --- Assignee: Manfred Baedke > Repeated upgrades > - > > Key: OAK-2619 > URL: https://issues.apache.org/jira/browse/OAK-2619 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: upgrade >Affects Versions: 1.1.7 >Reporter: Julian Sedding >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-2619.patch, > incremental-upgrade-no-changes-mongo.png, > incremental-upgrade-no-changes-tar.png, initial-upgrade-mongo.png, > initial-upgrade-tar.png > > > When upgrading from Jackrabbit 2 to Oak there are several scenarios that > could benefit from the ability to upgrade repeatedly into one target > repository. > E.g. a migration process might look as follows: > # upgrade a backup of a large repository a week before go-live > # run the upgrade again every night (commit-hooks only handle delta) > # run the upgrade one final time before go-live (commit-hooks only handle > delta) > In this scenario each upgrade would require a full traversal of the source > repository. However, if done right, only the delta needs to be written and > the commit-hooks also only need to process the delta. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2401) SegmentNodeStoreService prone to deadlocks
[
https://issues.apache.org/jira/browse/OAK-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589692#comment-14589692
]
Chetan Mehrotra commented on OAK-2401:
--
bq. This is, in my opinion, another reason to have a static reference instead
of a dynamic one
Making it static does not change the implementation much as its only known via
configuration that wether BlobStore is required or not. If you mark it static,
greedy and optional then following flows are possible
# BlobStore required
## At time of activation BlobStore has been registered - In this case the
BlobStore would be bound
## At time of activation BlobStore is not registered - In that case also
activation proceed (its optional per SCR). Later when BlobStore comes the bind
method would be invoked.
# BlobStore not required - In this case at time of activation SNS would know by
reading the config that BlobStore is not required and it would proceed and
create the SegmentNodeStore
So changing the BlobStore reference options does not help.
Probably what you are looking for is '.cardinality.minimum' support
added to SCR as part of RFC 190 (Section 5.10 [1]) (see FELIX-4391). If we use
that then yes those binad/unbind method logic can be avoided
[1]
https://github.com/osgi/design/raw/master/rfcs/rfc0190/rfc-0190-Declarative_Services_Enhancements.pdf
> SegmentNodeStoreService prone to deadlocks
> --
>
> Key: OAK-2401
> URL: https://issues.apache.org/jira/browse/OAK-2401
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: resilience
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-2401-01.patch, OAK-2401-02.patch, OAK-2401-03.patch,
> OAK-2401-04-testcase-fix.patch, OAK-2401.patch
>
>
> The SegmentNodeStoreService is prone to deadlocks because of the way in which
> is synchronizes access to the _SegmentNodeStore_ delegate.
> The issue can now be seen on #deactivate, when the deregistration is being
> synchronously broadcast and if a referring service calls #getNodeStore the
> deadlock happens.
> {code}
> Found one Java-level deadlock:
> =
> "qtp844483043-936":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)":
> waiting to lock monitor 0x01d4d0907c88 (object 0x01d2334be930, a
> java.lang.Object),
> which is held by "pool-5-thread-4"
> "pool-5-thread-4":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> Java stack information for the threads listed above:
> ===
> "qtp844483043-936":
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:144)
> - waiting to lock <0x01d231f52698> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:73)
> at
> org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.getRoot(ProxyNodeStore.java:35)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.(MutableRoot.java:160)
> at
> org.apache.jackrabbit.oak.core.ContentSessionImpl.getLatestRoot(ContentSessionImpl.java:110)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getRoot(AbstractLoginModule.java:403)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.getTokenProvider(TokenLoginModule.java:215)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.login(TokenLoginModule.java:128)
> at
> org.apache.felix.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:52)
> at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.sec
[jira] [Commented] (OAK-3002) Optimize docCache and docChildrenCache invalidation by filtering using journal
[
https://issues.apache.org/jira/browse/OAK-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589684#comment-14589684
]
Chetan Mehrotra commented on OAK-3002:
--
bq. the journal contains a tree of nodes that have changed. However, it does
not yet indicate if a non-leaf node has changed or not. For a leaf-node it is
clear, that has changed. But for a non-leaf that is atm not yet marked in any
way (maybe we could do that).
Aah was not aware of that. I thought we are storing list of changed paths, now
I see that its a JSOPIt would be better if we do this and thus avoid the
complexity in cache invalidation logic
[~mreutegg] thoughts?
> Optimize docCache and docChildrenCache invalidation by filtering using journal
> --
>
> Key: OAK-3002
> URL: https://issues.apache.org/jira/browse/OAK-3002
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, mongomk
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: scalability
> Fix For: 1.3.1, 1.2.3
>
> Attachments:
> OAK-3002-improved-doc-and-docChildren-cache-invaliation.3.patch,
> OAK-3002-improved-doc-cache-invaliation.2.patch
>
>
> This subtask is about spawning out a
> [comment|https://issues.apache.org/jira/browse/OAK-2829?focusedCommentId=14588114&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14588114]
> on OAK-2829 re optimizing docCache invalidation using the newly introduced
> external diff journal:
> {quote}
> Attached OAK-2829-improved-doc-cache-invaliation.patch which is a suggestion
> on how to avoid invalidating the entire document cache when doing a
> {{backgroundRead}} but instead making use of the new journal: ie only
> invalidate from the document cache what has actually changed.
> I'd like to get an opinion ([~mreutegg], [~chetanm]?) on this first, I have a
> load test pending locally which found invalidation of the document cache to
> be the slowest part thus wanted to optimize this first.
> Open still/next:
> * also invalidate only necessary parts from the docChildrenCache
> * junits for all of these
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-2401) SegmentNodeStoreService prone to deadlocks
[
https://issues.apache.org/jira/browse/OAK-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589675#comment-14589675
]
Francesco Mari edited comment on OAK-2401 at 6/17/15 12:03 PM:
---
bq. Further in a given system there should be one and only one BlobStore
configured and they should be configured once and not changed once a setup is
running.
This is, in my opinion, another reason to have a static reference instead of a
dynamic one. A static reference makes a clearer statement about the kind of
dependency existing between a {{SegmentNodeStoreService}} and a {{BlobStore}}.
was (Author: frm):
bq. Further in a given system there should be one and only one BlobStore
configured and they should be configured once and not changed once a setup is
running.
This is, in my opinion, another reason to have a static reference instead of a
dynamic one. Having a static references makes a clearer statement about the
kind of dependency existing between a {{SegmentNodeStoreService}} and a
{{BlobStore}}.
> SegmentNodeStoreService prone to deadlocks
> --
>
> Key: OAK-2401
> URL: https://issues.apache.org/jira/browse/OAK-2401
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: resilience
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-2401-01.patch, OAK-2401-02.patch, OAK-2401-03.patch,
> OAK-2401-04-testcase-fix.patch, OAK-2401.patch
>
>
> The SegmentNodeStoreService is prone to deadlocks because of the way in which
> is synchronizes access to the _SegmentNodeStore_ delegate.
> The issue can now be seen on #deactivate, when the deregistration is being
> synchronously broadcast and if a referring service calls #getNodeStore the
> deadlock happens.
> {code}
> Found one Java-level deadlock:
> =
> "qtp844483043-936":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)":
> waiting to lock monitor 0x01d4d0907c88 (object 0x01d2334be930, a
> java.lang.Object),
> which is held by "pool-5-thread-4"
> "pool-5-thread-4":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> Java stack information for the threads listed above:
> ===
> "qtp844483043-936":
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:144)
> - waiting to lock <0x01d231f52698> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:73)
> at
> org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.getRoot(ProxyNodeStore.java:35)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.(MutableRoot.java:160)
> at
> org.apache.jackrabbit.oak.core.ContentSessionImpl.getLatestRoot(ContentSessionImpl.java:110)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getRoot(AbstractLoginModule.java:403)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.getTokenProvider(TokenLoginModule.java:215)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.login(TokenLoginModule.java:128)
> at
> org.apache.felix.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:52)
> at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
>
[jira] [Commented] (OAK-2401) SegmentNodeStoreService prone to deadlocks
[
https://issues.apache.org/jira/browse/OAK-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589675#comment-14589675
]
Francesco Mari commented on OAK-2401:
-
bq. Further in a given system there should be one and only one BlobStore
configured and they should be configured once and not changed once a setup is
running.
This is, in my opinion, another reason to have a static reference instead of a
dynamic one. Having a static references makes a clearer statement about the
kind of dependency existing between a {{SegmentNodeStoreService}} and a
{{BlobStore}}.
> SegmentNodeStoreService prone to deadlocks
> --
>
> Key: OAK-2401
> URL: https://issues.apache.org/jira/browse/OAK-2401
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: resilience
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-2401-01.patch, OAK-2401-02.patch, OAK-2401-03.patch,
> OAK-2401-04-testcase-fix.patch, OAK-2401.patch
>
>
> The SegmentNodeStoreService is prone to deadlocks because of the way in which
> is synchronizes access to the _SegmentNodeStore_ delegate.
> The issue can now be seen on #deactivate, when the deregistration is being
> synchronously broadcast and if a referring service calls #getNodeStore the
> deadlock happens.
> {code}
> Found one Java-level deadlock:
> =
> "qtp844483043-936":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)":
> waiting to lock monitor 0x01d4d0907c88 (object 0x01d2334be930, a
> java.lang.Object),
> which is held by "pool-5-thread-4"
> "pool-5-thread-4":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> Java stack information for the threads listed above:
> ===
> "qtp844483043-936":
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:144)
> - waiting to lock <0x01d231f52698> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:73)
> at
> org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.getRoot(ProxyNodeStore.java:35)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.(MutableRoot.java:160)
> at
> org.apache.jackrabbit.oak.core.ContentSessionImpl.getLatestRoot(ContentSessionImpl.java:110)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getRoot(AbstractLoginModule.java:403)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.getTokenProvider(TokenLoginModule.java:215)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.login(TokenLoginModule.java:128)
> at
> org.apache.felix.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:52)
> at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595)
> at
> org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:161)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:256)
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:92)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl
[jira] [Updated] (OAK-3002) Optimize docCache and docChildrenCache invalidation by filtering using journal
[
https://issues.apache.org/jira/browse/OAK-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-3002:
-
Summary: Optimize docCache and docChildrenCache invalidation by filtering
using journal (was: Optimize docCache by filtering using journal)
> Optimize docCache and docChildrenCache invalidation by filtering using journal
> --
>
> Key: OAK-3002
> URL: https://issues.apache.org/jira/browse/OAK-3002
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, mongomk
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: scalability
> Fix For: 1.3.1, 1.2.3
>
> Attachments:
> OAK-3002-improved-doc-and-docChildren-cache-invaliation.3.patch,
> OAK-3002-improved-doc-cache-invaliation.2.patch
>
>
> This subtask is about spawning out a
> [comment|https://issues.apache.org/jira/browse/OAK-2829?focusedCommentId=14588114&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14588114]
> on OAK-2829 re optimizing docCache invalidation using the newly introduced
> external diff journal:
> {quote}
> Attached OAK-2829-improved-doc-cache-invaliation.patch which is a suggestion
> on how to avoid invalidating the entire document cache when doing a
> {{backgroundRead}} but instead making use of the new journal: ie only
> invalidate from the document cache what has actually changed.
> I'd like to get an opinion ([~mreutegg], [~chetanm]?) on this first, I have a
> load test pending locally which found invalidation of the document cache to
> be the slowest part thus wanted to optimize this first.
> Open still/next:
> * also invalidate only necessary parts from the docChildrenCache
> * junits for all of these
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3002) Optimize docCache by filtering using journal
[
https://issues.apache.org/jira/browse/OAK-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-3002:
-
Attachment: OAK-3002-improved-doc-and-docChildren-cache-invaliation.3.patch
Re:
{quote}
Open still/next:
* also invalidate only necessary parts from the docChildrenCache
{quote}
Attached [^OAK-3002-improved-doc-and-docChildren-cache-invaliation.3.patch]
which also invalidates the docChildren cache (cumulative patch based including
previous two, based on latest trunk)
Re:
{quote}
* junits for all of these
{quote}
still open
> Optimize docCache by filtering using journal
>
>
> Key: OAK-3002
> URL: https://issues.apache.org/jira/browse/OAK-3002
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, mongomk
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: scalability
> Fix For: 1.3.1, 1.2.3
>
> Attachments:
> OAK-3002-improved-doc-and-docChildren-cache-invaliation.3.patch,
> OAK-3002-improved-doc-cache-invaliation.2.patch
>
>
> This subtask is about spawning out a
> [comment|https://issues.apache.org/jira/browse/OAK-2829?focusedCommentId=14588114&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14588114]
> on OAK-2829 re optimizing docCache invalidation using the newly introduced
> external diff journal:
> {quote}
> Attached OAK-2829-improved-doc-cache-invaliation.patch which is a suggestion
> on how to avoid invalidating the entire document cache when doing a
> {{backgroundRead}} but instead making use of the new journal: ie only
> invalidate from the document cache what has actually changed.
> I'd like to get an opinion ([~mreutegg], [~chetanm]?) on this first, I have a
> load test pending locally which found invalidation of the document cache to
> be the slowest part thus wanted to optimize this first.
> Open still/next:
> * also invalidate only necessary parts from the docChildrenCache
> * junits for all of these
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3004) OSGI wrapper service for Jackrabbit CachingFDS
[ https://issues.apache.org/jira/browse/OAK-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shashank Gupta resolved OAK-3004. - Resolution: Duplicate Yes. Duplicate of OAK-3005. > OSGI wrapper service for Jackrabbit CachingFDS > -- > > Key: OAK-3004 > URL: https://issues.apache.org/jira/browse/OAK-3004 > Project: Jackrabbit Oak > Issue Type: Improvement >Affects Versions: 1.0.15 >Reporter: Shashank Gupta >Assignee: Shashank Gupta > Fix For: 1.0.16 > > > OSGI service wrapper for JCR-3869 which provides CachingDataStore > capabilities for SAN & NAS storage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2829) Comparing node states for external changes is too slow
[ https://issues.apache.org/jira/browse/OAK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589665#comment-14589665 ] Marcel Reutegger commented on OAK-2829: --- For now I would rather keep it simple and include everything. But it's an enhancement we should keep in mind. > Comparing node states for external changes is too slow > -- > > Key: OAK-2829 > URL: https://issues.apache.org/jira/browse/OAK-2829 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Blocker > Labels: scalability > Fix For: 1.3.1, 1.2.3 > > Attachments: CompareAgainstBaseStateTest.java, OAK-2829-gc-bug.patch, > OAK-2829-improved-doc-cache-invaliation.2.patch, > OAK-2829-improved-doc-cache-invaliation.patch, graph-1.png, graph.png > > > Comparing node states for local changes has been improved already with > OAK-2669. But in a clustered setup generating events for external changes > cannot make use of the introduced cache and is therefore slower. This can > result in a growing observation queue, eventually reaching the configured > limit. See also OAK-2683. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3004) OSGI wrapper service for Jackrabbit CachingFDS
[ https://issues.apache.org/jira/browse/OAK-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589662#comment-14589662 ] Chetan Mehrotra commented on OAK-3004: -- [~shgu...@adobe.com] is this duplicate of OAK-3005? > OSGI wrapper service for Jackrabbit CachingFDS > -- > > Key: OAK-3004 > URL: https://issues.apache.org/jira/browse/OAK-3004 > Project: Jackrabbit Oak > Issue Type: Improvement >Affects Versions: 1.0.15 >Reporter: Shashank Gupta >Assignee: Shashank Gupta > Fix For: 1.0.16 > > > OSGI service wrapper for JCR-3869 which provides CachingDataStore > capabilities for SAN & NAS storage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3005) OSGI wrapper service for Jackrabbit CachingFDS
[
https://issues.apache.org/jira/browse/OAK-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589661#comment-14589661
]
Chetan Mehrotra edited comment on OAK-3005 at 6/17/15 11:47 AM:
[~shgu...@adobe.com] Given we already use Guava in Oak it might be better to
just make use of them and have a simple CachingDataStore impl. Have a look at
{{DataStoreBlobStore#getInputStream}} where we have some caching done for small
binaries on heap.
Extrapolating that design in following way would allow us to implement a simple
FS based caching layer
# Have a new cache where the cached value is File (or some instance which keeps
a reference to File)
# Provide support for Weight via a simple
[Weigher|http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/cache/Weigher.html]
which is based on File size
# Register a
[RemovalListener|http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/cache/RemovalListener.html]
which removes the file from file system upon eviction
# Provide a
[CacheLoader|http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/cache/CacheLoader.html]
which spools the remote binary to local filesystem
This should be a small logic and would provide you all benefits of Guava cache
including cache stats. And this would transparently work for any DataStore.
May be we implement it at {{BlobStore}} level itself and then it would be
useful for other BlobStore also. Doing it at BlobStore level would require some
support from {{BlobStore}} to determine the blob length from blobId itself.
[1] https://code.google.com/p/guava-libraries/wiki/CachesExplained
was (Author: chetanm):
[~shgu...@adobe.com] Given we already use Guava in Oak it might be better to
just make use of them and have a simple CachingDataStore impl. Have a look at
{{DataStoreBlobStore#getInputStream}} where we have some caching done for small
binaries on heap.
Extrapolating that design in following way would allow us to implement a simple
FS based caching layer
# Have a new cache where the cached value is File (or some instance which keeps
a reference to File)
# Provide support for Weight via a simple
[Weigher|http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/cache/Weigher.html]
which is based on File size
# Register a
[RemovalListener|http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/cache/RemovalListener.html]
which removes the file from file system upon eviction
# Provide a loader which spools the remote binary to local filesystem
This should be a small logic and would provide you all benefits of Guava cache
including cache stats. And this would transparently work for any DataStore.
May be we implement it at {{BlobStore}} level itself and then it would be
useful for other BlobStore also. Doing it at BlobStore level would require some
support from {{BlobStore}} to determine the blob length from blobId itself.
[1] https://code.google.com/p/guava-libraries/wiki/CachesExplained
> OSGI wrapper service for Jackrabbit CachingFDS
> --
>
> Key: OAK-3005
> URL: https://issues.apache.org/jira/browse/OAK-3005
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob
>Affects Versions: 1.0.15
>Reporter: Shashank Gupta
>Assignee: Shashank Gupta
> Labels: features, performance
> Fix For: 1.0.16
>
> Attachments: OAK-2729.patch
>
>
> OSGI service wrapper for JCR-3869 which provides CachingDataStore
> capabilities for SAN & NAS storage
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3005) OSGI wrapper service for Jackrabbit CachingFDS
[
https://issues.apache.org/jira/browse/OAK-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589661#comment-14589661
]
Chetan Mehrotra commented on OAK-3005:
--
[~shgu...@adobe.com] Given we already use Guava in Oak it might be better to
just make use of them and have a simple CachingDataStore impl. Have a look at
{{DataStoreBlobStore#getInputStream}} where we have some caching done for small
binaries on heap.
Extrapolating that design in following way would allow us to implement a simple
FS based caching layer
# Have a new cache where the cached value is File (or some instance which keeps
a reference to File)
# Provide support for Weight via a simple
[Weigher|http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/cache/Weigher.html]
which is based on File size
# Register a
[RemovalListener|http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/cache/RemovalListener.html]
which removes the file from file system upon eviction
# Provide a loader which spools the remote binary to local filesystem
This should be a small logic and would provide you all benefits of Guava cache
including cache stats. And this would transparently work for any DataStore.
May be we implement it at {{BlobStore}} level itself and then it would be
useful for other BlobStore also. Doing it at BlobStore level would require some
support from {{BlobStore}} to determine the blob length from blobId itself.
[1] https://code.google.com/p/guava-libraries/wiki/CachesExplained
> OSGI wrapper service for Jackrabbit CachingFDS
> --
>
> Key: OAK-3005
> URL: https://issues.apache.org/jira/browse/OAK-3005
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob
>Affects Versions: 1.0.15
>Reporter: Shashank Gupta
>Assignee: Shashank Gupta
> Labels: features, performance
> Fix For: 1.0.16
>
> Attachments: OAK-2729.patch
>
>
> OSGI service wrapper for JCR-3869 which provides CachingDataStore
> capabilities for SAN & NAS storage
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3003) Improve login performance with huge group membership
[
https://issues.apache.org/jira/browse/OAK-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589643#comment-14589643
]
angela commented on OAK-3003:
-
this issue extends from OAK-2690 (adding link). see also benchmark results in
OAK-2690 for comparison.
> Improve login performance with huge group membership
>
>
> Key: OAK-3003
> URL: https://issues.apache.org/jira/browse/OAK-3003
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: angela
>Assignee: angela
> Attachments: OAK-3003.patch, group_cache_in_userprincipalprovider.txt
>
>
> As visible when running {{LoginWithMembershipTest}} default login performance
> (which uses the {{o.a.j.oak.security.principal.PrincipalProviderImpl}} to
> lookup the complete set of principals) suffers when a given user is member of
> a huge number of groups (see also OAK-2690 for benchmark data).
> While using dynamic group membership (and thus a custom {{PrincipalProvider}}
> would be the preferable way to deal with this, we still want to optimize
> {{PrincipalProvider.getPrincipals(String userId}} for the default
> implementation.
> With the introduction of a less generic implementation in OAK-2690, we might
> be able to come up with an optimization that makes use of the very
> implementation details of the user management while at the same time being
> able to properly secure it as we won't need to extend the public API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3005) OSGI wrapper service for Jackrabbit CachingFDS
[ https://issues.apache.org/jira/browse/OAK-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shashank Gupta updated OAK-3005: Labels: features patch performance (was: ) > OSGI wrapper service for Jackrabbit CachingFDS > -- > > Key: OAK-3005 > URL: https://issues.apache.org/jira/browse/OAK-3005 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Affects Versions: 1.0.15 >Reporter: Shashank Gupta >Assignee: Shashank Gupta > Labels: features, performance > Fix For: 1.0.16 > > Attachments: OAK-2729.patch > > > OSGI service wrapper for JCR-3869 which provides CachingDataStore > capabilities for SAN & NAS storage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3005) OSGI wrapper service for Jackrabbit CachingFDS
[ https://issues.apache.org/jira/browse/OAK-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shashank Gupta updated OAK-3005: Labels: features performance (was: features patch performance) > OSGI wrapper service for Jackrabbit CachingFDS > -- > > Key: OAK-3005 > URL: https://issues.apache.org/jira/browse/OAK-3005 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Affects Versions: 1.0.15 >Reporter: Shashank Gupta >Assignee: Shashank Gupta > Labels: features, performance > Fix For: 1.0.16 > > Attachments: OAK-2729.patch > > > OSGI service wrapper for JCR-3869 which provides CachingDataStore > capabilities for SAN & NAS storage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3005) OSGI wrapper service for Jackrabbit CachingFDS
[ https://issues.apache.org/jira/browse/OAK-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shashank Gupta updated OAK-3005: Attachment: OAK-2729.patch patch attached. 18 test cases are added in [TestCachingFDS.java|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-data/src/test/java/org/apache/jackrabbit/core/data/TestCachingFDS.java] & [TestCachingFDSCacheOff.java|https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-data/src/test/java/org/apache/jackrabbit/core/data/TestCachingFDSCacheOff.java] > OSGI wrapper service for Jackrabbit CachingFDS > -- > > Key: OAK-3005 > URL: https://issues.apache.org/jira/browse/OAK-3005 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Affects Versions: 1.0.15 >Reporter: Shashank Gupta >Assignee: Shashank Gupta > Fix For: 1.0.16 > > Attachments: OAK-2729.patch > > > OSGI service wrapper for JCR-3869 which provides CachingDataStore > capabilities for SAN & NAS storage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3005) OSGI wrapper service for Jackrabbit CachingFDS
[ https://issues.apache.org/jira/browse/OAK-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shashank Gupta updated OAK-3005: Component/s: blob > OSGI wrapper service for Jackrabbit CachingFDS > -- > > Key: OAK-3005 > URL: https://issues.apache.org/jira/browse/OAK-3005 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Affects Versions: 1.0.15 >Reporter: Shashank Gupta >Assignee: Shashank Gupta > Fix For: 1.0.16 > > Attachments: OAK-2729.patch > > > OSGI service wrapper for JCR-3869 which provides CachingDataStore > capabilities for SAN & NAS storage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3005) OSGI wrapper service for Jackrabbit CachingFDS
Shashank Gupta created OAK-3005: --- Summary: OSGI wrapper service for Jackrabbit CachingFDS Key: OAK-3005 URL: https://issues.apache.org/jira/browse/OAK-3005 Project: Jackrabbit Oak Issue Type: Improvement Affects Versions: 1.0.15 Reporter: Shashank Gupta Assignee: Shashank Gupta Fix For: 1.0.16 OSGI service wrapper for JCR-3869 which provides CachingDataStore capabilities for SAN & NAS storage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3004) OSGI wrapper service for Jackrabbit CachingFDS
Shashank Gupta created OAK-3004: --- Summary: OSGI wrapper service for Jackrabbit CachingFDS Key: OAK-3004 URL: https://issues.apache.org/jira/browse/OAK-3004 Project: Jackrabbit Oak Issue Type: Improvement Affects Versions: 1.0.15 Reporter: Shashank Gupta Assignee: Shashank Gupta Fix For: 1.0.16 OSGI service wrapper for JCR-3869 which provides CachingDataStore capabilities for SAN & NAS storage -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3002) Optimize docCache by filtering using journal
[
https://issues.apache.org/jira/browse/OAK-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589631#comment-14589631
]
Stefan Egli commented on OAK-3002:
--
[~chetanm], good point indeed. However, the way the journal is structured
currently doing this check atm still results in fewer invalidated entries.
Here's why:
* the journal contains a tree of nodes that have changed. However, it does not
yet indicate if a non-leaf node has changed or not. For a leaf-node it is
clear, that has changed. But for a non-leaf that is atm not yet marked in any
way (maybe we could do that).
* the result of this is, that we treat non-leaf nodes as changed as well -
which we overlay with checks as to whether something really has changed (be
that somewhere in {{diff()}} or in {{invalidateCache(Iterable)}}.
* now when it comes to invalidating it could be that the cache already has a
non-leaf node in an up-to-date version, so doing a {{modCnt}} check helps
finding that out and subsequently avoiding invalidating if the document is
indeed the most current one.
I have done some testing and found that it can invalidate between very roughly
1 and 50% fewer documents doing this check (I can attach the test case once
polished properly, it's a bit hacky atm).
Now of course the time of doing the modCnt-check needs to be compared with the
gain. Perhaps my test case was too much geared towards doing many changes thus
yields better and in real-life it would be 'good enough' to invalidate all ids
(leafs and non-leafs) of the journal. So it's difficult to say if the gain is
really big.
Also, we could perhaps do better and mark non-leafs explicitly somehow if they
have changed as well (other than the fact that a child has changed)
> Optimize docCache by filtering using journal
>
>
> Key: OAK-3002
> URL: https://issues.apache.org/jira/browse/OAK-3002
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, mongomk
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: scalability
> Fix For: 1.3.1, 1.2.3
>
> Attachments: OAK-3002-improved-doc-cache-invaliation.2.patch
>
>
> This subtask is about spawning out a
> [comment|https://issues.apache.org/jira/browse/OAK-2829?focusedCommentId=14588114&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14588114]
> on OAK-2829 re optimizing docCache invalidation using the newly introduced
> external diff journal:
> {quote}
> Attached OAK-2829-improved-doc-cache-invaliation.patch which is a suggestion
> on how to avoid invalidating the entire document cache when doing a
> {{backgroundRead}} but instead making use of the new journal: ie only
> invalidate from the document cache what has actually changed.
> I'd like to get an opinion ([~mreutegg], [~chetanm]?) on this first, I have a
> load test pending locally which found invalidation of the document cache to
> be the slowest part thus wanted to optimize this first.
> Open still/next:
> * also invalidate only necessary parts from the docChildrenCache
> * junits for all of these
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2999) Index updation fails on updating multivalued property
[
https://issues.apache.org/jira/browse/OAK-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589622#comment-14589622
]
Amit Jain commented on OAK-2999:
Sure
> Index updation fails on updating multivalued property
> -
>
> Key: OAK-2999
> URL: https://issues.apache.org/jira/browse/OAK-2999
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.2, 1.0.15
>Reporter: Rishabh Maurya
>Assignee: Chetan Mehrotra
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
>
> On emptying a multivalued property, fulltext index updation fails and one can
> search on old values. Following test demonstrates the issue.
> Added below test in
> [LuceneIndexQueryTest.java|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexQueryTest.java]
> which should pass -
> {code}
> @Test
> public void testMultiValuedPropUpdate() throws Exception {
> Tree test = root.getTree("/").addChild("test");
> String child = "child";
> String mulValuedProp = "prop";
> test.addChild(child).setProperty(mulValuedProp, of("foo","bar"),
> Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", ImmutableList.of("/test/" + child));
> test.getChild(child).setProperty(mulValuedProp, new
> ArrayList(), Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", new ArrayList());
> test.getChild(child).setProperty(mulValuedProp, of("bar"),
> Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", new ArrayList());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2999) Index updation fails on updating multivalued property
[
https://issues.apache.org/jira/browse/OAK-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589617#comment-14589617
]
Chetan Mehrotra commented on OAK-2999:
--
[~amitj_76] Can you have a look at this issue
> Index updation fails on updating multivalued property
> -
>
> Key: OAK-2999
> URL: https://issues.apache.org/jira/browse/OAK-2999
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.2, 1.0.15
>Reporter: Rishabh Maurya
>Assignee: Chetan Mehrotra
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
>
> On emptying a multivalued property, fulltext index updation fails and one can
> search on old values. Following test demonstrates the issue.
> Added below test in
> [LuceneIndexQueryTest.java|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexQueryTest.java]
> which should pass -
> {code}
> @Test
> public void testMultiValuedPropUpdate() throws Exception {
> Tree test = root.getTree("/").addChild("test");
> String child = "child";
> String mulValuedProp = "prop";
> test.addChild(child).setProperty(mulValuedProp, of("foo","bar"),
> Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", ImmutableList.of("/test/" + child));
> test.getChild(child).setProperty(mulValuedProp, new
> ArrayList(), Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", new ArrayList());
> test.getChild(child).setProperty(mulValuedProp, of("bar"),
> Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", new ArrayList());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2999) Index updation fails on updating multivalued property
[
https://issues.apache.org/jira/browse/OAK-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2999:
-
Fix Version/s: 1.0.16
1.2.3
1.3.1
> Index updation fails on updating multivalued property
> -
>
> Key: OAK-2999
> URL: https://issues.apache.org/jira/browse/OAK-2999
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.2, 1.0.15
>Reporter: Rishabh Maurya
>Assignee: Chetan Mehrotra
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
>
> On emptying a multivalued property, fulltext index updation fails and one can
> search on old values. Following test demonstrates the issue.
> Added below test in
> [LuceneIndexQueryTest.java|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexQueryTest.java]
> which should pass -
> {code}
> @Test
> public void testMultiValuedPropUpdate() throws Exception {
> Tree test = root.getTree("/").addChild("test");
> String child = "child";
> String mulValuedProp = "prop";
> test.addChild(child).setProperty(mulValuedProp, of("foo","bar"),
> Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", ImmutableList.of("/test/" + child));
> test.getChild(child).setProperty(mulValuedProp, new
> ArrayList(), Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", new ArrayList());
> test.getChild(child).setProperty(mulValuedProp, of("bar"),
> Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", new ArrayList());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2999) Index updation fails on updating multivalued property
[
https://issues.apache.org/jira/browse/OAK-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589615#comment-14589615
]
Chetan Mehrotra commented on OAK-2999:
--
Interesting issue!! {{LuceneIndexEditor}} only adds a Lucene Document for a
node if there is a field created. In current case what happens is like this
# A node with a single MVP is created and indexed. Indexing logic checks for
property -> Finds it indexable -> Loops over MVP -> create fields -> Lucene
Document get created
# Later that MVP is set to empty. The change is detected by
{{LuceneIndexEditor}} -> Finds it indexable -> Loops over the MVP -> No field
gets created and hence no Document gets written. Due to this old Document does
not get overwritten and continues to get shown in search result
As a fix the indexing logic should check if the property is indexable and
create an empty Document if no field is created. Note that this should only be
done the property (which is indexed) is change and previous state of property
was not empty
> Index updation fails on updating multivalued property
> -
>
> Key: OAK-2999
> URL: https://issues.apache.org/jira/browse/OAK-2999
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.2, 1.0.15
>Reporter: Rishabh Maurya
>Assignee: Chetan Mehrotra
>
> On emptying a multivalued property, fulltext index updation fails and one can
> search on old values. Following test demonstrates the issue.
> Added below test in
> [LuceneIndexQueryTest.java|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexQueryTest.java]
> which should pass -
> {code}
> @Test
> public void testMultiValuedPropUpdate() throws Exception {
> Tree test = root.getTree("/").addChild("test");
> String child = "child";
> String mulValuedProp = "prop";
> test.addChild(child).setProperty(mulValuedProp, of("foo","bar"),
> Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", ImmutableList.of("/test/" + child));
> test.getChild(child).setProperty(mulValuedProp, new
> ArrayList(), Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", new ArrayList());
> test.getChild(child).setProperty(mulValuedProp, of("bar"),
> Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", new ArrayList());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2999) Index updation fails on updating multivalued property
[
https://issues.apache.org/jira/browse/OAK-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2999:
-
Affects Version/s: 1.2
> Index updation fails on updating multivalued property
> -
>
> Key: OAK-2999
> URL: https://issues.apache.org/jira/browse/OAK-2999
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.2, 1.0.15
>Reporter: Rishabh Maurya
>Assignee: Chetan Mehrotra
>
> On emptying a multivalued property, fulltext index updation fails and one can
> search on old values. Following test demonstrates the issue.
> Added below test in
> [LuceneIndexQueryTest.java|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexQueryTest.java]
> which should pass -
> {code}
> @Test
> public void testMultiValuedPropUpdate() throws Exception {
> Tree test = root.getTree("/").addChild("test");
> String child = "child";
> String mulValuedProp = "prop";
> test.addChild(child).setProperty(mulValuedProp, of("foo","bar"),
> Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", ImmutableList.of("/test/" + child));
> test.getChild(child).setProperty(mulValuedProp, new
> ArrayList(), Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", new ArrayList());
> test.getChild(child).setProperty(mulValuedProp, of("bar"),
> Type.STRINGS);
> root.commit();
> assertQuery(
> "/jcr:root//*[jcr:contains(@" + mulValuedProp + ", 'foo')]",
> "xpath", new ArrayList());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2829) Comparing node states for external changes is too slow
[ https://issues.apache.org/jira/browse/OAK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589605#comment-14589605 ] Chetan Mehrotra commented on OAK-2829: -- [~mreutegg] [~egli] Should we also add support for excluding paths under index node i.e. hidden paths to reduce the count of paths added to the journal > Comparing node states for external changes is too slow > -- > > Key: OAK-2829 > URL: https://issues.apache.org/jira/browse/OAK-2829 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Blocker > Labels: scalability > Fix For: 1.3.1, 1.2.3 > > Attachments: CompareAgainstBaseStateTest.java, OAK-2829-gc-bug.patch, > OAK-2829-improved-doc-cache-invaliation.2.patch, > OAK-2829-improved-doc-cache-invaliation.patch, graph-1.png, graph.png > > > Comparing node states for local changes has been improved already with > OAK-2669. But in a clustered setup generating events for external changes > cannot make use of the introduced cache and is therefore slower. This can > result in a growing observation queue, eventually reaching the configured > limit. See also OAK-2683. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3002) Optimize docCache by filtering using journal
[
https://issues.apache.org/jira/browse/OAK-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589602#comment-14589602
]
Chetan Mehrotra commented on OAK-3002:
--
Bit confused on the approach. The journal would already provide the list of ids
which have been modified on the Mongo side. So the invalidation logic can just
evict those entries from the cache and need not perform any further check with
Mongo. However the logic in {{invalidateCache(Iterable paths)}} looks
like perform the check against Mongo. Should not it just make use of ids and
invalidate them
> Optimize docCache by filtering using journal
>
>
> Key: OAK-3002
> URL: https://issues.apache.org/jira/browse/OAK-3002
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, mongomk
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: scalability
> Fix For: 1.3.1, 1.2.3
>
> Attachments: OAK-3002-improved-doc-cache-invaliation.2.patch
>
>
> This subtask is about spawning out a
> [comment|https://issues.apache.org/jira/browse/OAK-2829?focusedCommentId=14588114&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14588114]
> on OAK-2829 re optimizing docCache invalidation using the newly introduced
> external diff journal:
> {quote}
> Attached OAK-2829-improved-doc-cache-invaliation.patch which is a suggestion
> on how to avoid invalidating the entire document cache when doing a
> {{backgroundRead}} but instead making use of the new journal: ie only
> invalidate from the document cache what has actually changed.
> I'd like to get an opinion ([~mreutegg], [~chetanm]?) on this first, I have a
> load test pending locally which found invalidation of the document cache to
> be the slowest part thus wanted to optimize this first.
> Open still/next:
> * also invalidate only necessary parts from the docChildrenCache
> * junits for all of these
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3002) Optimize docCache by filtering using journal
[
https://issues.apache.org/jira/browse/OAK-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3002:
-
Assignee: Stefan Egli
> Optimize docCache by filtering using journal
>
>
> Key: OAK-3002
> URL: https://issues.apache.org/jira/browse/OAK-3002
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, mongomk
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: scalability
> Fix For: 1.3.1, 1.2.3
>
> Attachments: OAK-3002-improved-doc-cache-invaliation.2.patch
>
>
> This subtask is about spawning out a
> [comment|https://issues.apache.org/jira/browse/OAK-2829?focusedCommentId=14588114&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14588114]
> on OAK-2829 re optimizing docCache invalidation using the newly introduced
> external diff journal:
> {quote}
> Attached OAK-2829-improved-doc-cache-invaliation.patch which is a suggestion
> on how to avoid invalidating the entire document cache when doing a
> {{backgroundRead}} but instead making use of the new journal: ie only
> invalidate from the document cache what has actually changed.
> I'd like to get an opinion ([~mreutegg], [~chetanm]?) on this first, I have a
> load test pending locally which found invalidation of the document cache to
> be the slowest part thus wanted to optimize this first.
> Open still/next:
> * also invalidate only necessary parts from the docChildrenCache
> * junits for all of these
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2829) Comparing node states for external changes is too slow
[ https://issues.apache.org/jira/browse/OAK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589595#comment-14589595 ] Marcel Reutegger commented on OAK-2829: --- Addressed TODO in JournalEntry: http://svn.apache.org/r1685989 > Comparing node states for external changes is too slow > -- > > Key: OAK-2829 > URL: https://issues.apache.org/jira/browse/OAK-2829 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Blocker > Labels: scalability > Fix For: 1.3.1, 1.2.3 > > Attachments: CompareAgainstBaseStateTest.java, OAK-2829-gc-bug.patch, > OAK-2829-improved-doc-cache-invaliation.2.patch, > OAK-2829-improved-doc-cache-invaliation.patch, graph-1.png, graph.png > > > Comparing node states for local changes has been improved already with > OAK-2669. But in a clustered setup generating events for external changes > cannot make use of the introduced cache and is therefore slower. This can > result in a growing observation queue, eventually reaching the configured > limit. See also OAK-2683. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2401) SegmentNodeStoreService prone to deadlocks
[
https://issues.apache.org/jira/browse/OAK-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589588#comment-14589588
]
Chetan Mehrotra commented on OAK-2401:
--
I do not think this issue is related to BlobStore registration. So changing
that would not solve this issue at least
Further in a given system there should be one and only one BlobStore configured
and they should be configured once and not changed once a setup is running.
Otherwise it would lead to repository state inconsistency where some binaries
may be written to BlobStore and some not. So this would be a setup issue and
outside of SegmentNodeStoreService control
> SegmentNodeStoreService prone to deadlocks
> --
>
> Key: OAK-2401
> URL: https://issues.apache.org/jira/browse/OAK-2401
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: resilience
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-2401-01.patch, OAK-2401-02.patch, OAK-2401-03.patch,
> OAK-2401-04-testcase-fix.patch, OAK-2401.patch
>
>
> The SegmentNodeStoreService is prone to deadlocks because of the way in which
> is synchronizes access to the _SegmentNodeStore_ delegate.
> The issue can now be seen on #deactivate, when the deregistration is being
> synchronously broadcast and if a referring service calls #getNodeStore the
> deadlock happens.
> {code}
> Found one Java-level deadlock:
> =
> "qtp844483043-936":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)":
> waiting to lock monitor 0x01d4d0907c88 (object 0x01d2334be930, a
> java.lang.Object),
> which is held by "pool-5-thread-4"
> "pool-5-thread-4":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> Java stack information for the threads listed above:
> ===
> "qtp844483043-936":
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:144)
> - waiting to lock <0x01d231f52698> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:73)
> at
> org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.getRoot(ProxyNodeStore.java:35)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.(MutableRoot.java:160)
> at
> org.apache.jackrabbit.oak.core.ContentSessionImpl.getLatestRoot(ContentSessionImpl.java:110)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getRoot(AbstractLoginModule.java:403)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.getTokenProvider(TokenLoginModule.java:215)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.login(TokenLoginModule.java:128)
> at
> org.apache.felix.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:52)
> at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595)
> at
> org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:161)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:256)
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:92)
> at
> org.a
[jira] [Updated] (OAK-3003) Improve login performance with huge group membership
[
https://issues.apache.org/jira/browse/OAK-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-3003:
Attachment: group_cache_in_userprincipalprovider.txt
OAK-3003.patch
initial proposal including some preliminary figures from the
{{LoginWithMembershipTest}}.
[~djaeggi], [~chaotic], would it be possible to look at the proposal? the goal
was to tmp. cache group-principals as calculated upon
{{PermissionProvider#getPrincipals(String)}} but making sure this is only
writable by the system session compiling that list upon login.
TODO:
- verify proper handling of potential collisions upon concurrent login
- verify there is _really_ no way to exploit this
- verify behavior in clustered environment.
however, before investing a lot of effort, i would be glad to get feedback from
my fellows in the security team :-)
> Improve login performance with huge group membership
>
>
> Key: OAK-3003
> URL: https://issues.apache.org/jira/browse/OAK-3003
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: angela
>Assignee: angela
> Attachments: OAK-3003.patch, group_cache_in_userprincipalprovider.txt
>
>
> As visible when running {{LoginWithMembershipTest}} default login performance
> (which uses the {{o.a.j.oak.security.principal.PrincipalProviderImpl}} to
> lookup the complete set of principals) suffers when a given user is member of
> a huge number of groups (see also OAK-2690 for benchmark data).
> While using dynamic group membership (and thus a custom {{PrincipalProvider}}
> would be the preferable way to deal with this, we still want to optimize
> {{PrincipalProvider.getPrincipals(String userId}} for the default
> implementation.
> With the introduction of a less generic implementation in OAK-2690, we might
> be able to come up with an optimization that makes use of the very
> implementation details of the user management while at the same time being
> able to properly secure it as we won't need to extend the public API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2401) SegmentNodeStoreService prone to deadlocks
[
https://issues.apache.org/jira/browse/OAK-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589574#comment-14589574
]
Francesco Mari commented on OAK-2401:
-
There is still the window open by the {{bindBlobStore()}} and
{{unbindBlobStore()}} methods. They occur asynchronously and need
synchronisation. Moreover, when a bound service is replaced with a better one,
{{unbindBlobStore()}} for the old service is called after the
{{bindBlobStore()}} for the new service, thus deregistering the new
registrations made available by {{registerNodeStore()}}.
The more I think about it, the more I'm convinced that we should have a static,
greedy reference to the {{BlobStore}} and solve every synchronisation problem
at once in the most straightforward way.
> SegmentNodeStoreService prone to deadlocks
> --
>
> Key: OAK-2401
> URL: https://issues.apache.org/jira/browse/OAK-2401
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: resilience
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-2401-01.patch, OAK-2401-02.patch, OAK-2401-03.patch,
> OAK-2401-04-testcase-fix.patch, OAK-2401.patch
>
>
> The SegmentNodeStoreService is prone to deadlocks because of the way in which
> is synchronizes access to the _SegmentNodeStore_ delegate.
> The issue can now be seen on #deactivate, when the deregistration is being
> synchronously broadcast and if a referring service calls #getNodeStore the
> deadlock happens.
> {code}
> Found one Java-level deadlock:
> =
> "qtp844483043-936":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)":
> waiting to lock monitor 0x01d4d0907c88 (object 0x01d2334be930, a
> java.lang.Object),
> which is held by "pool-5-thread-4"
> "pool-5-thread-4":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> Java stack information for the threads listed above:
> ===
> "qtp844483043-936":
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:144)
> - waiting to lock <0x01d231f52698> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:73)
> at
> org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.getRoot(ProxyNodeStore.java:35)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.(MutableRoot.java:160)
> at
> org.apache.jackrabbit.oak.core.ContentSessionImpl.getLatestRoot(ContentSessionImpl.java:110)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getRoot(AbstractLoginModule.java:403)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.getTokenProvider(TokenLoginModule.java:215)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.login(TokenLoginModule.java:128)
> at
> org.apache.felix.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:52)
> at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595)
> at
> org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:161)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:256
[jira] [Resolved] (OAK-2997) Document mapping between built-in privileges and API calls + items
[ https://issues.apache.org/jira/browse/OAK-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-2997. - Resolution: Fixed Fix Version/s: (was: 1.4) 1.3.1 Committed revision 1685980 > Document mapping between built-in privileges and API calls + items > -- > > Key: OAK-2997 > URL: https://issues.apache.org/jira/browse/OAK-2997 > Project: Jackrabbit Oak > Issue Type: Task > Components: doc >Reporter: angela >Assignee: angela > Fix For: 1.3.1 > > > while the permission documentation explains the meaning of each oak > permission, this is missing for the built-in privileges which would be more > relevant for API consumers. > i would therefore suggest to add a table with the following information > - privilege name > - API calls > - name of items affected by the privilege -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2829) Comparing node states for external changes is too slow
[ https://issues.apache.org/jira/browse/OAK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589560#comment-14589560 ] Marcel Reutegger commented on OAK-2829: --- Added tests for JournalEntry: http://svn.apache.org/r1685977 > Comparing node states for external changes is too slow > -- > > Key: OAK-2829 > URL: https://issues.apache.org/jira/browse/OAK-2829 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Blocker > Labels: scalability > Fix For: 1.3.1, 1.2.3 > > Attachments: CompareAgainstBaseStateTest.java, OAK-2829-gc-bug.patch, > OAK-2829-improved-doc-cache-invaliation.2.patch, > OAK-2829-improved-doc-cache-invaliation.patch, graph-1.png, graph.png > > > Comparing node states for local changes has been improved already with > OAK-2669. But in a clustered setup generating events for external changes > cannot make use of the introduced cache and is therefore slower. This can > result in a growing observation queue, eventually reaching the configured > limit. See also OAK-2683. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2829) Comparing node states for external changes is too slow
[ https://issues.apache.org/jira/browse/OAK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589513#comment-14589513 ] Marcel Reutegger commented on OAK-2829: --- - Reformatted the code. Some classes used tabs instead of spaces. - Reduced the READ_CHUNK_SIZE to 100 - Kept the exception handling in backgroundRead, but now the diff cache is only populated when reading the journal entries was successful. This means if reading journal entries fails the diff cache is not populated and diffs must be calculated when requested Done in trunk: http://svn.apache.org/r1685964 > Comparing node states for external changes is too slow > -- > > Key: OAK-2829 > URL: https://issues.apache.org/jira/browse/OAK-2829 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Blocker > Labels: scalability > Fix For: 1.3.1, 1.2.3 > > Attachments: CompareAgainstBaseStateTest.java, OAK-2829-gc-bug.patch, > OAK-2829-improved-doc-cache-invaliation.2.patch, > OAK-2829-improved-doc-cache-invaliation.patch, graph-1.png, graph.png > > > Comparing node states for local changes has been improved already with > OAK-2669. But in a clustered setup generating events for external changes > cannot make use of the introduced cache and is therefore slower. This can > result in a growing observation queue, eventually reaching the configured > limit. See also OAK-2683. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-2401) SegmentNodeStoreService prone to deadlocks
[
https://issues.apache.org/jira/browse/OAK-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589325#comment-14589325
]
Chetan Mehrotra edited comment on OAK-2401 at 6/17/15 8:59 AM:
---
bq. declare the reference to the BlobStore to be static, greedy and optional
[~frm] Not sure if that is the problem. {{SegmentNodeStoreService}} does not
make call to foreign code from within the synchronized block (except in
deactivate, explained later in comment). So its doing the right thing there. At
least for this issue the problem was in Discovery as it was calling to
framework while holding the locks.
As you noted
bq. The biggest issue, in my opinion, is synchronized keyword on the
getNodeStore() method. This excessive locking interferes with the lifecycle of
the component in the OSGi framework.
The required fix here would be
# Drop synchronized from {{getNodeStore}} and mark delegate as volatile - A
NodeStore instance would only be available to outside world once it is
registered with OSGi ServiceRegistery and by that time NodeStore would be
properly initialized. So for startup case no call can come for {{getNodeStore}}
untill it gets initialized.
# Drop synchronized from the deactivate - By contract the deactivate would only
be called from a single thread. Or if we want to play safe do the unregistering
part outside of synchronized. This would ensure that we do not hold any lock
while calling to OSGi (which infact is the root cause of deadlock here)
With this change for above scenario should work fine.
I think we should
was (Author: chetanm):
bq. declare the reference to the BlobStore to be static, greedy and optional
[~frm] Not sure if that is the problem. {{SegmentNodeStoreService}} does not
make call to foreign code from within the synchronized block. So its doing the
right thing there. At least for this issue the problem was in Discovery as it
was calling to framework while holding the locks.
As you noted
bq. The biggest issue, in my opinion, is synchronized keyword on the
getNodeStore() method. This excessive locking interferes with the lifecycle of
the component in the OSGi framework.
The required fix here would be
# Drop synchronized from {{getNodeStore}} and mark delegate as volatile - A
NodeStore instance would only be available to outside world once it is
registered with OSGi ServiceRegistery and by that time NodeStore would be
properly initialized. So for startup case no call can come for {{getNodeStore}}
untill it gets initialized.
# Drop synchronized from the deactivate - By contract the deactivate would only
be called from a single thread. Or if we want to play safe do the unregistering
part outside of synchronized. This would ensure that we do not hold any lock
while calling to OSGi (which infact is the root cause of deadlock here)
With this change for above scenario should work fine.
I think we should
> SegmentNodeStoreService prone to deadlocks
> --
>
> Key: OAK-2401
> URL: https://issues.apache.org/jira/browse/OAK-2401
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: resilience
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-2401-01.patch, OAK-2401-02.patch, OAK-2401-03.patch,
> OAK-2401-04-testcase-fix.patch, OAK-2401.patch
>
>
> The SegmentNodeStoreService is prone to deadlocks because of the way in which
> is synchronizes access to the _SegmentNodeStore_ delegate.
> The issue can now be seen on #deactivate, when the deregistration is being
> synchronously broadcast and if a referring service calls #getNodeStore the
> deadlock happens.
> {code}
> Found one Java-level deadlock:
> =
> "qtp844483043-936":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)":
> waiting to lock monitor 0x01d4d0907c88 (object 0x01d2334be930, a
> java.lang.Object),
> which is held by "pool-5-thread-4"
> "pool-5-thread-4":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> Java stack information for the threads listed above:
> ==
[jira] [Commented] (OAK-2961) Async index fails with OakState0001: Unresolved conflicts in /:async
[
https://issues.apache.org/jira/browse/OAK-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589478#comment-14589478
]
Davide Giannella commented on OAK-2961:
---
[~alexparvulescu] we may be needing this for 1.0 as well. Let me see after
applying the patch if it solves and if it's easy to backport.
> Async index fails with OakState0001: Unresolved conflicts in /:async
>
>
> Key: OAK-2961
> URL: https://issues.apache.org/jira/browse/OAK-2961
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk, query
>Affects Versions: 1.2.2, 1.0.14, 1.4
>Reporter: Davide Giannella
>Assignee: Davide Giannella
> Labels: resilience
> Fix For: 1.3.1, 1.2.3
>
> Attachments: OAK-2961.patch
>
>
> When running on a mongo cluster, in case of high activity the async index
> could fail with the following exception.
> Reproduced with LucenePropertyIndex.
> {noformat}
> 10:55:13.069 [oak-scheduled-executor-5] WARN
> o.a.j.o.p.index.AsyncIndexUpdate - [async] The index update failed
> org.apache.jackrabbit.oak.api.CommitFailedException: OakState0001: Unresolved
> conflicts in /:async
> at
> org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.failOnMergeConflict(ConflictValidator.java:84)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.propertyAdded(ConflictValidator.java:54)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.propertyAdded(EditorDiff.java:82)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:378)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:400)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:55)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:528)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:219)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:171)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:158)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1466)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.mergeWithConcurrencyCheck(AsyncIndexUpdate.java:467)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.access$4(AsyncIndexUpdate.java:445)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate$AsyncUpdateCallback.(AsyncIndexUpdate.java:201)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.updateIndex(AsyncIndexUpdate.java:372)
> ~[classes/:na]
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.run(AsyncIndexUpdate.java:320)
> ~[classes/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_60]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3000:
-
Attachment: OAK-3000.patch
[~tmueller] The patch had a issue with test expectation. I have the updated the
patch. Can you try with that
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3000:
-
Attachment: (was: OAK-3000.patch)
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589455#comment-14589455
]
Chetan Mehrotra commented on OAK-3000:
--
bq. I guess to avoid out of memory, and to give more reasonable results, we
should change the highlighter to use a BitField to remember which characters
are to be highlighted
[~tmueller] I am not sure weather we should further invest in
SimpleExcerptProvider. Instead we should switch to Lucene based highlighter
which should be more feature rich and robust
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589452#comment-14589452
]
Thomas Mueller commented on OAK-3000:
-
I guess to avoid out of memory, and to give more reasonable results, we should
change the highlighter to use a BitField to remember which characters are to be
highlighted, and then only in the final stage use "" "" where
applicable. I can come up with a patch for that.
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589442#comment-14589442
]
Thomas Mueller edited comment on OAK-3000 at 6/17/15 7:53 AM:
--
For me, the new test "highlightWithWildCard" fails. It says:
{noformat}
org.junit.ComparisonFailure: expected:
<[fox is jumping]>
but was:
<[fox is jumping]>
{noformat}
I'm not sure if the patch is correct. Debugging the code, it will try to
highlight "fox" and then "\*". Highlighting "fox" works, but highlighting "\*"
would highlight the character "\*". But I don't think the wildcard character
should be handled like this. I would expect it to be ignored:
{noformat}
@Test
public void highlightIgnoreStar() throws Exception {
assertEquals("10 * 10",
highlight(sb("10 * 10"), of("fox *")));
}
{noformat}
A bit unexpected (I would call it a bug) is that you can highlight the
intermediate HTML. That way, you can generate a strange, and very long result.
For example, this results in a 300 KB (!) long string:
{noformat}
highlight(sb("abc"), of("a < > o n st ng> ng on ong /")))
{noformat}
was (Author: tmueller):
For me, the new test "highlightWithWildCard" fails. It says:
{noformat}
org.junit.ComparisonFailure: expected:
<[fox is jumping]>
but was:
<[fox is jumping]>
{noformat}
I'm not sure if the patch is correct. Debugging the code, it will try to
highlight "fox" and then "*". Highlighting "fox" works, but highlighting "*"
would highlight the character "*". But I don't think the wildcard character
should be handled like this. I would expect it to be ignored:
{noformat}
@Test
public void highlightIgnoreStar() throws Exception {
assertEquals("10 * 10",
highlight(sb("10 * 10"), of("fox *")));
}
{noformat}
A bit unexpected (I would call it a bug) is that you can highlight the
intermediate HTML. That way, you can generate a strange, and very long result.
For example, this results in a 300 KB (!) long string:
{noformat}
highlight(sb("abc"), of("a < > o n st ng> ng on ong /")))
{noformat}
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3000) SimpleExcerptProvider causes OOM for some wildcard expressions
[
https://issues.apache.org/jira/browse/OAK-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589442#comment-14589442
]
Thomas Mueller commented on OAK-3000:
-
For me, the new test "highlightWithWildCard" fails. It says:
{noformat}
org.junit.ComparisonFailure: expected:
<[fox is jumping]>
but was:
<[fox is jumping]>
{noformat}
I'm not sure if the patch is correct. Debugging the code, it will try to
highlight "fox" and then "*". Highlighting "fox" works, but highlighting "*"
would highlight the character "*". But I don't think the wildcard character
should be handled like this. I would expect it to be ignored:
{noformat}
@Test
public void highlightIgnoreStar() throws Exception {
assertEquals("10 * 10",
highlight(sb("10 * 10"), of("fox *")));
}
{noformat}
A bit unexpected (I would call it a bug) is that you can highlight the
intermediate HTML. That way, you can generate a strange, and very long result.
For example, this results in a 300 KB (!) long string:
{noformat}
highlight(sb("abc"), of("a < > o n st ng> ng on ong /")))
{noformat}
> SimpleExcerptProvider causes OOM for some wildcard expressions
> --
>
> Key: OAK-3000
> URL: https://issues.apache.org/jira/browse/OAK-3000
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Chetan Mehrotra
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-3000.patch
>
>
> {{SimpleExcerptProvider}} would cause OOM is the search expression involves
> wildcard in following form
> bq. fox *
> This causes an infinite loop leading to OOM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3003) Improve login performance with huge group membership
angela created OAK-3003:
---
Summary: Improve login performance with huge group membership
Key: OAK-3003
URL: https://issues.apache.org/jira/browse/OAK-3003
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: angela
Assignee: angela
As visible when running {{LoginWithMembershipTest}} default login performance
(which uses the {{o.a.j.oak.security.principal.PrincipalProviderImpl}} to
lookup the complete set of principals) suffers when a given user is member of a
huge number of groups (see also OAK-2690 for benchmark data).
While using dynamic group membership (and thus a custom {{PrincipalProvider}}
would be the preferable way to deal with this, we still want to optimize
{{PrincipalProvider.getPrincipals(String userId}} for the default
implementation.
With the introduction of a less generic implementation in OAK-2690, we might be
able to come up with an optimization that makes use of the very implementation
details of the user management while at the same time being able to properly
secure it as we won't need to extend the public API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2401) SegmentNodeStoreService prone to deadlocks
[
https://issues.apache.org/jira/browse/OAK-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2401:
-
Attachment: OAK-2401-04-testcase-fix.patch
[patch|^OAK-2401-04-testcase-fix.patch] which has a testcase to reproduce the
deadlock and has a potential fix
[~frm] [~amitj_76] [~alex.parvulescu] Can you review the patch?
> SegmentNodeStoreService prone to deadlocks
> --
>
> Key: OAK-2401
> URL: https://issues.apache.org/jira/browse/OAK-2401
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: resilience
> Fix For: 1.3.1, 1.2.3, 1.0.16
>
> Attachments: OAK-2401-01.patch, OAK-2401-02.patch, OAK-2401-03.patch,
> OAK-2401-04-testcase-fix.patch, OAK-2401.patch
>
>
> The SegmentNodeStoreService is prone to deadlocks because of the way in which
> is synchronizes access to the _SegmentNodeStore_ delegate.
> The issue can now be seen on #deactivate, when the deregistration is being
> synchronously broadcast and if a referring service calls #getNodeStore the
> deadlock happens.
> {code}
> Found one Java-level deadlock:
> =
> "qtp844483043-936":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)":
> waiting to lock monitor 0x01d4d0907c88 (object 0x01d2334be930, a
> java.lang.Object),
> which is held by "pool-5-thread-4"
> "pool-5-thread-4":
> waiting to lock monitor 0x01d1aacc7208 (object 0x01d231f52698, a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)"
> Java stack information for the threads listed above:
> ===
> "qtp844483043-936":
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:144)
> - waiting to lock <0x01d231f52698> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:73)
> at
> org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.getRoot(ProxyNodeStore.java:35)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.(MutableRoot.java:160)
> at
> org.apache.jackrabbit.oak.core.ContentSessionImpl.getLatestRoot(ContentSessionImpl.java:110)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getRoot(AbstractLoginModule.java:403)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.getTokenProvider(TokenLoginModule.java:215)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.login(TokenLoginModule.java:128)
> at
> org.apache.felix.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:52)
> at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595)
> at
> org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:161)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:256)
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:92)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:197)
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.login(AbstractSlingRepository2.java:297)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProviderFactory.getResourceProviderInternal(Jcr
[jira] [Commented] (OAK-2829) Comparing node states for external changes is too slow
[ https://issues.apache.org/jira/browse/OAK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589387#comment-14589387 ] Stefan Egli commented on OAK-2829: -- Note: this is now discussed in OAK-3002 > Comparing node states for external changes is too slow > -- > > Key: OAK-2829 > URL: https://issues.apache.org/jira/browse/OAK-2829 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Blocker > Labels: scalability > Fix For: 1.3.1, 1.2.3 > > Attachments: CompareAgainstBaseStateTest.java, OAK-2829-gc-bug.patch, > OAK-2829-improved-doc-cache-invaliation.2.patch, > OAK-2829-improved-doc-cache-invaliation.patch, graph-1.png, graph.png > > > Comparing node states for local changes has been improved already with > OAK-2669. But in a clustered setup generating events for external changes > cannot make use of the introduced cache and is therefore slower. This can > result in a growing observation queue, eventually reaching the configured > limit. See also OAK-2683. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3002) Optimize docCache by filtering using journal
[
https://issues.apache.org/jira/browse/OAK-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-3002:
-
Attachment: OAK-3002-improved-doc-cache-invaliation.2.patch
Attached [^OAK-3002-improved-doc-cache-invaliation.2.patch] (which was
originally added to OAK-2829) as the basis for discussion
> Optimize docCache by filtering using journal
>
>
> Key: OAK-3002
> URL: https://issues.apache.org/jira/browse/OAK-3002
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, mongomk
>Reporter: Stefan Egli
> Labels: scalability
> Fix For: 1.3.1, 1.2.3
>
> Attachments: OAK-3002-improved-doc-cache-invaliation.2.patch
>
>
> This subtask is about spawning out a
> [comment|https://issues.apache.org/jira/browse/OAK-2829?focusedCommentId=14588114&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14588114]
> on OAK-2829 re optimizing docCache invalidation using the newly introduced
> external diff journal:
> {quote}
> Attached OAK-2829-improved-doc-cache-invaliation.patch which is a suggestion
> on how to avoid invalidating the entire document cache when doing a
> {{backgroundRead}} but instead making use of the new journal: ie only
> invalidate from the document cache what has actually changed.
> I'd like to get an opinion ([~mreutegg], [~chetanm]?) on this first, I have a
> load test pending locally which found invalidation of the document cache to
> be the slowest part thus wanted to optimize this first.
> Open still/next:
> * also invalidate only necessary parts from the docChildrenCache
> * junits for all of these
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2829) Comparing node states for external changes is too slow
[ https://issues.apache.org/jira/browse/OAK-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589384#comment-14589384 ] Stefan Egli commented on OAK-2829: -- Created OAK-3002 for this > Comparing node states for external changes is too slow > -- > > Key: OAK-2829 > URL: https://issues.apache.org/jira/browse/OAK-2829 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Blocker > Labels: scalability > Fix For: 1.3.1, 1.2.3 > > Attachments: CompareAgainstBaseStateTest.java, OAK-2829-gc-bug.patch, > OAK-2829-improved-doc-cache-invaliation.2.patch, > OAK-2829-improved-doc-cache-invaliation.patch, graph-1.png, graph.png > > > Comparing node states for local changes has been improved already with > OAK-2669. But in a clustered setup generating events for external changes > cannot make use of the introduced cache and is therefore slower. This can > result in a growing observation queue, eventually reaching the configured > limit. See also OAK-2683. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3002) Optimize docCache by filtering using journal
Stefan Egli created OAK-3002:
Summary: Optimize docCache by filtering using journal
Key: OAK-3002
URL: https://issues.apache.org/jira/browse/OAK-3002
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: core, mongomk
Reporter: Stefan Egli
Fix For: 1.3.1, 1.2.3
This subtask is about spawning out a
[comment|https://issues.apache.org/jira/browse/OAK-2829?focusedCommentId=14588114&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14588114]
on OAK-2829 re optimizing docCache invalidation using the newly introduced
external diff journal:
{quote}
Attached OAK-2829-improved-doc-cache-invaliation.patch which is a suggestion on
how to avoid invalidating the entire document cache when doing a
{{backgroundRead}} but instead making use of the new journal: ie only
invalidate from the document cache what has actually changed.
I'd like to get an opinion ([~mreutegg], [~chetanm]?) on this first, I have a
load test pending locally which found invalidation of the document cache to be
the slowest part thus wanted to optimize this first.
Open still/next:
* also invalidate only necessary parts from the docChildrenCache
* junits for all of these
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
