[jira] [Updated] (OAK-4616) Record suggestor status in suggest-data node
[
https://issues.apache.org/jira/browse/OAK-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-4616:
-
Description:
Currently the suggestor storage logic maintains a timestamp of when suggestor
data was last updated in property {{lastUpdated}} in {{:suggesterStatus}} node.
Actual suggest data is stored in a separate node {{:suggest-data}}.
{noformat}
/oak:index/lucene-suggest: { reindexCount = 1, name = lucene-suggest,
compatVersion = 2, reindex = false, type = lucene, jcr:primaryType =
oak:QueryIndexDefinition, :facet-config = { ... }, indexRules = { ... }, :data
= { ... }, :status = { ... }, :suggest-data = { ... }, :suggesterStatus = { ...
}}
{noformat}
It would be better if this property is stored in {{:suggest-data}}. This would
simplify adding support for multiplexing as each dir node would be having
complete info
{noformat}
+ :oak:mount-foo-suggest-data
- lastUpdated
+ :suggest-data
- lastUpdated
{noformat}
was:
Currently the suggestor storage logic maintains a timestamp of when suggestor
data was last updated in property {{lastUpdated}} in {{:suggesterStatus}} node.
Actual suggest data is stored in a separate node {{:suggest-data}}.
{noformat}
/oak:index/lucene-suggest: { reindexCount = 1, name = lucene-suggest,
compatVersion = 2, reindex = false, type = lucene, jcr:primaryType =
oak:QueryIndexDefinition, :facet-config = { ... }, indexRules = { ... }, :data
= { ... }, :status = { ... }, :suggest-data = { ... }, :suggesterStatus = { ...
}}
{noformat}
It would be better if this property is stored in {{:suggest-data}}. This would
simplify adding support for multiplexing as each dir node would be having
complete info
{noformat}
+ :oak:mount-foo-suggest-data
- lastUpdated
:suggest-data
- lastUpdated
{noformat}
> Record suggestor status in suggest-data node
> -
>
> Key: OAK-4616
> URL: https://issues.apache.org/jira/browse/OAK-4616
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6
>
>
> Currently the suggestor storage logic maintains a timestamp of when suggestor
> data was last updated in property {{lastUpdated}} in {{:suggesterStatus}}
> node. Actual suggest data is stored in a separate node {{:suggest-data}}.
> {noformat}
> /oak:index/lucene-suggest: { reindexCount = 1, name = lucene-suggest,
> compatVersion = 2, reindex = false, type = lucene, jcr:primaryType =
> oak:QueryIndexDefinition, :facet-config = { ... }, indexRules = { ... },
> :data = { ... }, :status = { ... }, :suggest-data = { ... }, :suggesterStatus
> = { ... }}
> {noformat}
> It would be better if this property is stored in {{:suggest-data}}. This
> would simplify adding support for multiplexing as each dir node would be
> having complete info
> {noformat}
> + :oak:mount-foo-suggest-data
>- lastUpdated
> + :suggest-data
>- lastUpdated
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4616) Record suggestor status in suggest-data node
Chetan Mehrotra created OAK-4616:
Summary: Record suggestor status in suggest-data node
Key: OAK-4616
URL: https://issues.apache.org/jira/browse/OAK-4616
Project: Jackrabbit Oak
Issue Type: Improvement
Components: lucene
Reporter: Chetan Mehrotra
Priority: Minor
Fix For: 1.6
Currently the suggestor storage logic maintains a timestamp of when suggestor
data was last updated in property {{lastUpdated}} in {{:suggesterStatus}} node.
Actual suggest data is stored in a separate node {{:suggest-data}}.
{noformat}
/oak:index/lucene-suggest: { reindexCount = 1, name = lucene-suggest,
compatVersion = 2, reindex = false, type = lucene, jcr:primaryType =
oak:QueryIndexDefinition, :facet-config = { ... }, indexRules = { ... }, :data
= { ... }, :status = { ... }, :suggest-data = { ... }, :suggesterStatus = { ...
}}
{noformat}
It would be better if this property is stored in {{:suggest-data}}. This would
simplify adding support for multiplexing as each dir node would be having
complete info
{noformat}
+ :oak:mount-foo-suggest-data
- lastUpdated
:suggest-data
- lastUpdated
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4615) RDBDocumentStore: in 1.0, cache invalidation is slightly different from 1.2
[
https://issues.apache.org/jira/browse/OAK-4615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-4615:
Attachment: OAK-4615.diff
Proposed fix.
> RDBDocumentStore: in 1.0, cache invalidation is slightly different from 1.2
> ---
>
> Key: OAK-4615
> URL: https://issues.apache.org/jira/browse/OAK-4615
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Affects Versions: 1.0.32
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Attachments: OAK-4615.diff
>
>
> The difference is:
> {noformat}
> ***
> *** 1128,1140
> String appendData = ser.asString(update);
> for (List chunkedIds : Lists.partition(ids, CHUNKSIZE))
> {
> Set seenQueryContext = Collections.emptySet();
> if (collection == Collection.NODES) {
> - for (String id : chunkedIds) {
> - nodesCache.invalidate(id);
> - }
> -
> // keep concurrently running queries from updating
> // the cache entry for this key
> seenQueryContext = new HashSet();
> --- 1128,1137
> String appendData = ser.asString(update);
> for (List chunkedIds : Lists.partition(ids, CHUNKSIZE))
> {
> +
> Set seenQueryContext = Collections.emptySet();
> if (collection == Collection.NODES) {
> // keep concurrently running queries from updating
> // the cache entry for this key
> seenQueryContext = new HashSet();
> ***
> *** 1142,1147
> --- 1139,1147
> qc.addKeys(chunkedIds);
> seenQueryContext.add(qc);
> }
> + for (String id : chunkedIds) {
> + nodesCache.invalidate(id);
> + }
> }
> {noformat}
> and seems to be caused by the change for OAK-3657.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4615) RDBDocumentStore: in 1.0, cache invalidation is slightly different from 1.2
[
https://issues.apache.org/jira/browse/OAK-4615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-4615:
Issue Type: Technical task (was: Task)
Parent: OAK-1266
> RDBDocumentStore: in 1.0, cache invalidation is slightly different from 1.2
> ---
>
> Key: OAK-4615
> URL: https://issues.apache.org/jira/browse/OAK-4615
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Affects Versions: 1.0.32
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>
> The difference is:
> {noformat}
> ***
> *** 1128,1140
> String appendData = ser.asString(update);
> for (List chunkedIds : Lists.partition(ids, CHUNKSIZE))
> {
> Set seenQueryContext = Collections.emptySet();
> if (collection == Collection.NODES) {
> - for (String id : chunkedIds) {
> - nodesCache.invalidate(id);
> - }
> -
> // keep concurrently running queries from updating
> // the cache entry for this key
> seenQueryContext = new HashSet();
> --- 1128,1137
> String appendData = ser.asString(update);
> for (List chunkedIds : Lists.partition(ids, CHUNKSIZE))
> {
> +
> Set seenQueryContext = Collections.emptySet();
> if (collection == Collection.NODES) {
> // keep concurrently running queries from updating
> // the cache entry for this key
> seenQueryContext = new HashSet();
> ***
> *** 1142,1147
> --- 1139,1147
> qc.addKeys(chunkedIds);
> seenQueryContext.add(qc);
> }
> + for (String id : chunkedIds) {
> + nodesCache.invalidate(id);
> + }
> }
> {noformat}
> and seems to be caused by the change for OAK-3657.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4615) RDBDocumentStore: in 1.0, cache invalidation is slightly different from 1.2
Julian Reschke created OAK-4615:
---
Summary: RDBDocumentStore: in 1.0, cache invalidation is slightly
different from 1.2
Key: OAK-4615
URL: https://issues.apache.org/jira/browse/OAK-4615
Project: Jackrabbit Oak
Issue Type: Task
Components: rdbmk
Affects Versions: 1.0.32
Reporter: Julian Reschke
Assignee: Julian Reschke
The difference is:
{noformat}
***
*** 1128,1140
String appendData = ser.asString(update);
for (List chunkedIds : Lists.partition(ids, CHUNKSIZE)) {
Set seenQueryContext = Collections.emptySet();
if (collection == Collection.NODES) {
- for (String id : chunkedIds) {
- nodesCache.invalidate(id);
- }
-
// keep concurrently running queries from updating
// the cache entry for this key
seenQueryContext = new HashSet();
--- 1128,1137
String appendData = ser.asString(update);
for (List chunkedIds : Lists.partition(ids, CHUNKSIZE)) {
+
Set seenQueryContext = Collections.emptySet();
if (collection == Collection.NODES) {
// keep concurrently running queries from updating
// the cache entry for this key
seenQueryContext = new HashSet();
***
*** 1142,1147
--- 1139,1147
qc.addKeys(chunkedIds);
seenQueryContext.add(qc);
}
+ for (String id : chunkedIds) {
+ nodesCache.invalidate(id);
+ }
}
{noformat}
and seems to be caused by the change for OAK-3657.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-4522: -- Labels: observation (was: ) Component/s: jcr > Improve CommitRateLimiter to optionally block some commits > -- > > Key: OAK-4522 > URL: https://issues.apache.org/jira/browse/OAK-4522 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: observation > Fix For: 1.6 > > > The CommitRateLimiter of OAK-1659 can delay commits, but doesn't currently > block them, and delays even those commits that are part of handling events. > Because of that, the queue can still get full, and possibly delaying commits > while handling events can make the situation even worse. > In Jackrabbit 2.x, we had a similar feature: JCR-2402. Also related is > JCR-2746. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4581) Persistent local journal for more reliable event generation
[
https://issues.apache.org/jira/browse/OAK-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-4581:
--
Labels: observation (was: )
> Persistent local journal for more reliable event generation
> ---
>
> Key: OAK-4581
> URL: https://issues.apache.org/jira/browse/OAK-4581
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Chetan Mehrotra
> Labels: observation
> Fix For: 1.6
>
>
> As discussed in OAK-2683 "hitting the observation queue limit" has multiple
> drawbacks. Quite a bit of work is done to make diff generation faster.
> However there are still chances of event queue getting filled up.
> This issue is meant to implement a persistent event journal. Idea here being
> # NodeStore would push the diff into a persistent store via a synchronous
> observer
> # Observors which are meant to handle such events in async way (by virtue of
> being wrapped in BackgroundObserver) would instead pull the events from this
> persisted journal
> h3. A - What is persisted
> h4. 1 - Serialized Root States and CommitInfo
> In this approach we just persist the root states in serialized form.
> * DocumentNodeStore - This means storing the root revision vector
> * SegmentNodeStore - {color:red}Q1 - What does serialized form of
> SegmentNodeStore root state looks like{color} - Possible the RecordId of
> "root" state
> Note that with OAK-4528 DocumentNodeStore can rely on persisted remote
> journal to determine the affected paths. Which reduces the need for
> persisting complete diff locally.
> Event generation logic would then "deserialize" the persisted root states and
> then generate the diff as currently done via NodeState comparison
> h4. 2 - Serialized commit diff and CommitInfo
> In this approach we can save the diff in JSOP form. The diff only contains
> information about affected path. Similar to what is current being stored in
> DocumentNodeStore journal
> h4. CommitInfo
> The commit info would also need to be serialized. So it needs to be ensure
> whatever is stored there can be serialized or re calculated
> h3. B - How it is persisted
> h4. 1 - Use a secondary segment NodeStore
> OAK-4180 makes use of SegmentNodeStore as a secondary store for caching.
> [~mreutegg] suggested that for persisted local journal we can also utilize a
> SegmentNodeStore instance. Care needs to be taken for compaction. Either via
> generation approach or relying on online compaction
> h4. 2- Make use of write ahead log implementations
> [~ianeboston] suggested that we can make use of some write ahead log
> implementation like [1], [2] or [3]
> h3. C - How changes get pulled
> Some points to consider for event generation logic
> # Would need a way to keep pointers to journal entry on per listener basis.
> This would allow each Listener to "pull" content changes and generate diff as
> per its speed and keeping in memory overhead low
> # The journal should survive restarts
> [1] http://www.mapdb.org/javadoc/latest/mapdb/org/mapdb/WriteAheadLog.html
> [2]
> https://github.com/apache/activemq/tree/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/journal
> [3]
> https://github.com/elastic/elasticsearch/tree/master/core/src/main/java/org/elasticsearch/index/translog
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4614) Collection of observation resilience issues
Marcel Reutegger created OAK-4614: - Summary: Collection of observation resilience issues Key: OAK-4614 URL: https://issues.apache.org/jira/browse/OAK-4614 Project: Jackrabbit Oak Issue Type: Epic Components: core, documentmk, jcr Reporter: Marcel Reutegger Fix For: 1.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4522: Fix Version/s: 1.6 > Improve CommitRateLimiter to optionally block some commits > -- > > Key: OAK-4522 > URL: https://issues.apache.org/jira/browse/OAK-4522 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.6 > > > The CommitRateLimiter of OAK-1659 can delay commits, but doesn't currently > block them, and delays even those commits that are part of handling events. > Because of that, the queue can still get full, and possibly delaying commits > while handling events can make the situation even worse. > In Jackrabbit 2.x, we had a similar feature: JCR-2402. Also related is > JCR-2746. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15397550#comment-15397550 ] Thomas Mueller commented on OAK-4522: - The CommitRateLimiter currently only gets informed about added entries (when the queue grows), but not about removed entries (when the queue shrinks). That means once the commit rate limiter blocks commits, in the (unusual but possible) case that no new entries are added to the queue, it would never un-block. Support for removing events on removing entries is available in the second patch of OAK-4543. > Improve CommitRateLimiter to optionally block some commits > -- > > Key: OAK-4522 > URL: https://issues.apache.org/jira/browse/OAK-4522 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Thomas Mueller >Assignee: Thomas Mueller > > The CommitRateLimiter of OAK-1659 can delay commits, but doesn't currently > block them, and delays even those commits that are part of handling events. > Because of that, the queue can still get full, and possibly delaying commits > while handling events can make the situation even worse. > In Jackrabbit 2.x, we had a similar feature: JCR-2402. Also related is > JCR-2746. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4543) Add info about event generation and consumption by observer
[ https://issues.apache.org/jira/browse/OAK-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-4543: -- Attachment: OAK-4543.patch Updated patch with changes from OAK-4610. > Add info about event generation and consumption by observer > --- > > Key: OAK-4543 > URL: https://issues.apache.org/jira/browse/OAK-4543 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, jcr >Reporter: Vikas Saurabh >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, > monitoring, observation, performance > Fix For: 1.6 > > Attachments: OAK-4543.patch, OAK-4543.patch > > > I'm not sure if it's possible in the current scheme of things > (implementation), but it'd useful to be able to easily differentiate between > slow diff calculation or slow observer as a reason to see why observation > queue might fill up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3072) LuceneIndexEditorTest#copyOnWriteAndLocks failing on windows
[
https://issues.apache.org/jira/browse/OAK-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-3072.
--
Resolution: Fixed
Fix Version/s: 1.5.7
Re-enabled the test and modified it to not run on windows setup
> LuceneIndexEditorTest#copyOnWriteAndLocks failing on windows
>
>
> Key: OAK-3072
> URL: https://issues.apache.org/jira/browse/OAK-3072
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.3.1
> Environment: windows
>Reporter: Amit Jain
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6, 1.5.7
>
>
> LuceneIndexEditorTest#copyOnWriteAndLocks regularly fails on windows with the
> following exception
> {noformat}
> copyOnWriteAndLocks(org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest)
> Time elapsed: 0.19 sec <<< ERROR!
> org.apache.jackrabbit.oak.api.CommitFailedException: OakLucene0003: Failed to
> index the node /test
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.addOrUpdate(LuceneIndexEditor.java:297)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.leave(LuceneIndexEditor.java:191)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.leave(CompositeEditor.java:74)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.leave(VisibleEditor.java:63)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:130)
> at
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.copyOnWriteAndLocks(LuceneIndexEditorTest.java:376)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
> at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
>
[jira] [Resolved] (OAK-4613) Suggest directory should be opened in read only mode
[
https://issues.apache.org/jira/browse/OAK-4613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-4613.
--
Resolution: Fixed
Fix Version/s: 1.5.7
Done in 1754393
> Suggest directory should be opened in read only mode
>
>
> Key: OAK-4613
> URL: https://issues.apache.org/jira/browse/OAK-4613
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6, 1.5.7
>
>
> {{IndexNode}} currently opens the suggest directory in following way
> {code}
> if (definition.isSuggestEnabled()) {
> suggestDirectory = new OakDirectory(defnNodeState.builder(),
> ":suggest-data", definition, false);
> }
> {code}
> It has two issues
> * It open a builder on existing node state. Instead of that it should use
> {{ReadOnlyBuilder}}
> * The directory should be opened in read only mode
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4613) Suggest directory should be opened in read only mode
Chetan Mehrotra created OAK-4613:
Summary: Suggest directory should be opened in read only mode
Key: OAK-4613
URL: https://issues.apache.org/jira/browse/OAK-4613
Project: Jackrabbit Oak
Issue Type: Improvement
Components: lucene
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
Fix For: 1.6
{{IndexNode}} currently opens the suggest directory in following way
{code}
if (definition.isSuggestEnabled()) {
suggestDirectory = new OakDirectory(defnNodeState.builder(),
":suggest-data", definition, false);
}
{code}
It has two issues
* It open a builder on existing node state. Instead of that it should use
{{ReadOnlyBuilder}}
* The directory should be opened in read only mode
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3072) LuceneIndexEditorTest#copyOnWriteAndLocks failing on windows
[
https://issues.apache.org/jira/browse/OAK-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3072:
-
Fix Version/s: 1.6
> LuceneIndexEditorTest#copyOnWriteAndLocks failing on windows
>
>
> Key: OAK-3072
> URL: https://issues.apache.org/jira/browse/OAK-3072
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.3.1
> Environment: windows
>Reporter: Amit Jain
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6
>
>
> LuceneIndexEditorTest#copyOnWriteAndLocks regularly fails on windows with the
> following exception
> {noformat}
> copyOnWriteAndLocks(org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest)
> Time elapsed: 0.19 sec <<< ERROR!
> org.apache.jackrabbit.oak.api.CommitFailedException: OakLucene0003: Failed to
> index the node /test
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.addOrUpdate(LuceneIndexEditor.java:297)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.leave(LuceneIndexEditor.java:191)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.leave(CompositeEditor.java:74)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.leave(VisibleEditor.java:63)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:130)
> at
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.copyOnWriteAndLocks(LuceneIndexEditorTest.java:376)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
> at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.io.IOException: Cannot overwrite:
>
[jira] [Commented] (OAK-4543) Add info about event generation and consumption by observer
[ https://issues.apache.org/jira/browse/OAK-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15397290#comment-15397290 ] Marcel Reutegger commented on OAK-4543: --- I resolved OAK-4610 as duplicate of this issue and will include the changes from the OAK-4610 in this issue as well. > Add info about event generation and consumption by observer > --- > > Key: OAK-4543 > URL: https://issues.apache.org/jira/browse/OAK-4543 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, jcr >Reporter: Vikas Saurabh >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, > monitoring, observation, performance > Fix For: 1.6 > > Attachments: OAK-4543.patch > > > I'm not sure if it's possible in the current scheme of things > (implementation), but it'd useful to be able to easily differentiate between > slow diff calculation or slow observer as a reason to see why observation > queue might fill up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4543) Add info about event generation and consumption by observer
[ https://issues.apache.org/jira/browse/OAK-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-4543: -- Component/s: jcr core > Add info about event generation and consumption by observer > --- > > Key: OAK-4543 > URL: https://issues.apache.org/jira/browse/OAK-4543 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, jcr >Reporter: Vikas Saurabh >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, > monitoring, observation, performance > Fix For: 1.6 > > Attachments: OAK-4543.patch > > > I'm not sure if it's possible in the current scheme of things > (implementation), but it'd useful to be able to easily differentiate between > slow diff calculation or slow observer as a reason to see why observation > queue might fill up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4610) Report age of oldest queue entry in EventListenerMBean and ConsolidatedListenerMBean
[ https://issues.apache.org/jira/browse/OAK-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-4610. --- Resolution: Duplicate Fix Version/s: (was: 1.6) I decided to resolve this issue as a duplicate of OAK-4543 and include changes proposed in this issue in OAK-4543. > Report age of oldest queue entry in EventListenerMBean and > ConsolidatedListenerMBean > > > Key: OAK-4610 > URL: https://issues.apache.org/jira/browse/OAK-4610 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, jcr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: observation > Attachments: OAK-4610.patch > > > This is related to JCR-4000 and the remaining work in Oak that hooks into the > ListenerTracker and exposes the info also in the consolidated listener MBean. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4543) Add info about event generation and consumption by observer
[ https://issues.apache.org/jira/browse/OAK-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15397255#comment-15397255 ] Vikas Saurabh commented on OAK-4543: Yeah, sorry... should've been clearer... so, queue length growing with inefficient/efficient filter can be due to really fast incoming commits OR event generation being slow. Low ratio with inefficient filter is probably same as a listener which quits early per path but asks for whole diff anyway - queue length growth in such cases would mean that event generation isn't able to keep up with incoming commits. Optimizing filter or optimizing event generation as potential resolutions is probably orthogonal to the monitoring task. > Add info about event generation and consumption by observer > --- > > Key: OAK-4543 > URL: https://issues.apache.org/jira/browse/OAK-4543 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Vikas Saurabh >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, > monitoring, observation, performance > Fix For: 1.6 > > Attachments: OAK-4543.patch > > > I'm not sure if it's possible in the current scheme of things > (implementation), but it'd useful to be able to easily differentiate between > slow diff calculation or slow observer as a reason to see why observation > queue might fill up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4543) Add info about event generation and consumption by observer
[ https://issues.apache.org/jira/browse/OAK-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15397210#comment-15397210 ] Marcel Reutegger commented on OAK-4543: --- bq. queue length is increasing with listener with relatively low ratio Please note, this doesn't necessarily mean somethings is wrong. It may also mean the filter set by the listener is 'inefficient'. E.g. listening for any event on a given node type is currently not optimized, while a path filter is. > Add info about event generation and consumption by observer > --- > > Key: OAK-4543 > URL: https://issues.apache.org/jira/browse/OAK-4543 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Vikas Saurabh >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, > monitoring, observation, performance > Fix For: 1.6 > > Attachments: OAK-4543.patch > > > I'm not sure if it's possible in the current scheme of things > (implementation), but it'd useful to be able to easily differentiate between > slow diff calculation or slow observer as a reason to see why observation > queue might fill up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
