[jira] [Commented] (OAK-4935) support prefiltering of async index updates
[
https://issues.apache.org/jira/browse/OAK-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15666441#comment-15666441
]
Chetan Mehrotra commented on OAK-4935:
--
Done changes in series of commits 1769747,1769748,1769749, 1769750,1769752
* [1769748|http://svn.apache.org/viewvc?rev=1769748=rev] and
[1769749|http://svn.apache.org/viewvc?rev=1769749=rev] Affect
{{AsyncIndexUpdate}} - [~alexparvulescu] if you can have a quick look at the
commit done it would be helpful!
[~egli] I added some logging in {{ChangeCollectorProvider}} with
[1769750|http://svn.apache.org/viewvc?rev=1769750=rev]
> support prefiltering of async index updates
> ---
>
> Key: OAK-4935
> URL: https://issues.apache.org/jira/browse/OAK-4935
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> As pointed out
> [here|https://issues.apache.org/jira/browse/OAK-4924?focusedCommentId=15568308=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15568308]
> at the moment the AsyncIndexUpdate, via SegmentNodeStore.refreshHead passes
> null in the contentChanged call. This prevents prefiltering from being
> applied.
> [~chetanm] suggested to explicitly run the ChangeCollector ValidationProvider
> in the AsyncIndexUpdate.mergeWithConcurrencyCheck (see [comment
> here|https://issues.apache.org/jira/browse/OAK-4924?focusedCommentId=15568339=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15568339]).
> Alternatively the AsyncIndexUpdate.mergeWithConcurrencyCheck could provide an
> explicit ChangeSet representing empty sets for all (paths, names, types,
> properties), as really an index update shouldn't generate anything of
> interest for any jcr listener. Not sure if this is always 100% the case but
> it sounds like a bit of a waste of CPU to collect hidden paths (of the
> indices) in a ChangeSet which then anyway shouldn't be applicable to any
> listener. But yes, it would be somewhat of a violation of the general
> contract to have the ChangeSet represent all changes. Then again, we could
> argue that hidden paths aren't included.
> [~chetanm], wdyt?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-5106.
-
Resolution: Fixed
Fix Version/s: 1.6
Very good catches! Committed at r1769753.
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.6, 1.5.14
>
> Attachments: OAK-5106.patch
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4935) support prefiltering of async index updates
[
https://issues.apache.org/jira/browse/OAK-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15666420#comment-15666420
]
Chetan Mehrotra commented on OAK-4935:
--
After doing the changes the number of {{prefilterSkips}} have gone down to 3
from 7 for each async index cycle i.e. for 3 contentChange events received pre
filtering cannot be performed. Digging further lead to root cause close to
OAK-4924. For example in SegmentNodeStore when a new checkpoint gets created it
performs a {{refreshHead}} which leads to Change dispatched with null
commitInfo in {{CPCreator}}
{code}
NodeBuilder props = cp.setChildNode("properties");
for (Entry p : properties.entrySet()) {
props.setProperty(p.getKey(), p.getValue());
}
cp.setChildNode(ROOT, state.getChildNode(ROOT));
SegmentNodeState newState = builder.getNodeState();
if (revisions.setHead(state.getRecordId(), newState.getRecordId()))
{
refreshHead();
return true;
}
{code}
[~mduerig] [~alex.parvulescu] Any thoughts if this aspect can be optimized wrt
pre filtering i.e. only for refreshHead call when checkpoint is being created
as its known that no other change has happened in between.
For DocumentNodeStore this is not an issue as no event is dispatched
/cc [~egli] [~mreutegg]
> support prefiltering of async index updates
> ---
>
> Key: OAK-4935
> URL: https://issues.apache.org/jira/browse/OAK-4935
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> As pointed out
> [here|https://issues.apache.org/jira/browse/OAK-4924?focusedCommentId=15568308=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15568308]
> at the moment the AsyncIndexUpdate, via SegmentNodeStore.refreshHead passes
> null in the contentChanged call. This prevents prefiltering from being
> applied.
> [~chetanm] suggested to explicitly run the ChangeCollector ValidationProvider
> in the AsyncIndexUpdate.mergeWithConcurrencyCheck (see [comment
> here|https://issues.apache.org/jira/browse/OAK-4924?focusedCommentId=15568339=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15568339]).
> Alternatively the AsyncIndexUpdate.mergeWithConcurrencyCheck could provide an
> explicit ChangeSet representing empty sets for all (paths, names, types,
> properties), as really an index update shouldn't generate anything of
> interest for any jcr listener. Not sure if this is always 100% the case but
> it sounds like a bit of a waste of CPU to collect hidden paths (of the
> indices) in a ChangeSet which then anyway shouldn't be applicable to any
> listener. But yes, it would be somewhat of a violation of the general
> contract to have the ChangeSet represent all changes. Then again, we could
> argue that hidden paths aren't included.
> [~chetanm], wdyt?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari reassigned OAK-5106:
---
Assignee: Francesco Mari (was: Timothee Maret)
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.5.14
>
> Attachments: OAK-5106.patch
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5091) Support bundled documents in oak-mongo.js
[
https://issues.apache.org/jira/browse/OAK-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15666345#comment-15666345
]
Marcel Reutegger commented on OAK-5091:
---
That would be a low level DocumentStore console, right? Sounds very useful to
me.
> Support bundled documents in oak-mongo.js
> -
>
> Key: OAK-5091
> URL: https://issues.apache.org/jira/browse/OAK-5091
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk
>Affects Versions: 1.5.13
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.8
>
>
> With document bundling (OAK-1312) repository can have holes in document
> hierarchy (this
> [comment|https://issues.apache.org/jira/browse/OAK-1312?focusedCommentId=15434914=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15434914])
> {quote}
> Just a quick note: with the implementation, we can have potential holes in
> documents - say we have {{/a, /a/b and /a/b/c}} and {{/a/b}} is bundled with
> {{/a}}. Then we'd only have documents - {{0:/, 1:/a, 3:/a/b/c}}.
> While that, of course, is ok, but we would need to factor this at least in
> oak-mongo.js (I can't recall any place else right now) which loops
> recursively at quite a few places with breaking the loop if no docs are found
> at a given depth.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5108) [Blob GC] checkConsistency() should sync available blobs from the datastore
Amit Jain created OAK-5108:
--
Summary: [Blob GC] checkConsistency() should sync available blobs
from the datastore
Key: OAK-5108
URL: https://issues.apache.org/jira/browse/OAK-5108
Project: Jackrabbit Oak
Issue Type: Bug
Components: blob
Reporter: Amit Jain
Assignee: Amit Jain
Fix For: 1.5.14
With OAK-4200, the blob ids are cached locally and a periodic snapshot job then
consolidates all the newly written blob ids to a file which is used to report
the blob ids available.
With {{checkConsistency}} because of this lag, missing blobs might be
incorrectly reported and the {{checkConsistency}} method should directly report
the blobs from the datastore.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15665324#comment-15665324
]
Michael Dürig commented on OAK-5106:
Thanks [~marett], this fixes the failing build on my end. I cannot comment on
the particulars of the patch, leaving this to [~frm].
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5106.patch
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664884#comment-15664884
]
Timothee Maret edited comment on OAK-5106 at 11/14/16 8:52 PM:
---
Attach a svn patch that
* Reuse the NioEventLoopGroup in the standby client
* Fix a file handler leak in tests (the server NioEventLoopGroup was not
released)
was (Author: marett):
Attach a svn patch that
* Reuse the NioEventLoopGroup in the standby client
* Fix a memory leak in tests (the server NioEventLoopGroup was not released)
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5106.patch
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664894#comment-15664894
]
Timothee Maret commented on OAK-5106:
-
IT tests used to run with ~4'000 files opened at the same time. With the patch,
it is reduced to < 500.
[~frm], [~mduerig] could you have a look at the patch ?
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5106.patch
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5106:
Attachment: OAK-5106.patch
Attach a svn patch that
* Reuse the NioEventLoopGroup in the standby client
* Fix a memory leak in tests (the server NioEventLoopGroup was not released)
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5106.patch
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned OAK-5106:
---
Assignee: Timothee Maret
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5106:
Flags: Patch
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
> Fix For: 1.5.14
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4619) Unify RecordCacheStats and CacheStats
[
https://issues.apache.org/jira/browse/OAK-4619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4619:
---
Issue Type: Improvement (was: Task)
> Unify RecordCacheStats and CacheStats
> -
>
> Key: OAK-4619
> URL: https://issues.apache.org/jira/browse/OAK-4619
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Minor
> Labels: technical_debt
> Fix For: 1.5.14
>
>
> There is {{org.apache.jackrabbit.oak.cache.CacheStats}} in {{oak-core}} and
> {{org.apache.jackrabbit.oak.segment.RecordCacheStats}} in
> {{oak-segment-tar}}. Both exposing quite similar functionality. We should try
> to unify them as much as possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-5036) switch o.a.j.oak.jcr.observation.filter version to 1.0.0 before oak 1.6 release
[ https://issues.apache.org/jira/browse/OAK-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli resolved OAK-5036. -- Resolution: Fixed set to 1.0.0 in http://svn.apache.org/viewvc?rev=1769683=rev > switch o.a.j.oak.jcr.observation.filter version to 1.0.0 before oak 1.6 > release > --- > > Key: OAK-5036 > URL: https://issues.apache.org/jira/browse/OAK-5036 > Project: Jackrabbit Oak > Issue Type: Task > Components: jcr >Reporter: Stefan Egli >Assignee: Stefan Egli >Priority: Blocker > Fix For: 1.6, 1.5.14 > > > OAK-5013 introduces an extension mechanism to expose Oak specific observation > filtering features. > Currently the corresponding package is set to version 0.0.0 with the idea to > not dirty the version range unnecessarily before oak 1.6. But before > releasing oak 1.6 this should be set to 1.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-5107) Avoid NullPointerException in ChangeSetFilterImpl
[
https://issues.apache.org/jira/browse/OAK-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved OAK-5107.
--
Resolution: Fixed
Fix Version/s: 1.6
caught in http://svn.apache.org/viewvc?rev=1769682=rev
> Avoid NullPointerException in ChangeSetFilterImpl
> -
>
> Key: OAK-5107
> URL: https://issues.apache.org/jira/browse/OAK-5107
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.13
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6, 1.5.14
>
>
> The following exception was seen:
> {noformat}java.lang.NullPointerException: null
> at java.util.HashSet.(HashSet.java:116)
> at
> org.apache.jackrabbit.oak.plugins.observation.filter.ChangeSetFilterImpl.excludes(ChangeSetFilterImpl.java:90)
> at
> org.apache.jackrabbit.oak.plugins.observation.filter.FilterBuilder$2.excludes(FilterBuilder.java:438)
> at
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.evalPrefilter(ChangeProcessor.java:699)
> at
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.access$900(ChangeProcessor.java:84)
> at
> org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor$6.excludes(ChangeProcessor.java:386)
> at
> org.apache.jackrabbit.oak.plugins.observation.FilteringObserver.contentChanged(FilteringObserver.java:95)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeObserver.contentChanged(CompositeObserver.java:53)
> at
> org.apache.jackrabbit.oak.spi.commit.ChangeDispatcher.contentChanged(ChangeDispatcher.java:79)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeStore.contentChanged(SegmentNodeStore.java:655)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeStore.access$1000(SegmentNodeStore.java:73)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeStore$Commit.setHead(SegmentNodeStore.java:536)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeStore$Commit.optimisticMerge(SegmentNodeStore.java:581)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeStore$Commit.execute(SegmentNodeStore.java:635)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeStore.merge(SegmentNodeStore.java:289)
> at
> org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.merge(ProxyNodeStore.java:43)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:249)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.commit(SessionDelegate.java:347)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:494)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5107) Avoid NullPointerException in ChangeSetFilterImpl
Stefan Egli created OAK-5107:
Summary: Avoid NullPointerException in ChangeSetFilterImpl
Key: OAK-5107
URL: https://issues.apache.org/jira/browse/OAK-5107
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 1.5.13
Reporter: Stefan Egli
Assignee: Stefan Egli
Fix For: 1.5.14
The following exception was seen:
{noformat}java.lang.NullPointerException: null
at java.util.HashSet.(HashSet.java:116)
at
org.apache.jackrabbit.oak.plugins.observation.filter.ChangeSetFilterImpl.excludes(ChangeSetFilterImpl.java:90)
at
org.apache.jackrabbit.oak.plugins.observation.filter.FilterBuilder$2.excludes(FilterBuilder.java:438)
at
org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.evalPrefilter(ChangeProcessor.java:699)
at
org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.access$900(ChangeProcessor.java:84)
at
org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor$6.excludes(ChangeProcessor.java:386)
at
org.apache.jackrabbit.oak.plugins.observation.FilteringObserver.contentChanged(FilteringObserver.java:95)
at
org.apache.jackrabbit.oak.spi.commit.CompositeObserver.contentChanged(CompositeObserver.java:53)
at
org.apache.jackrabbit.oak.spi.commit.ChangeDispatcher.contentChanged(ChangeDispatcher.java:79)
at
org.apache.jackrabbit.oak.segment.SegmentNodeStore.contentChanged(SegmentNodeStore.java:655)
at
org.apache.jackrabbit.oak.segment.SegmentNodeStore.access$1000(SegmentNodeStore.java:73)
at
org.apache.jackrabbit.oak.segment.SegmentNodeStore$Commit.setHead(SegmentNodeStore.java:536)
at
org.apache.jackrabbit.oak.segment.SegmentNodeStore$Commit.optimisticMerge(SegmentNodeStore.java:581)
at
org.apache.jackrabbit.oak.segment.SegmentNodeStore$Commit.execute(SegmentNodeStore.java:635)
at
org.apache.jackrabbit.oak.segment.SegmentNodeStore.merge(SegmentNodeStore.java:289)
at
org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.merge(ProxyNodeStore.java:43)
at
org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:249)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.commit(SessionDelegate.java:347)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:494)
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5091) Support bundled documents in oak-mongo.js
[
https://issues.apache.org/jira/browse/OAK-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664777#comment-15664777
]
Vikas Saurabh commented on OAK-5091:
Should we bump it to Major then? Btw, the out-of-band-from-release-pov argument
is still valid imo.
> Support bundled documents in oak-mongo.js
> -
>
> Key: OAK-5091
> URL: https://issues.apache.org/jira/browse/OAK-5091
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk
>Affects Versions: 1.5.13
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.8
>
>
> With document bundling (OAK-1312) repository can have holes in document
> hierarchy (this
> [comment|https://issues.apache.org/jira/browse/OAK-1312?focusedCommentId=15434914=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15434914])
> {quote}
> Just a quick note: with the implementation, we can have potential holes in
> documents - say we have {{/a, /a/b and /a/b/c}} and {{/a/b}} is bundled with
> {{/a}}. Then we'd only have documents - {{0:/, 1:/a, 3:/a/b/c}}.
> While that, of course, is ok, but we would need to factor this at least in
> oak-mongo.js (I can't recall any place else right now) which loops
> recursively at quite a few places with breaking the loop if no docs are found
> at a given depth.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5091) Support bundled documents in oak-mongo.js
[
https://issues.apache.org/jira/browse/OAK-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664772#comment-15664772
]
Vikas Saurabh commented on OAK-5091:
I was thinking about this a bit and parsing bundling information, which afair
is rev-versioned data, seems getting too much to do in javascript. May be, as
an orthogonal approach, we do a parallel oak-run-console-command which uses
oak's classes as far as possible and goes down to impl specific class to do
some stuff optimally (break usual DocumentNodeStore abstraction and talk to
mongo or rdb directly - of course through helper classes). If that sounds
reasonable, we can then deprecate oak-mongo.js.
As an added (minor??) advantage we get RDB maintenance at par with that of
mongo.
[~mreutegg], [~chetanm], [~reschke], thoughts??
> Support bundled documents in oak-mongo.js
> -
>
> Key: OAK-5091
> URL: https://issues.apache.org/jira/browse/OAK-5091
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk
>Affects Versions: 1.5.13
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.8
>
>
> With document bundling (OAK-1312) repository can have holes in document
> hierarchy (this
> [comment|https://issues.apache.org/jira/browse/OAK-1312?focusedCommentId=15434914=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15434914])
> {quote}
> Just a quick note: with the implementation, we can have potential holes in
> documents - say we have {{/a, /a/b and /a/b/c}} and {{/a/b}} is bundled with
> {{/a}}. Then we'd only have documents - {{0:/, 1:/a, 3:/a/b/c}}.
> While that, of course, is ok, but we would need to factor this at least in
> oak-mongo.js (I can't recall any place else right now) which loops
> recursively at quite a few places with breaking the loop if no docs are found
> at a given depth.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5106) Reuse NioEventLoopGroup in standby client
Timothee Maret created OAK-5106:
---
Summary: Reuse NioEventLoopGroup in standby client
Key: OAK-5106
URL: https://issues.apache.org/jira/browse/OAK-5106
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-tar
Affects Versions: 1.5.13
Reporter: Timothee Maret
Fix For: 1.5.14
The Standby client code does instantiate a new {{NioEventLoopGroup}} for every
cycle (5 seconds). The standby tests do instantiate many {{NioEventLoopGroup}}.
Although {{NioEventLoopGroup}} are closed properly, each of them consume files
and management overhead (seting up/down). An improvement would be to reuse the
{{NioEventLoopGroup}} in standby client across polling cycles and reuse
{{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5105) withIncludeAncestorsRemove should support **
[
https://issues.apache.org/jira/browse/OAK-5105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-5105:
-
Fix Version/s: 1.6
> withIncludeAncestorsRemove should support **
>
>
> Key: OAK-5105
> URL: https://issues.apache.org/jira/browse/OAK-5105
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.5.13
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6, 1.5.14
>
>
> At the moment withIncludeAncestorsRemove is defined to only add {{!deep}}
> filters for all known parents. However, if you use \*\* you can't know all
> parents beforehand. So for those glob paths, besides the known parents, we
> should add the actual, full glob path (for NODE_REMOVED only that is) to the
> condition (using the trick to not add {{deleteSubtree}} which otherwise
> filters out subtree deletion).
> As a result you get different events based on the glob path:
> * for all known parents you get an event if one of those parents get removed
> * if you have a glob path registered, then you get an event for all matching
> paths should a parent of those nodes get deleted
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5104) GlobbingPathFilter does not match /a/**/b corrctly
[ https://issues.apache.org/jira/browse/OAK-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated OAK-5104: - Fix Version/s: 1.6 > GlobbingPathFilter does not match /a/**/b corrctly > -- > > Key: OAK-5104 > URL: https://issues.apache.org/jira/browse/OAK-5104 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.5.13 >Reporter: Stefan Egli >Assignee: Stefan Egli >Priority: Minor > Fix For: 1.6, 1.5.14 > > > Given a glob path with \*\* 'in the middle', the GlobbingPathFilter doens't > match that correctly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-5096) node type aggregate filter should be added in OR mode (not in AND)
[
https://issues.apache.org/jira/browse/OAK-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved OAK-5096.
--
Resolution: Fixed
Fix Version/s: 1.6
> node type aggregate filter should be added in OR mode (not in AND)
> --
>
> Key: OAK-5096
> URL: https://issues.apache.org/jira/browse/OAK-5096
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.5.13
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Blocker
> Fix For: 1.6, 1.5.14
>
>
> [~cziegeler] reported the following: The node type aggregate filter
> introduced in OAK-5021 ({{OakEventFilter.withNodeTypeAggregate}}) currently
> is added in 'AND' mode. That means its conditions must be fulfilled
> additionally to the other filter settings in order for an event to be
> generated. This is somewhat counter intuitive as the expectation is that this
> should be in 'OR' mode, which means all it should do is aggregate changes
> under a certain node type (based on certain sub paths) into a parent path (by
> using the identifier) but it should still send out all other events normally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-5105) withIncludeAncestorsRemove should support **
[
https://issues.apache.org/jira/browse/OAK-5105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved OAK-5105.
--
Resolution: Fixed
> withIncludeAncestorsRemove should support **
>
>
> Key: OAK-5105
> URL: https://issues.apache.org/jira/browse/OAK-5105
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.5.13
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.14
>
>
> At the moment withIncludeAncestorsRemove is defined to only add {{!deep}}
> filters for all known parents. However, if you use \*\* you can't know all
> parents beforehand. So for those glob paths, besides the known parents, we
> should add the actual, full glob path (for NODE_REMOVED only that is) to the
> condition (using the trick to not add {{deleteSubtree}} which otherwise
> filters out subtree deletion).
> As a result you get different events based on the glob path:
> * for all known parents you get an event if one of those parents get removed
> * if you have a glob path registered, then you get an event for all matching
> paths should a parent of those nodes get deleted
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5105) withIncludeAncestorsRemove should support **
[
https://issues.apache.org/jira/browse/OAK-5105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664401#comment-15664401
]
Stefan Egli commented on OAK-5105:
--
implemented in http://svn.apache.org/viewvc?rev=1769658=rev
> withIncludeAncestorsRemove should support **
>
>
> Key: OAK-5105
> URL: https://issues.apache.org/jira/browse/OAK-5105
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.5.13
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.14
>
>
> At the moment withIncludeAncestorsRemove is defined to only add {{!deep}}
> filters for all known parents. However, if you use \*\* you can't know all
> parents beforehand. So for those glob paths, besides the known parents, we
> should add the actual, full glob path (for NODE_REMOVED only that is) to the
> condition (using the trick to not add {{deleteSubtree}} which otherwise
> filters out subtree deletion).
> As a result you get different events based on the glob path:
> * for all known parents you get an event if one of those parents get removed
> * if you have a glob path registered, then you get an event for all matching
> paths should a parent of those nodes get deleted
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5020) Improved support for node removals
[ https://issues.apache.org/jira/browse/OAK-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664368#comment-15664368 ] Stefan Egli commented on OAK-5020: -- Added a follow-up OAK-5105 which will take care of supporting glob paths with withIncludeAncestorsRemove > Improved support for node removals > -- > > Key: OAK-5020 > URL: https://issues.apache.org/jira/browse/OAK-5020 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.5.12 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: 1.6, 1.5.13 > > > (Originally reported as JCR-4045, but moved to Oak as a result of introducing > the OakEventFilter in OAK-5013. From the original description: ) > If a listener is subscribed for removal events of a subtree, e.g. /a/b/c/d it > gets removal events for everything in that three. > However, if /a/b is removed, the listener is not informed at all, which makes > the listener state inconsistent/invalid > I suggest to add a new flag to the JackrabbitEventFilter and if that is > enabled the listener will get remove events of all the parent nodes - if the > listener is interested in remove events of any kind. > /cc [~cziegeler] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5105) withIncludeAncestorsRemove should support **
Stefan Egli created OAK-5105:
Summary: withIncludeAncestorsRemove should support **
Key: OAK-5105
URL: https://issues.apache.org/jira/browse/OAK-5105
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Affects Versions: 1.5.13
Reporter: Stefan Egli
Assignee: Stefan Egli
Fix For: 1.5.14
At the moment withIncludeAncestorsRemove is defined to only add {{!deep}}
filters for all known parents. However, if you use \*\* you can't know all
parents beforehand. So for those glob paths, besides the known parents, we
should add the actual, full glob path (for NODE_REMOVED only that is) to the
condition (using the trick to not add {{deleteSubtree}} which otherwise filters
out subtree deletion).
As a result you get different events based on the glob path:
* for all known parents you get an event if one of those parents get removed
* if you have a glob path registered, then you get an event for all matching
paths should a parent of those nodes get deleted
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-5104) GlobbingPathFilter does not match /a/**/b corrctly
[ https://issues.apache.org/jira/browse/OAK-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli resolved OAK-5104. -- Resolution: Fixed fixed in http://svn.apache.org/viewvc?rev=1769655=rev /cc [~mduerig] > GlobbingPathFilter does not match /a/**/b corrctly > -- > > Key: OAK-5104 > URL: https://issues.apache.org/jira/browse/OAK-5104 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.5.13 >Reporter: Stefan Egli >Assignee: Stefan Egli >Priority: Minor > Fix For: 1.5.14 > > > Given a glob path with \*\* 'in the middle', the GlobbingPathFilter doens't > match that correctly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5104) GlobbingPathFilter does not match /a/**/b corrctly
Stefan Egli created OAK-5104: Summary: GlobbingPathFilter does not match /a/**/b corrctly Key: OAK-5104 URL: https://issues.apache.org/jira/browse/OAK-5104 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.5.13 Reporter: Stefan Egli Assignee: Stefan Egli Priority: Minor Fix For: 1.5.14 Given a glob path with \*\* 'in the middle', the GlobbingPathFilter doens't match that correctly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5092) Add support for weighing the cache entries in caches
[
https://issues.apache.org/jira/browse/OAK-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-5092:
-
Attachment: OAK-5092.patch
initial proposal. I think I managed to come pretty close to the sizes of the
cache by experimenting with the entries overhead. I view this as a best effort
estimate, it's not really realistic to expect a real value here.
Another change is related to {{PriorityCache}}'s {{evictionCount}} which was
not really covering all the evictions that were happening on the cache (2 cases
missing, one was the generation purge, and the other one is the overwrite of an
item in the cache).
[~mduerig] thoughts?
> Add support for weighing the cache entries in caches
>
>
> Key: OAK-5092
> URL: https://issues.apache.org/jira/browse/OAK-5092
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 1.6, 1.5.15
>
> Attachments: OAK-5092.patch
>
>
> Some of the current caches in {{segment-tar}} don't have support for
> evaluation of current weight. I'd like to look into the {{PriorityCache}} and
> {{RecordCache}} we use and possibly add something. this is based on initial
> patch from OAK-4966.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5037) Update Oak 1.2 and Oak 1.4 to Jackrabbit 2.12.5
[ https://issues.apache.org/jira/browse/OAK-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-5037. - Bulk close for 1.4.10 > Update Oak 1.2 and Oak 1.4 to Jackrabbit 2.12.5 > --- > > Key: OAK-5037 > URL: https://issues.apache.org/jira/browse/OAK-5037 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Affects Versions: 1.2.20, 1.4.9 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.2.21, 1.4.10 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-5100) Provide source store external references flag via command line if available
[
https://issues.apache.org/jira/browse/OAK-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu resolved OAK-5100.
--
Resolution: Fixed
Assignee: Alex Parvulescu
thanks for the review!
applied the patch with rev http://svn.apache.org/viewvc?rev=1769626=rev
> Provide source store external references flag via command line if available
> ---
>
> Key: OAK-5100
> URL: https://issues.apache.org/jira/browse/OAK-5100
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: upgrade
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.6, 1.5.14
>
> Attachments: OAK-5100.patch
>
>
> Currently the upgrade code tries to figure out if the source store uses an
> external datastore by running a {{SegmentTracker.collectBlobReferences}}
> process. This has performance problems when the given store doesn't use a
> datastore, so the above method will traverse the entire store without any
> callback (think 150GB store).
> The relatively simple fix is to provide this flag via the command line for
> the upgrade bits, still using the existing method as a fallback if nothing is
> provided.
> {noformat}
> at org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:224)
> at org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:204)
> at
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.readSegment(FileStore.java:1238)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.readSegment(SegmentTracker.java:242)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentId.getSegment(SegmentId.java:149)
> - locked <0x00054e8e25c8> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentId)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.collectBlobReferences(SegmentTracker.java:307)
> at
> org.apache.jackrabbit.oak.upgrade.cli.node.SegmentFactory.hasExternalBlobReferences(SegmentFactory.java:120)
> at
> org.apache.jackrabbit.oak.upgrade.cli.node.StoreFactory.hasExternalBlobReferences(StoreFactory.java:67)
> at
> org.apache.jackrabbit.oak.upgrade.cli.parser.StoreArguments.srcUsesEmbeddedDatastore(StoreArguments.java:109)
> at
> org.apache.jackrabbit.oak.upgrade.cli.OakUpgrade.migrate(OakUpgrade.java:64)
> at org.apache.jackrabbit.oak.upgrade.cli.OakUpgrade.main(OakUpgrade.java:48)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5100) Provide source store external references flag via command line if available
[
https://issues.apache.org/jira/browse/OAK-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15663913#comment-15663913
]
Tomek Rękawek commented on OAK-5100:
Got it, as I wrote, patch LGTM.
> Provide source store external references flag via command line if available
> ---
>
> Key: OAK-5100
> URL: https://issues.apache.org/jira/browse/OAK-5100
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: upgrade
>Reporter: Alex Parvulescu
> Fix For: 1.6, 1.5.14
>
> Attachments: OAK-5100.patch
>
>
> Currently the upgrade code tries to figure out if the source store uses an
> external datastore by running a {{SegmentTracker.collectBlobReferences}}
> process. This has performance problems when the given store doesn't use a
> datastore, so the above method will traverse the entire store without any
> callback (think 150GB store).
> The relatively simple fix is to provide this flag via the command line for
> the upgrade bits, still using the existing method as a fallback if nothing is
> provided.
> {noformat}
> at org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:224)
> at org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:204)
> at
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.readSegment(FileStore.java:1238)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.readSegment(SegmentTracker.java:242)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentId.getSegment(SegmentId.java:149)
> - locked <0x00054e8e25c8> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentId)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.collectBlobReferences(SegmentTracker.java:307)
> at
> org.apache.jackrabbit.oak.upgrade.cli.node.SegmentFactory.hasExternalBlobReferences(SegmentFactory.java:120)
> at
> org.apache.jackrabbit.oak.upgrade.cli.node.StoreFactory.hasExternalBlobReferences(StoreFactory.java:67)
> at
> org.apache.jackrabbit.oak.upgrade.cli.parser.StoreArguments.srcUsesEmbeddedDatastore(StoreArguments.java:109)
> at
> org.apache.jackrabbit.oak.upgrade.cli.OakUpgrade.migrate(OakUpgrade.java:64)
> at org.apache.jackrabbit.oak.upgrade.cli.OakUpgrade.main(OakUpgrade.java:48)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2612) Findbugs plugin version should depend on JDK version
[ https://issues.apache.org/jira/browse/OAK-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu updated OAK-2612: - Fix Version/s: 1.0.36 > Findbugs plugin version should depend on JDK version > > > Key: OAK-2612 > URL: https://issues.apache.org/jira/browse/OAK-2612 > Project: Jackrabbit Oak > Issue Type: Bug > Components: parent >Affects Versions: 1.1.7 >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.1.8, 1.0.36 > > > Looking at the current CI builds the JDK 8 one is always failing because > _maven-findbugs-plugin-2.5.3_ doesn't work with it, on the other hand > upgrading to 3.0.0 will make the JDK 6 build failing, therefore the version > used has to be dependent on the used JDK. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2612) Findbugs plugin version should depend on JDK version
[ https://issues.apache.org/jira/browse/OAK-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15663868#comment-15663868 ] Alex Parvulescu commented on OAK-2612: -- I merged this to 1.0 branch with r 1769619, verifying the releases failed for me on java8. > Findbugs plugin version should depend on JDK version > > > Key: OAK-2612 > URL: https://issues.apache.org/jira/browse/OAK-2612 > Project: Jackrabbit Oak > Issue Type: Bug > Components: parent >Affects Versions: 1.1.7 >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.1.8, 1.0.36 > > > Looking at the current CI builds the JDK 8 one is always failing because > _maven-findbugs-plugin-2.5.3_ doesn't work with it, on the other hand > upgrading to 3.0.0 will make the JDK 6 build failing, therefore the version > used has to be dependent on the used JDK. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-5069) Backup fails when called from RepositoryManagementMBean#startBackup
[
https://issues.apache.org/jira/browse/OAK-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-5069.
Resolution: Fixed
Fix Version/s: (was: 1.6)
Fixed at http://svn.apache.org/viewvc?rev=1769614=rev
Thanks [~dulceanu] for the patch!
> Backup fails when called from RepositoryManagementMBean#startBackup
> ---
>
> Key: OAK-5069
> URL: https://issues.apache.org/jira/browse/OAK-5069
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.5.12
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
> Fix For: 1.5.14
>
> Attachments: OAK-5069-01.patch, OAK-5069-02.patch
>
>
> When calling {{RepositoryManagementMBean.startBackup}}, the operation fails
> with the following stacktrace:
> {code:java}
> 04.11.2016 13:12:56.733 *ERROR* [qtp2039314079-250]
> org.apache.jackrabbit.oak.management.ManagementOperation Backup failed
> java.lang.IllegalStateException: /repository/segmentstore is in use by
> another store.
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.(FileStore.java:168)
> at
> org.apache.jackrabbit.oak.segment.file.FileStoreBuilder.build(FileStoreBuilder.java:304)
> at
> org.apache.jackrabbit.oak.backup.impl.FileStoreBackupImpl.backup(FileStoreBackupImpl.java:65)
> at
> org.apache.jackrabbit.oak.backup.impl.FileStoreBackupRestoreImpl$1.call(FileStoreBackupRestoreImpl.java:102)
> at
> org.apache.jackrabbit.oak.backup.impl.FileStoreBackupRestoreImpl$1.call(FileStoreBackupRestoreImpl.java:97)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.nio.channels.OverlappingFileLockException: null
> at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1062)
> at java.nio.channels.FileChannel.lock(FileChannel.java:1053)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.(FileStore.java:166)
> ... 8 common frames omitted
> {code}
> /cc [~mduerig]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5069) Backup fails when called from RepositoryManagementMBean#startBackup
[
https://issues.apache.org/jira/browse/OAK-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-5069:
-
Attachment: OAK-5069-02.patch
Changed configuration to allow absolute paths, while keeping the default in
*repository.home*/segmentstore-backup.
[~mduerig], could you take a look at the patch, please?
> Backup fails when called from RepositoryManagementMBean#startBackup
> ---
>
> Key: OAK-5069
> URL: https://issues.apache.org/jira/browse/OAK-5069
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.5.12
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
> Fix For: 1.6, 1.5.14
>
> Attachments: OAK-5069-01.patch, OAK-5069-02.patch
>
>
> When calling {{RepositoryManagementMBean.startBackup}}, the operation fails
> with the following stacktrace:
> {code:java}
> 04.11.2016 13:12:56.733 *ERROR* [qtp2039314079-250]
> org.apache.jackrabbit.oak.management.ManagementOperation Backup failed
> java.lang.IllegalStateException: /repository/segmentstore is in use by
> another store.
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.(FileStore.java:168)
> at
> org.apache.jackrabbit.oak.segment.file.FileStoreBuilder.build(FileStoreBuilder.java:304)
> at
> org.apache.jackrabbit.oak.backup.impl.FileStoreBackupImpl.backup(FileStoreBackupImpl.java:65)
> at
> org.apache.jackrabbit.oak.backup.impl.FileStoreBackupRestoreImpl$1.call(FileStoreBackupRestoreImpl.java:102)
> at
> org.apache.jackrabbit.oak.backup.impl.FileStoreBackupRestoreImpl$1.call(FileStoreBackupRestoreImpl.java:97)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.nio.channels.OverlappingFileLockException: null
> at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1062)
> at java.nio.channels.FileChannel.lock(FileChannel.java:1053)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.(FileStore.java:166)
> ... 8 common frames omitted
> {code}
> /cc [~mduerig]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4973) Speed up tests with MongoFixture
[ https://issues.apache.org/jira/browse/OAK-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4973. - Bulk close for 1.5.13 > Speed up tests with MongoFixture > > > Key: OAK-4973 > URL: https://issues.apache.org/jira/browse/OAK-4973 > Project: Jackrabbit Oak > Issue Type: Test > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.13 > > > The time to run tests using MongoFixture can be reduced by dropping > collections instead of dropping and recreating the DB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5010) Document split with binary properties too eager
[ https://issues.apache.org/jira/browse/OAK-5010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-5010. - Bulk close for 1.5.13 > Document split with binary properties too eager > --- > > Key: OAK-5010 > URL: https://issues.apache.org/jira/browse/OAK-5010 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.5.1 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.13 > > > OAK-2392 changed the split logic for documents and creates a split document > as soon as a binary property is overwritten. This happens quite frequently in > a default Oak setup with oak-lucene. Lucene files are stored in the > repository and many of them are short lived because they are merged into > bigger segments later. This means all documents for those files are split as > soon as the file is deleted. The revision garbage collection does not get any > benefit from this, because it will remove the files anyway. It is actually > more expensive, because the GC also needs to collect the split documents. > The split logic should be updated to only create a split document with binary > properties when the node still exists at the current head revision. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4868) Update SegmentS3DataStoreBlobGCTest in oak-it once oak-segment-tar updated
[ https://issues.apache.org/jira/browse/OAK-4868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4868. - Bulk close for 1.5.13 > Update SegmentS3DataStoreBlobGCTest in oak-it once oak-segment-tar updated > -- > > Key: OAK-4868 > URL: https://issues.apache.org/jira/browse/OAK-4868 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: blob >Reporter: Amit Jain >Assignee: Amit Jain >Priority: Minor > Fix For: 1.6, 1.5.13 > > > SegmentS3DataStoreBlobGCIT in oak-it needs to be updated with changes similar > to done for OAK-4848. > This would require oak-segment-tar updated to 0.0.14 once released. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5022) add includeSubtreeOnDelete flag to OakEventFilter
[
https://issues.apache.org/jira/browse/OAK-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5022.
-
Bulk close for 1.5.13
> add includeSubtreeOnDelete flag to OakEventFilter
> -
>
> Key: OAK-5022
> URL: https://issues.apache.org/jira/browse/OAK-5022
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6, 1.5.13
>
>
> (Originally reported as JCR-4037, but moved to Oak as a result of introducing
> the OakEventFilter in OAK-5013. From the original description: )
> In some cases of observation it would be useful to receive events of child
> node or properties of a parent/grandparent that was deleted. Currently (in
> Oak at least) one only receives a deleted event for the node that was deleted
> and none of the children.
> Suggesting to (re)introduce a flag, eg as follows to the
> JackrabbitEventFilter:
> {code}
> boolean includeSubtreeOnRemove;
> {code}
> (Open for any better name of course)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4985) Upgrade Oak Segment Tar dependency to 0.0.16
[ https://issues.apache.org/jira/browse/OAK-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4985. - Bulk close for 1.5.13 > Upgrade Oak Segment Tar dependency to 0.0.16 > > > Key: OAK-4985 > URL: https://issues.apache.org/jira/browse/OAK-4985 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.6, 1.5.13 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4955) Write log messages to file only (oak-pojosr)
[ https://issues.apache.org/jira/browse/OAK-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4955. - Bulk close for 1.5.13 > Write log messages to file only (oak-pojosr) > > > Key: OAK-4955 > URL: https://issues.apache.org/jira/browse/OAK-4955 > Project: Jackrabbit Oak > Issue Type: Test > Components: pojosr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.13 > > > The log configuration for tests in oak-pojosr currently writes log messages > to a file and the console. This creates a rather verbose build output. I'd > like to disable the log output to the console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5032) Update Groovy version in oak-run to 2.4.7
[ https://issues.apache.org/jira/browse/OAK-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-5032. - Bulk close for 1.5.13 > Update Groovy version in oak-run to 2.4.7 > - > > Key: OAK-5032 > URL: https://issues.apache.org/jira/browse/OAK-5032 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.6, 1.5.13 > > > oak-run currently packages Groovy 2.3.1 while latest is 2.4.7. We should > update to latest for new features and better performance > With use of invokedynamic support and new version a groovy a script [1] which > was taking 1 hr on a big repository now takes 30 mins! > [1] https://gist.github.com/chetanmeh/d7588d96a839dd2d26760913e4055215 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5059) DocumentCachingDataStoreStatsTest sometimes stuck
[
https://issues.apache.org/jira/browse/OAK-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5059.
-
Bulk close for 1.5.13
> DocumentCachingDataStoreStatsTest sometimes stuck
> -
>
> Key: OAK-5059
> URL: https://issues.apache.org/jira/browse/OAK-5059
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: it
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.6, 1.5.13
>
> Attachments: unit-tests.log, unit-tests.log
>
>
> The test sometimes gets stuck when it starts on an existing MongoDB with data
> that was written with a Virtual clock. The log then writes a WARN message
> like this:
> {noformat}
> 14:01:57.823 WARN [main] DocumentNodeStore.java:2136 Detected clock
> differences. Local time is 'Thu Nov 03 14:01:57 CET 2016', while most recent
> external time is 'Thu Nov 03 15:00:00 CET 2016'. Current _lastRev entries:
> [r1582a7d3d6b-0-1]
> 14:01:57.826 WARN [main] DocumentNodeStore.java:2143 Background read will be
> delayed by 3482,8 seconds. Please check system time on cluster nodes.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5020) Improved support for node removals
[ https://issues.apache.org/jira/browse/OAK-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-5020. - Bulk close for 1.5.13 > Improved support for node removals > -- > > Key: OAK-5020 > URL: https://issues.apache.org/jira/browse/OAK-5020 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.5.12 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: 1.6, 1.5.13 > > > (Originally reported as JCR-4045, but moved to Oak as a result of introducing > the OakEventFilter in OAK-5013. From the original description: ) > If a listener is subscribed for removal events of a subtree, e.g. /a/b/c/d it > gets removal events for everything in that three. > However, if /a/b is removed, the listener is not informed at all, which makes > the listener state inconsistent/invalid > I suggest to add a new flag to the JackrabbitEventFilter and if that is > enabled the listener will get remove events of all the parent nodes - if the > listener is interested in remove events of any kind. > /cc [~cziegeler] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4984) Server time unavailable with authenticated connection to MongoDB
[
https://issues.apache.org/jira/browse/OAK-4984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4984.
-
Bulk close for 1.5.13
> Server time unavailable with authenticated connection to MongoDB
>
>
> Key: OAK-4984
> URL: https://issues.apache.org/jira/browse/OAK-4984
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
>Affects Versions: 1.4
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Labels: resilience
> Fix For: 1.6, 1.5.13
>
>
> The MongoDocumentStore gets the current server time with the {{serverStatus}}
> command. When MongoDB is configured with authentication, the command may fail
> because it requires the
> [clusterMonitor|https://docs.mongodb.com/manual/reference/built-in-roles/#clusterMonitor]
> role.
> The method will then simply log a WARN message and assume no time difference.
> Maybe there is a different command we can use to get the time on the server?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4888) Warn or fail queries above a configurable cost value
[ https://issues.apache.org/jira/browse/OAK-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4888. - Bulk close for 1.5.13 > Warn or fail queries above a configurable cost value > > > Key: OAK-4888 > URL: https://issues.apache.org/jira/browse/OAK-4888 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Alexander Klimetschek >Assignee: Thomas Mueller > Labels: docs-impacting > Fix For: 1.6, 1.5.13 > > > *Problem:* It's easy to run into performance problems with queries that are > not backed by an index or miss the right one. Developers writing these > queries typically do not have the real large production data, and thus don't > see that a query would scale badly, and would not see any traversal warnings, > as these only happen with a large number of results. > *Proposal:* Oak's query engine already calculates a cost estimate to make a > decision which index to use, or even if there is any at all. This cost > estimate could be used to find out if a query is not supported by an index or > with one that is not suitable enough (e.g. ordering by property that is not > indexed) > If a query is above a certain cost value, a big warning could be put out or > even the query could be made to fail (maybe a per query option, that you > might want to have to "fail" by default to ensure people are not overlooking > the problem). The cost limit should be configurable, as it might depend on > the hardware power. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5011) Add event aggregation support to observation filtering
[
https://issues.apache.org/jira/browse/OAK-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5011.
-
Bulk close for 1.5.13
> Add event aggregation support to observation filtering
> --
>
> Key: OAK-5011
> URL: https://issues.apache.org/jira/browse/OAK-5011
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-5011.patch
>
>
> Currently the observation filtering 'subsystem' allows only the creation of
> events with the path and identifier set to the parent of where the change
> happened. To support features like JCR-4046 we need some sort of event
> 'aggregation'. The idea is that while the change happened somewhere in a
> subtree it would still be reported with the {{event.getIdentifier()}} set on
> some parent/aggregator node (the {{event.getPath()}} would still be the
> actual change).
> To support this, the suggestion is to add a {{EventAggregator}} to the
> {{FilterBuilder}} which would be invoked right before the actual event is
> being created, but after the filtering happened, so it would only affect how
> the event looks like, not whether or not the event is generated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4788) Fulltext parser sorts and unique-s parsed terms
[
https://issues.apache.org/jira/browse/OAK-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4788.
-
Bulk close for 1.5.13
> Fulltext parser sorts and unique-s parsed terms
> ---
>
> Key: OAK-4788
> URL: https://issues.apache.org/jira/browse/OAK-4788
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.6, 1.5.13
>
>
> Pasting a bit of discussion from OAK-4705:
> {quote}
> bq. whether it's a good idea to sort entries ("hello - world" becomes "-
> hello world") and make them unique ("test test" becomes "test").
> I think parser shouldn't play with ordering .. but I can see the rational
> that it allows consumer of parsed output to potentially have forward seeks in
> their dictionaries. Otoh, I think making unique or not shouldn't be parsers's
> concern at all.
> I'd open a new issue to follow up on these aspects.
> {quote}
> /cc [~tmueller]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5016) OOM in SegmentDataStoreBlobGCIT
[
https://issues.apache.org/jira/browse/OAK-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5016.
-
Bulk close for 1.5.13
> OOM in SegmentDataStoreBlobGCIT
> ---
>
> Key: OAK-5016
> URL: https://issues.apache.org/jira/browse/OAK-5016
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Amit Jain
> Labels: test-failure
> Fix For: 1.6, 1.5.13
>
>
> I've seen that test going OOM on our Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/#showFailuresLink
> {noformat}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:220)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:141)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckInit(SegmentDataStoreBlobGCIT.java:317)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4908) Best-effort prefiltering in ChangeProcessor based on ChangeSet
[
https://issues.apache.org/jira/browse/OAK-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4908.
-
Bulk close for 1.5.13
> Best-effort prefiltering in ChangeProcessor based on ChangeSet
> --
>
> Key: OAK-4908
> URL: https://issues.apache.org/jira/browse/OAK-4908
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core, jcr
>Affects Versions: 1.5.11
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Labels: review
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4908.patch, OAK-4908.v2.patch, OAK-4908.v3.patch,
> OAK-4908.v4.patch, OAK-4908.v5.patch
>
>
> This is a subtask as a result of
> [discussions|https://issues.apache.org/jira/browse/OAK-4796?focusedCommentId=15550962=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15550962]
> around design in OAK-4796:
> Based on the ChangeSet provided with OAK-4907 in the CommitContext, the
> ChangeProcessor should do a best-effort prefiltering of commits before they
> get added to the (BackgroundObserver's) queue.
> This consists of the following parts:
> * -the support for optionally excluding commits from being added to the queue
> in the BackgroundObserver- EDIT: factored that out into OAK-4916
> * -the BackgroundObserver signaling downstream Observers that a change should
> be excluded via a {{NOOP_CHANGE}} CommitInfo- EDIT: factored that out into
> OAK-4916
> * the ChangeProcessor using OAK-4907's ChangeSet of the CommitContext for
> best-effort prefiltering - and handling the {{NOOP_CHANGED}} CommitInfo
> introduced in OAK-4916
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4963) Test failure: SegmentDataStoreBlobGCIT
[
https://issues.apache.org/jira/browse/OAK-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4963.
-
Bulk close for 1.5.13
> Test failure: SegmentDataStoreBlobGCIT
> --
>
> Key: OAK-4963
> URL: https://issues.apache.org/jira/browse/OAK-4963
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Labels: test-failure
> Fix For: 1.6, 1.5.13
>
>
> SegmentDataStoreBlobGCIT seems to crash the JVM on Java 7. Following is the
> relevant part of the build output.
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.19.1:integration-test (default) @
> oak-segment-tar ---
> ---
> T E S T S
> ---
> Running org.apache.jackrabbit.oak.segment.file.FileStoreIT
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 22.301 sec -
> in org.apache.jackrabbit.oak.segment.file.FileStoreIT
> Running org.apache.jackrabbit.oak.segment.file.SegmentReferenceLimitTestIT
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec - in
> org.apache.jackrabbit.oak.segment.file.SegmentReferenceLimitTestIT
> Running org.apache.jackrabbit.oak.segment.file.LargeNumberOfPropertiesTestIT
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.001 sec -
> in org.apache.jackrabbit.oak.segment.file.LargeNumberOfPropertiesTestIT
> Running org.apache.jackrabbit.oak.segment.SegmentOverflowExceptionIT
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec - in
> org.apache.jackrabbit.oak.segment.SegmentOverflowExceptionIT
> Running org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 45.78 sec -
> in org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT
> Running org.apache.jackrabbit.oak.segment.standby.FailoverSslTestIT
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 9.202 sec -
> in org.apache.jackrabbit.oak.segment.standby.FailoverSslTestIT
> Running org.apache.jackrabbit.oak.segment.standby.BrokenNetworkIT
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 63.024 sec -
> in org.apache.jackrabbit.oak.segment.standby.BrokenNetworkIT
> Running
> org.apache.jackrabbit.oak.segment.standby.FailoverMultipleClientsTestIT
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.052 sec -
> in org.apache.jackrabbit.oak.segment.standby.FailoverMultipleClientsTestIT
> Running org.apache.jackrabbit.oak.segment.standby.MBeanIT
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 9.287 sec -
> in org.apache.jackrabbit.oak.segment.standby.MBeanIT
> Running org.apache.jackrabbit.oak.segment.standby.FailoverIPRangeIT
> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 42.691 sec -
> in org.apache.jackrabbit.oak.segment.standby.FailoverIPRangeIT
> Running org.apache.jackrabbit.oak.segment.standby.StandbyTestIT
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 23.303 sec -
> in org.apache.jackrabbit.oak.segment.standby.StandbyTestIT
> Running org.apache.jackrabbit.oak.segment.standby.RecoverTestIT
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.415 sec -
> in org.apache.jackrabbit.oak.segment.standby.RecoverTestIT
> Running org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 39.002 sec -
> in org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT
> Running org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT
> Results :
> Tests run: 65, Failures: 0, Errors: 0, Skipped: 3
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 10:17 min
> [INFO] Finished at: 2016-10-19T20:45:40+00:00
> [INFO] Final Memory: 63M/553M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:integration-test
> (default) on project oak-segment-tar: Execution default of goal
> org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:integration-test
> failed: The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> [ERROR] Command was /bin/sh -c cd /apps/jenkins/workspace/oak-segment-tar &&
> /opt/jdk-7/jre/bin/java -Xmx512m -XX:MaxPermSize=64m
> -XX:+HeapDumpOnOutOfMemoryError -Dupdate.limit=100 -Djava.awt.headless=true
> -jar
>
[jira] [Closed] (OAK-2722) IndexCopier fails to delete older index directory upon reindex
[
https://issues.apache.org/jira/browse/OAK-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-2722.
-
Bulk close for 1.5.13
> IndexCopier fails to delete older index directory upon reindex
> --
>
> Key: OAK-2722
> URL: https://issues.apache.org/jira/browse/OAK-2722
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: resilience
> Fix For: 1.6, 1.5.13
>
>
> {{IndexCopier}} tries to remove the older index directory incase of reindex.
> This might fails on platform like Windows if the files are still memory
> mapped or are locked.
> For deleting directories we would need to take similar approach like being
> done with deleting old index files i.e. do retries later.
> Due to this following test fails on Windows (Per [~julian.resc...@gmx.de] )
> {noformat}
> Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.07 sec <<<
> FAILURE!
> deleteOldPostReindex(org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest)
> Time elapsed: 0.02 sec <<< FAILURE!
> java.lang.AssertionError: Old index directory should have been removed
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertFalse(Assert.java:68)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.deleteOldPostReindex(IndexCopierTest.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4956) SegmentGCOptions retainedGenerations setting not exposed via OSGi
[
https://issues.apache.org/jira/browse/OAK-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4956.
-
Bulk close for 1.5.13
> SegmentGCOptions retainedGenerations setting not exposed via OSGi
> -
>
> Key: OAK-4956
> URL: https://issues.apache.org/jira/browse/OAK-4956
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.6, 1.5.13
>
>
> Expose {{SegmentGCOptions#retainedGenerations}} setting via OSGi.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-2460) Resolve the base directory path of persistent cache against repository home
[
https://issues.apache.org/jira/browse/OAK-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-2460.
-
Bulk close for 1.5.13
> Resolve the base directory path of persistent cache against repository home
> ---
>
> Key: OAK-2460
> URL: https://issues.apache.org/jira/browse/OAK-2460
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Chetan Mehrotra
>Assignee: Marcel Reutegger
>Priority: Minor
> Labels: technical_debt
> Fix For: 1.6, 1.5.13
>
>
> Currently PersistentCache uses the directory path directly. Various other
> parts in Oak which need access to the filesystem currently make use of
> {{repository.home}} framework property in OSGi env [1]
> Same should also be used in PersistentCache
> [1] http://jackrabbit.apache.org/oak/docs/osgi_config.html#SegmentNodeStore
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4900) Enable persistent caches by default
[ https://issues.apache.org/jira/browse/OAK-4900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4900. - Bulk close for 1.5.13 > Enable persistent caches by default > --- > > Key: OAK-4900 > URL: https://issues.apache.org/jira/browse/OAK-4900 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: observation > Fix For: 1.6, 1.5.13 > > > The diff persistent cache is important for efficient processing of external > changes and should be enabled by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5007) Put oak-segment-tar back in the main release cycle
[ https://issues.apache.org/jira/browse/OAK-5007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-5007. - Bulk close for 1.5.13 > Put oak-segment-tar back in the main release cycle > -- > > Key: OAK-5007 > URL: https://issues.apache.org/jira/browse/OAK-5007 > Project: Jackrabbit Oak > Issue Type: Bug > Components: parent, segment-tar >Reporter: Francesco Mari >Assignee: Francesco Mari >Priority: Blocker > Fix For: 1.6, 1.5.13 > > > The oak-segment-tar module should be included in the main release cycle. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4929) Clean GCMonitor#compacted method arguments
[
https://issues.apache.org/jira/browse/OAK-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4929.
-
Bulk close for 1.5.13
> Clean GCMonitor#compacted method arguments
> --
>
> Key: OAK-4929
> URL: https://issues.apache.org/jira/browse/OAK-4929
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core, lucene
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.6, 1.5.13
>
>
> Subtask of OAK-4283, first step is to remove all arguments from the
> {{GCMonitor#compacted}} api.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-1312) Bundle nodes into a document
[ https://issues.apache.org/jira/browse/OAK-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-1312. - Bulk close for 1.5.13 > Bundle nodes into a document > > > Key: OAK-1312 > URL: https://issues.apache.org/jira/browse/OAK-1312 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core, documentmk >Reporter: Marcel Reutegger >Assignee: Chetan Mehrotra > Labels: docs-impacting, performance > Fix For: 1.6, 1.5.13 > > Attachments: OAK-1312-meta-prop-handling.patch, > OAK-1312-review-v1.diff, OAK-1312-review-v2.diff, benchmark-result-db2.txt, > benchmark-result-postgres.txt, benchmark-results.txt, run-benchmark.sh > > > For very fine grained content with many nodes and only few properties per > node it would be more efficient to bundle multiple nodes into a single > MongoDB document. Mostly reading would benefit because there are less > roundtrips to the backend. At the same time storage footprint would be lower > because metadata overhead is per document. > Feature branch - > https://github.com/chetanmeh/jackrabbit-oak/compare/trunk...chetanmeh:OAK-1312 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4981) Config option to disable specific bundling config
[
https://issues.apache.org/jira/browse/OAK-4981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4981.
-
Bulk close for 1.5.13
> Config option to disable specific bundling config
> -
>
> Key: OAK-4981
> URL: https://issues.apache.org/jira/browse/OAK-4981
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: bundling, docs-impacting
> Fix For: 1.6, 1.5.13
>
>
> With OAK-4975 Oak would be shipping some default bundling config. An
> application might want to disable such bundling and for those cases we need
> to support some config option to disable bundling for specific nodetypes.
> *Proposal*
> Have a boolean property {{disabled}} on bundling config for specific nodetype
> to indication that this bundling config is not to be used
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4969.
-
Bulk close for 1.5.13
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.2, 1.4, 1.6, 1.2.21, 1.5.13, 1.4.10
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
> at
>
[jira] [Closed] (OAK-4971) Implement caching for FileDataStore
[ https://issues.apache.org/jira/browse/OAK-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4971. - Bulk close for 1.5.13 > Implement caching for FileDataStore > --- > > Key: OAK-4971 > URL: https://issues.apache.org/jira/browse/OAK-4971 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: blob >Reporter: Amit Jain >Assignee: Amit Jain > Fix For: 1.6, 1.5.13 > > > With OAK-3253, an implementation was done by using CachingDataStore. This > also should be refreshed to use the new caching implemented using OAK-4837. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4869) Enable benchmarks for DataStore
[ https://issues.apache.org/jira/browse/OAK-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4869. - Bulk close for 1.5.13 > Enable benchmarks for DataStore > --- > > Key: OAK-4869 > URL: https://issues.apache.org/jira/browse/OAK-4869 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: blob, run >Reporter: Amit Jain >Assignee: Amit Jain >Priority: Minor > Fix For: 1.6, 1.5.13 > > > Benchmarks for creating/retrieving files should have support for configuring > DataStore(s) including S3DataStore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4817) QueryEngineSettings without MBean
[ https://issues.apache.org/jira/browse/OAK-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4817. - Bulk close for 1.5.13 > QueryEngineSettings without MBean > - > > Key: OAK-4817 > URL: https://issues.apache.org/jira/browse/OAK-4817 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.6, 1.5.13 > > Attachments: OAK-4817.patch > > > QueryEngineSettings is currently an MBean, and constructing a new instance is > expensive. This is seem in some oak-core security components. The MBean > functionality should be decoupled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5076) CopyOnWrite directory should clear working set of files being written upon start
[
https://issues.apache.org/jira/browse/OAK-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5076.
-
Bulk close for 1.5.13
> CopyOnWrite directory should clear working set of files being written upon
> start
>
>
> Key: OAK-5076
> URL: https://issues.apache.org/jira/browse/OAK-5076
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6, 1.5.13
>
>
> {{CopyOnWriteDirectory}} makes use of working set (introduced with OAK-3110)
> to notify the {{CopyOnReadDirectory}} that those files are in use. This would
> ensure that CoR dir does not consider such files as garbage.
> This set gets cleared when CoW dir closes cleanly. However in case it does
> not close cleanly such a state would not be cleared. To handle such cases we
> should clear the working set upon construction of CoW dir as there can be
> only one writer by design
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4606) Avoid persisting rootRevision in PathFilteringDiff
[ https://issues.apache.org/jira/browse/OAK-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4606. - Bulk close for 1.5.13 > Avoid persisting rootRevision in PathFilteringDiff > -- > > Key: OAK-4606 > URL: https://issues.apache.org/jira/browse/OAK-4606 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.6, 1.5.13 > > > With OAK-4470 readRevisions were remove and instead PathFilteringDiff now > stores the root revision in each nodestate. We can avoid that and only store > the root revision with root node state and use that for child nodestates -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4974) Enable configuring QueryEngineSettings via OSGi config
[
https://issues.apache.org/jira/browse/OAK-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4974.
-
Bulk close for 1.5.13
> Enable configuring QueryEngineSettings via OSGi config
> --
>
> Key: OAK-4974
> URL: https://issues.apache.org/jira/browse/OAK-4974
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: docs-impacting
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4974-v1.patch
>
>
> Oak QueryEngine exposes few settings options via {{QueryEngineSettings}}.
> Currently they can be configured via
> # System properties
> # JMX - The settings are not persistent
> We should have a way to configure them via OSGi also. A simple option can be
> to have a OSGi component which obtains a reference to
> {{QueryEngineSettingsMBean}} and then modifies the config upon activation
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-2629) Cleanup Oak Travis jobs
[ https://issues.apache.org/jira/browse/OAK-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-2629. - Bulk close for 1.5.13 > Cleanup Oak Travis jobs > --- > > Key: OAK-2629 > URL: https://issues.apache.org/jira/browse/OAK-2629 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: it >Reporter: Tommaso Teofili >Assignee: Marcel Reutegger > Labels: CI > Fix For: 1.6, 1.5.13 > > > Since we're moving toward Jenkins, let's remove the Travis jobs for Oak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4944) Enable RefreshOnGCTest segment-tar fixture
[ https://issues.apache.org/jira/browse/OAK-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4944. - Bulk close for 1.5.13 > Enable RefreshOnGCTest segment-tar fixture > -- > > Key: OAK-4944 > URL: https://issues.apache.org/jira/browse/OAK-4944 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: jcr >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Fix For: 1.6, 1.5.13 > > > Re-enable RefreshOnGCTest fixture post OAK-4929 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4968) Query engine: sort order is calculated multiple times unnecessarily
[ https://issues.apache.org/jira/browse/OAK-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4968. - Bulk close for 1.5.13 > Query engine: sort order is calculated multiple times unnecessarily > --- > > Key: OAK-4968 > URL: https://issues.apache.org/jira/browse/OAK-4968 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.6, 1.5.13 > > > In QueryImpl.getBestSelectorExecutionPlan, the sort order is calculated for > each index, which is unnecessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5034) FileStoreUtil#readSegmentWithRetry max retry delay is too short to be functional
[
https://issues.apache.org/jira/browse/OAK-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5034.
-
Bulk close for 1.5.13
> FileStoreUtil#readSegmentWithRetry max retry delay is too short to be
> functional
>
>
> Key: OAK-5034
> URL: https://issues.apache.org/jira/browse/OAK-5034
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-5034.patch
>
>
> The commit {{1765838}} introduced the {{FileStoreUtil#readSegmentWithRetry}}
> util and reduced the period between two tries (from 2sec to 0.125s) while the
> total number of tries did not change.
> This does not give enough time for the server to find references and
> segments, thus causing exceptions such as
> {code}
> 29.10.2016 05:07:37.242 *ERROR* [sling-default-2-Registered Service.605]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.IllegalStateException: Unable to read references of segment
> 5168c878-3a3f-49d0-aea9-b8b57d5d867f from primary
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.readReferences(StandbyClientSyncExecution.java:196)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.copySegmentHierarchyFromPrimary(StandbyClientSyncExecution.java:130)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.compareAgainstBaseState(StandbyClientSyncExecution.java:94)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:74)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:143)
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> and causing the client to throw exceptions, ultimately causing IT tests to
> fail.
> IIUC, the minimum period to retry should be bigger than a TarMK flush cycle
> (5 sec).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4882) Bottleneck in the asynchronous persistent cache
[ https://issues.apache.org/jira/browse/OAK-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4882. - Bulk close for 1.5.13 > Bottleneck in the asynchronous persistent cache > --- > > Key: OAK-4882 > URL: https://issues.apache.org/jira/browse/OAK-4882 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, documentmk >Affects Versions: 1.5.10, 1.4.8 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.6, 1.5.13, 1.4.10 > > Attachments: OAK-4882.patch > > > The class responsible for accepting new cache operations which will be > handled asynchronously is > [CacheActionDispatcher|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java]. > In case of a high load, when the queue is full (=1024 entries), the > [add()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L86] > method removes the oldest 256 entries. However, we can't afford losing the > updates (as it may result in having stale entries in the cache), so all the > removed entries are compacted into one big invalidate action. > The compaction action > ([CacheActionDispatcher#cleanTheQueue|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L97]) > still holds the lock taken in add() method, so threads which tries to add > something to the queue have to wait until cleanTheQueue() ends. > Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so > it won't hold the lock for the whole time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4403) Diff traversal in persisted branch commit traversing to unrelated paths
[ https://issues.apache.org/jira/browse/OAK-4403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4403. - Bulk close for 1.5.13 > Diff traversal in persisted branch commit traversing to unrelated paths > --- > > Key: OAK-4403 > URL: https://issues.apache.org/jira/browse/OAK-4403 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: Chetan Mehrotra >Assignee: Marcel Reutegger > Fix For: 1.6, 1.5.13 > > > With DocumentNodeStore when a commit involves a persisted branch the diff > logic traverses to those paths which are not affected by the current commit. > For e.g. in following flow > # Commit C1 (base rev R1) - Starts and modifies paths under /content. The > number of changes done exceed the update.limit and hence the in memory branch > transitions to Persisted state > # Before C1 commits another commit C2 starts and modified paths under /etc > and /var > # C2 commits (before C1). Head revision R2 > # C1 commits and perform the merge. Revision moves to R3 > Now at #4 the merge would trigger a diff which should normally traverse and > perform diff for those paths which are modified by C1. However currently it > seems to also perform diff on all those paths which have been modified after > R1 and R3. In doing so it would traverse the complete sub trees of such > paths. Note that functionally the end result is same just that too many extra > nodes are read which would put load on system > If the number of changes are reduced such that persisted branch is not > created then diff only reads those parts which are modified by the current > commit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4139) Idle session warnings for observation sessions
[
https://issues.apache.org/jira/browse/OAK-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4139.
-
Bulk close for 1.5.13
> Idle session warnings for observation sessions
> --
>
> Key: OAK-4139
> URL: https://issues.apache.org/jira/browse/OAK-4139
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Michael Dürig
>Assignee: Chetan Mehrotra
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4139-v1.patch, OAK-4139-v2.patch
>
>
> Although sessions that register an observation listener Oak still issues idle
> session warnings for them ({{RefreshStrategy.LogOnce}}). For such sessions
> Oak should not log that warning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4995) DocumentS3DataStoreStatsTest.testNoS3BlobStore() does not unregister node store
[ https://issues.apache.org/jira/browse/OAK-4995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4995. - Bulk close for 1.5.13 > DocumentS3DataStoreStatsTest.testNoS3BlobStore() does not unregister node > store > --- > > Key: OAK-4995 > URL: https://issues.apache.org/jira/browse/OAK-4995 > Project: Jackrabbit Oak > Issue Type: Test > Components: it >Affects Versions: 1.5.11 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.13 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5046) Remove the old estimation OSGi setting (compaction.gainThreshold)
[
https://issues.apache.org/jira/browse/OAK-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5046.
-
Bulk close for 1.5.13
> Remove the old estimation OSGi setting (compaction.gainThreshold)
> -
>
> Key: OAK-5046
> URL: https://issues.apache.org/jira/browse/OAK-5046
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.12
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: osgi-config
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-5046-01.patch, OAK-5046-02.patch, OAK-5046-03.patch,
> OAK-5046-04.patch, OAK-5046-05.patch
>
>
> Currently, there are two implementations for finding out the gain in
> repository size after running compaction: the old one,
> {{CompactionGainEstimate}} and the new one, {{SizeDeltaGcEstimation}}.
> Similarly, there are also two configurations for customising them, in
> {{SegmentNodeStoreService}}, {{compaction.gainThreshold}} and
> {{compaction.sizeDeltaEstimation}}.
> At the moment both of them are exposed as OSGi configurations, but only the
> new one should be exposed (e.g. {{compaction.sizeDeltaEstimation}}).
> It must be evaluated whether it makes sense to keep the logic associated with
> the old implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5008) SegmentRevisionGCMBean getLastRepositorySize wrong value
[
https://issues.apache.org/jira/browse/OAK-5008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5008.
-
Bulk close for 1.5.13
> SegmentRevisionGCMBean getLastRepositorySize wrong value
>
>
> Key: OAK-5008
> URL: https://issues.apache.org/jira/browse/OAK-5008
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.6, 1.5.13
>
>
> {{SegmentRevisionGCMBean}} delegates calls to a {{FileStoreGCMonitor}}, but
> the {{getLastRepositorySize}} method calls
> {{fileStoreGCMonitor.getLastReclaimedSize()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4991) Persistent cache should not cache those paths which are covered by DocumentNodeStateCache
[ https://issues.apache.org/jira/browse/OAK-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4991. - Bulk close for 1.5.13 > Persistent cache should not cache those paths which are covered by > DocumentNodeStateCache > - > > Key: OAK-4991 > URL: https://issues.apache.org/jira/browse/OAK-4991 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.6, 1.5.13 > > Attachments: OAK-4991-v1.patch > > > With OAK-4180 its possible to use a SegmentNodeStore as secondary store and > thus like a cache for certain set of path. In such kind of setup persistent > cache should not cache those NodeStates which are covered by > DocumentNodeStateCache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4992) Use the role name as prefix for directory used by SegmentNodeStoreFactory
[
https://issues.apache.org/jira/browse/OAK-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4992.
-
Bulk close for 1.5.13
> Use the role name as prefix for directory used by SegmentNodeStoreFactory
> -
>
> Key: OAK-4992
> URL: https://issues.apache.org/jira/browse/OAK-4992
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar, segmentmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6, 1.5.13
>
>
> Currently SegmentNodeStoreFactory uses a directory named {{segmentstore}}
> under repository home to store the segment files. To allow easier setup where
> multiple NodeStore instance do not overstep on each other this name should be
> prefixed with {{role}}
> Note that code tries to do the same currently with logic below but it ends up
> always creating {{segmentstore}} folder under repository home. As a fix
> {{role}} should be used in {{getDirectory}} method
> {code}
> private File getBaseDirectory() {
> String directory = property(DIRECTORY);
> if (directory != null) {
> return new File(directory);
> }
> if (role == null) {
> return new File("tarmk");
> } else {
> return new File("tarmk-" + role);
> }
> }
> private File getDirectory() {
> return new File(getBaseDirectory(), "segmentstore");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5077) Class "AbstractS3DataStoreService" should be declared abstract
[
https://issues.apache.org/jira/browse/OAK-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5077.
-
Bulk close for 1.5.13
> Class "AbstractS3DataStoreService" should be declared abstract
> --
>
> Key: OAK-5077
> URL: https://issues.apache.org/jira/browse/OAK-5077
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob
>Affects Versions: 1.5.12
>Reporter: Matt Ryan
>Assignee: Amit Jain
> Fix For: 1.6, 1.5.13
>
>
> The class
> {{org.apache.jackrabbit.oak.blob.cloud.s3.AbstractS3DataStoreService}} is not
> declared as an abstract class, but probably should be since the name of the
> class indicates that the intent was that it be abstract.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4919) Better feedback from method invocations on RevisionGCMBean
[
https://issues.apache.org/jira/browse/OAK-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4919.
-
Bulk close for 1.5.13
> Better feedback from method invocations on RevisionGCMBean
> --
>
> Key: OAK-4919
> URL: https://issues.apache.org/jira/browse/OAK-4919
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: monitoring
> Fix For: 1.6, 1.5.13
>
>
> The methods to invoke and cancel revision gc return void. This is by design
> as those calls are asynchronous. The idea is that
> {{RevisionGC.getRevisionGCStatus()}} would return the current status of an
> ongoing gc operation. However, currently that method only returns the status
> of the asynchronous task that was fired off. It should instead be able to
> convey back the real status of the underlying operation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4881) Make merge semaphore in SegmentNodeStore fair by default
[ https://issues.apache.org/jira/browse/OAK-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4881. - Bulk close for 1.5.13 > Make merge semaphore in SegmentNodeStore fair by default > > > Key: OAK-4881 > URL: https://issues.apache.org/jira/browse/OAK-4881 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar, segmentmk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.6, 1.5.13 > > Attachments: OAK-4881-v1.patch > > > Currently the merge semaphore in SegmentNodeStore is by default non fair. > OAK-3588 provided a config option to make it fair. > We should change the default to fair so as to ensure writer threads never get > starved. > Eventually this change would need to be backported to branches. Further going > forward OAK-4122 would replace the lock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5072) ChangeCollectorProvider should enable metatype support
[
https://issues.apache.org/jira/browse/OAK-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5072.
-
Bulk close for 1.5.13
> ChangeCollectorProvider should enable metatype support
> --
>
> Key: OAK-5072
> URL: https://issues.apache.org/jira/browse/OAK-5072
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6, 1.5.13
>
>
> {{ChangeCollectorProvider}} exposes some OSGi config but does not have
> metatype config enable. To allow configuring those config params it should be
> enabled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5065) Make configuration optional for SecondaryStoreCacheService
[
https://issues.apache.org/jira/browse/OAK-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5065.
-
Bulk close for 1.5.13
> Make configuration optional for SecondaryStoreCacheService
> --
>
> Key: OAK-5065
> URL: https://issues.apache.org/jira/browse/OAK-5065
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6, 1.5.13
>
>
> Currently {{SecondaryStoreCacheService}} as configuration policy of required.
> We should remove that requirement and let it get activated with default
> configuration if any {{NodeStoreProvider}} with {{secondary}} is registered.
> So in default setup this component would not get activated. And for a user to
> make use of this feature he would only need to configure a
> {{NodeStoreProvider}} with {{secondary}} role. And then as per requirement
> user can tweak the OSGi config to determine which all paths needs to be part
> of it
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-3796) Prevent blob gc and revision gc from running concurrently
[ https://issues.apache.org/jira/browse/OAK-3796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-3796. - Bulk close for 1.5.13 > Prevent blob gc and revision gc from running concurrently > - > > Key: OAK-3796 > URL: https://issues.apache.org/jira/browse/OAK-3796 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Michael Dürig >Priority: Critical > Labels: datastore, gc, resilience > Fix For: 1.6, 1.5.13 > > > I think we should add some safe guard preventing blob gc and revision gc from > running concurrently. Running those jobs concurrently would only result in > unnecessary contention for IO/CPU and most likely adversely effect the > outcome of both while also impacting overall system performance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5085) XPath: union bugfix
[
https://issues.apache.org/jira/browse/OAK-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5085.
-
Bulk close for 1.5.13
> XPath: union bugfix
> ---
>
> Key: OAK-5085
> URL: https://issues.apache.org/jira/browse/OAK-5085
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.6, 1.5.13
>
>
> The following query does not work:
> {noformat}
> //*[jcr:contains(., 'x')] | //*[jcr:contains(., 'y')])
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5039) Change globbing definition of GlobbingPathFilter
[
https://issues.apache.org/jira/browse/OAK-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5039.
-
Bulk close for 1.5.13
> Change globbing definition of GlobbingPathFilter
>
>
> Key: OAK-5039
> URL: https://issues.apache.org/jira/browse/OAK-5039
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6, 1.5.13
>
>
> In order to satisfy OAK-5019 (and thus SLING-6174) the definition of
> [GlobbingPathFilter|https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html]
> needs to be changed wrt the following:
> * old: {{* matches every path containing a single element}}
> * new: {{* matches character matches zero or more characters of a name
> component without crossing directory boundaries}}
> (and derived definition is hence adjusted accordingly to match above change)
> This change will basically allow to match eg
> * {noformat}*.*{noformat}
> * {noformat}*.html{noformat}
> and not only arbitrarily named path elements.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4999) ISE when starting Oak Console
[
https://issues.apache.org/jira/browse/OAK-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4999.
-
Bulk close for 1.5.13
> ISE when starting Oak Console
> -
>
> Key: OAK-4999
> URL: https://issues.apache.org/jira/browse/OAK-4999
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Affects Versions: Segment Tar 0.0.16
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Fix For: 1.6, 1.5.13
>
>
> {{oak-run console --read-write=true}} throws an {{ISE}}:
> {noformat}
> Exception in thread "main" java.lang.IllegalStateException: Cannot re-use
> builder
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:150)
> at
> org.apache.jackrabbit.oak.segment.file.FileStoreBuilder.build(FileStoreBuilder.java:325)
> at
> org.apache.jackrabbit.oak.console.SegmentTarFixture.create(SegmentTarFixture.java:51)
> at org.apache.jackrabbit.oak.console.Console.main(Console.java:139)
> at
> org.apache.jackrabbit.oak.run.ConsoleCommand.execute(ConsoleCommand.java:26)
> at org.apache.jackrabbit.oak.run.Mode.execute(Mode.java:63)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4966) Re-introduce a blocker for compaction based on available heap
[
https://issues.apache.org/jira/browse/OAK-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4966.
-
Bulk close for 1.5.13
> Re-introduce a blocker for compaction based on available heap
> -
>
> Key: OAK-4966
> URL: https://issues.apache.org/jira/browse/OAK-4966
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4966-jmx-notification-v2.patch,
> OAK-4966-jmx-notification.patch, OAK-4966.patch
>
>
> As seen in a local test, running compaction on a tight heap can lead to
> OOMEs. There used to be a best effort barrier against this situation 'not
> enough heap for compaction', but we removed it with the compaction maps.
> I think it makes sense to add it again based on the max size of some of the
> caches: segment cache {{256MB}} by default [0] and some writer caches which
> can go up to {{2GB}} all combined [1] and probably others I missed.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentCache.java#L48
> [1]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/WriterCacheManager.java#L50
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5023) add applyNoteTypeOnSelf property to OakEventFilter
[
https://issues.apache.org/jira/browse/OAK-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5023.
-
Bulk close for 1.5.13
> add applyNoteTypeOnSelf property to OakEventFilter
> --
>
> Key: OAK-5023
> URL: https://issues.apache.org/jira/browse/OAK-5023
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6, 1.5.13
>
>
> (Originally reported as JCR-4048, but moved to Oak as a result of introducing
> the OakEventFilter in OAK-5013. From the original description: )
> There seems to be a rather frequent use case of observation around which
> would like to create a filter on a _child_ rather than on a _parent_:
> consider the case when you'd like to filter for the removal of a node that
> has a particular nodeType. This can't be achieved atm as the nodeType is
> applicable to the parent of the node that changes, not the node itself (ie
> child).
> Therefore suggesting the introduction of a flag similar to the following:
> {code}
> boolean applyOnOwnNode;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
[
https://issues.apache.org/jira/browse/OAK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5055.
-
Bulk close for 1.5.13
> o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
>
>
> Key: OAK-5055
> URL: https://issues.apache.org/jira/browse/OAK-5055
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-5055.patch, OAK-5055.patch, OAK-5055.patch
>
>
> According to the API [0], the method {{RevisionGC#startRevisionGC}} should
> {code}
> @return the status of the operation right after it was initiated
> {code}
> However, it does return {{succeeded}} on every call, see [1].
> I believe this should either compute the actual state, or return
> {{initiated}} or {{running}}.
> Same applies for {{cancelRevisionGC}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
> [1]
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5031) Log configuration deprecation messages at WARN level
[
https://issues.apache.org/jira/browse/OAK-5031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5031.
-
Bulk close for 1.5.13
> Log configuration deprecation messages at WARN level
>
>
> Key: OAK-5031
> URL: https://issues.apache.org/jira/browse/OAK-5031
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-5031.patch
>
>
> The {{StandbyStoreServiceDeprecationError}} and
> {{SegmentNodeStoreServiceDeprecationError}} detect the presence of deprecated
> configurations and log at {{ERROR}} level a warning message.
> The level should be revised to {{WARN}} since having a deprecated
> configuration does not break the instance (it's not an error).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4993) Report plan when QueryTest.nodeType() fails
[ https://issues.apache.org/jira/browse/OAK-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4993. - Bulk close for 1.5.13 > Report plan when QueryTest.nodeType() fails > --- > > Key: OAK-4993 > URL: https://issues.apache.org/jira/browse/OAK-4993 > Project: Jackrabbit Oak > Issue Type: Test > Components: jcr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.13 > > > Travis recently showed a QueryTest.nodeType() failure. Unfortunately the test > does not print the plan chosen by Oak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5066) Provide a config option to disable lease check at DocumentNodeStoreService level
[
https://issues.apache.org/jira/browse/OAK-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5066.
-
Bulk close for 1.5.13
> Provide a config option to disable lease check at DocumentNodeStoreService
> level
>
>
> Key: OAK-5066
> URL: https://issues.apache.org/jira/browse/OAK-5066
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-5066-v1.patch
>
>
> Currently its not possible to disable lease check complete at
> DocumentNodeStoreService. System property
> {{oak.documentMK.disableLeaseCheck}} only disables some logic in
> ClusterNodeInfo but lease check wrapper still gets used.
> We should modify the logic also avoid wrapping if this property is enabled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5075) Refactor IndexCopier to make it more modular
[
https://issues.apache.org/jira/browse/OAK-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5075.
-
Bulk close for 1.5.13
> Refactor IndexCopier to make it more modular
>
>
> Key: OAK-5075
> URL: https://issues.apache.org/jira/browse/OAK-5075
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6, 1.5.13
>
>
> {{IndexCopier}} class in oak-lucene has many inner classes which can be moved
> out to make code simpler. This would simplify further addition of features to
> this class
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5029) Use head GC generation number to trigger cleanup on standby instance
[
https://issues.apache.org/jira/browse/OAK-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5029.
-
Bulk close for 1.5.13
> Use head GC generation number to trigger cleanup on standby instance
> -
>
> Key: OAK-5029
> URL: https://issues.apache.org/jira/browse/OAK-5029
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Francesco Mari
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-5029.patch
>
>
> With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
> instance could be determined by the GC generation number of the head which is
> bound to increase every time a cleanup is ran.
> {code}
> fileStore.getHead().getRecordId().getSegment().getGcGeneration();
> {code}
> The current trigger mechanism consists of detecting a 25% size increase over
> a client cycle (typ. 5 sec).
> This would be dropped in favor of the new detection mechanism.
> The auto-compaction mode would remain configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5002) NPE when creating read only store
[
https://issues.apache.org/jira/browse/OAK-5002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5002.
-
Bulk close for 1.5.13
> NPE when creating read only store
> -
>
> Key: OAK-5002
> URL: https://issues.apache.org/jira/browse/OAK-5002
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK_5002.patch
>
>
> Using
> {{org.apache.jackrabbit.oak.segment.SegmentNodeStoreBuilders#builder(org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore)}}
> to create a read only store results in a NPE:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:192)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeStore.builder(SegmentNodeStore.java:148)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreBuilders.builder(SegmentNodeStoreBuilders.java:69)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-2072) Lucene: inconsistent usage of the config option "persistence"
[ https://issues.apache.org/jira/browse/OAK-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-2072. - Bulk close for 1.5.13 > Lucene: inconsistent usage of the config option "persistence" > - > > Key: OAK-2072 > URL: https://issues.apache.org/jira/browse/OAK-2072 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.6, 1.5.13 > > > The Lucene index reader uses the configuration property "persistence", but > the editor (the component updating the index) does not. That leads to very > strange behavior if the property is missing, but the property "file" is set: > the reader would try to read from the file system, but those files are not > updated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4396) HttpStore.containsSegment throws SNFE instead of returning false for non existing segments
[
https://issues.apache.org/jira/browse/OAK-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4396.
-
Bulk close for 1.5.13
> HttpStore.containsSegment throws SNFE instead of returning false for non
> existing segments
> --
>
> Key: OAK-4396
> URL: https://issues.apache.org/jira/browse/OAK-4396
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Minor
> Fix For: 1.6, 1.5.13
>
>
> That method tries to check existence of a segment by checking the return
> value of {{readSegment}} for {{null}}. However, this method never returns
> {{null}} but throws a {{SNFE}} for non existing segments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-3404) Path to logical store mapping
[
https://issues.apache.org/jira/browse/OAK-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-3404.
-
Bulk close for 1.5.13
> Path to logical store mapping
> -
>
> Key: OAK-3404
> URL: https://issues.apache.org/jira/browse/OAK-3404
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-3404-v1.patch, ismounted.patch, mounts-v2.patch,
> mounts.patch
>
>
> Need to provide an API {{MountInfoProvider}} which would be responsible for
> mapping a given path to logical store name
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
