[jira] [Commented] (OAK-6911) Provide a way to tune inline size while storing binaries
[ https://issues.apache.org/jira/browse/OAK-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241485#comment-16241485 ] Chetan Mehrotra commented on OAK-6911: -- It may be better to just disable the default inlining if any BlobStore is configured. This allows tuning the inlining config at one place i.e. in BlobStore config. If someone want to use old behaviour he can just set the maxInlineSize of BlobStore to 16KB Looking at flow I think such a change should not impact existing content i.e. no impact on upgrade as only new binaries would be subjected to this limit. Old inlined binaries can still be read as is and no migration would be required. [~mduerig] Thoughts? > Provide a way to tune inline size while storing binaries > > > Key: OAK-6911 > URL: https://issues.apache.org/jira/browse/OAK-6911 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Chetan Mehrotra > Fix For: 1.8 > > > SegmentNodeStore currently inlines binaries of size less that 16KB > (Segment.MEDIUM_LIMIT) even if external BlobStore is configured. > Due to this behaviour quite a bit of segment tar storage consist of blob > data. In one setup out of 370 GB segmentstore size 290GB is due to inlined > binary. If most of this binary content is moved to BlobStore then it would > allow same repository to work better in lesser RAM > So it would be useful if some way is provided to disable this default > behaviour and let BlobStore take control of inline size i.e. in presence of > BlobStore no inlining is attempted by SegmentWriter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6911) Provide a way to tune inline size while storing binaries
Chetan Mehrotra created OAK-6911: Summary: Provide a way to tune inline size while storing binaries Key: OAK-6911 URL: https://issues.apache.org/jira/browse/OAK-6911 Project: Jackrabbit Oak Issue Type: Improvement Components: segment-tar Reporter: Chetan Mehrotra Fix For: 1.8 SegmentNodeStore currently inlines binaries of size less that 16KB (Segment.MEDIUM_LIMIT) even if external BlobStore is configured. Due to this behaviour quite a bit of segment tar storage consist of blob data. In one setup out of 370 GB segmentstore size 290GB is due to inlined binary. If most of this binary content is moved to BlobStore then it would allow same repository to work better in lesser RAM So it would be useful if some way is provided to disable this default behaviour and let BlobStore take control of inline size i.e. in presence of BlobStore no inlining is attempted by SegmentWriter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6862) Active deletion of Lucene binaries: JMX bean, and ability to disable automatic
[ https://issues.apache.org/jira/browse/OAK-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241357#comment-16241357 ] Vikas Saurabh commented on OAK-6862: Have pushed a rough change to https://github.com/catholicon/jackrabbit-oak/tree/OAK-6862-active-deletion-mbean. > Active deletion of Lucene binaries: JMX bean, and ability to disable automatic > -- > > Key: OAK-6862 > URL: https://issues.apache.org/jira/browse/OAK-6862 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Thomas Mueller >Assignee: Vikas Saurabh > Fix For: 1.8 > > > Currently, active deletion of Lucene binaries happens every 12 hours, and 12 > hours after starting the Oak Lucene bundle. > However, it would be better if active deletion can be run manually (using > JMX), and not automatic, (so it doesn't run at the same time as other tasks, > and can be scheduled). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OAK-6862) Active deletion of Lucene binaries: JMX bean, and ability to disable automatic
[ https://issues.apache.org/jira/browse/OAK-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh reassigned OAK-6862: -- Assignee: Vikas Saurabh > Active deletion of Lucene binaries: JMX bean, and ability to disable automatic > -- > > Key: OAK-6862 > URL: https://issues.apache.org/jira/browse/OAK-6862 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Thomas Mueller >Assignee: Vikas Saurabh > Fix For: 1.8 > > > Currently, active deletion of Lucene binaries happens every 12 hours, and 12 > hours after starting the Oak Lucene bundle. > However, it would be better if active deletion can be run manually (using > JMX), and not automatic, (so it doesn't run at the same time as other tasks, > and can be scheduled). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6879) Active deletion should expose more configurability to allow controlling its execution and how much load it puts
[ https://issues.apache.org/jira/browse/OAK-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh resolved OAK-6879. Resolution: Duplicate Fix Version/s: (was: 1.8) > Active deletion should expose more configurability to allow controlling its > execution and how much load it puts > --- > > Key: OAK-6879 > URL: https://issues.apache.org/jira/browse/OAK-6879 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh > > Currently purge cycle for active collector is scheduled every 12 hours since > oak-lucene comes up. > From maintenance and system stability pov, it would be useful to at have > some controls. Some examples: > * throttle knob - max rate at which blobs are purged > * maybe some execution window - that won't bode well with current default of > scheduled execution though - it would most likely require activation by > external call ... jmx or otherwise > * cancel a run -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6894) org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments failing
[
https://issues.apache.org/jira/browse/OAK-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240975#comment-16240975
]
Julian Reschke commented on OAK-6894:
-
LGTM so far.
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments
> failing
> -
>
> Key: OAK-6894
> URL: https://issues.apache.org/jira/browse/OAK-6894
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Blocker
> Labels: compaction, gc
> Fix For: 1.8, 1.7.11
>
> Attachments:
> TEST-org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.xml,
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT-output.txt,
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.txt
>
>
> {noformat}
> [ERROR]
> offRCUpgradesSegments(org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT)
> Time elapsed: 7.446 s <<< FAILURE!
> java.lang.AssertionError: Segment version mismatch. Expected V_13, found V_12
> expected: but was:
> at
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.checkSegmentVersion(UpgradeIT.java:141)
> at
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments(UpgradeIT.java:107)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6178) Test failure: DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources
[
https://issues.apache.org/jira/browse/OAK-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6178:
---
Fix Version/s: (was: 1.8)
> Test failure: DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources
> --
>
> Key: OAK-6178
> URL: https://issues.apache.org/jira/browse/OAK-6178
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, rdbmk
>Reporter: Hudson
> Labels: CI, jenkins, test-failure
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #259 has failed.
> First failed run: [Jackrabbit Oak
> #259|https://builds.apache.org/job/Jackrabbit%20Oak/259/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/259/console]
> {code}
> Error Message
> Service of type interface org.apache.jackrabbit.oak.spi.state.NodeStore was
> found. Expression: (sr == null). Values: sr =
> [org.apache.jackrabbit.oak.spi.state.NodeStore,
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore,
> org.apache.jackrabbit.oak.spi.state.Clusterable]
> Stacktrace
> java.lang.AssertionError: Service of type interface
> org.apache.jackrabbit.oak.spi.state.NodeStore was found. Expression: (sr ==
> null). Values: sr = [org.apache.jackrabbit.oak.spi.state.NodeStore,
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore,
> org.apache.jackrabbit.oak.spi.state.Clusterable]
> at
> org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources(DocumentNodeStoreConfigTest.groovy:110)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-5776) Build failure: Cannot create directory : Filename too long
[ https://issues.apache.org/jira/browse/OAK-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-5776: --- Fix Version/s: 1.8 > Build failure: Cannot create directory : Filename too long > -- > > Key: OAK-5776 > URL: https://issues.apache.org/jira/browse/OAK-5776 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > Labels: CI, build-failure, windows > Fix For: 1.8 > > > Jenkins Windows CI failure: https://builds.apache.org/job/Oak-Win/ > The build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) > 64-bit Windows only,nsfixtures=DOCUMENT_NS,profile=integrationTesting #473 > has failed. > First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited > security) 64-bit Windows > only,nsfixtures=DOCUMENT_NS,profile=integrationTesting > #473|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_NS,profile=integrationTesting/473/] > [console > log|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_NS,profile=integrationTesting/473/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6178) Test failure: DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources
[
https://issues.apache.org/jira/browse/OAK-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6178:
---
Fix Version/s: 1.8
> Test failure: DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources
> --
>
> Key: OAK-6178
> URL: https://issues.apache.org/jira/browse/OAK-6178
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, rdbmk
>Reporter: Hudson
> Labels: CI, jenkins, test-failure
> Fix For: 1.8
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #259 has failed.
> First failed run: [Jackrabbit Oak
> #259|https://builds.apache.org/job/Jackrabbit%20Oak/259/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/259/console]
> {code}
> Error Message
> Service of type interface org.apache.jackrabbit.oak.spi.state.NodeStore was
> found. Expression: (sr == null). Values: sr =
> [org.apache.jackrabbit.oak.spi.state.NodeStore,
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore,
> org.apache.jackrabbit.oak.spi.state.Clusterable]
> Stacktrace
> java.lang.AssertionError: Service of type interface
> org.apache.jackrabbit.oak.spi.state.NodeStore was found. Expression: (sr ==
> null). Values: sr = [org.apache.jackrabbit.oak.spi.state.NodeStore,
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore,
> org.apache.jackrabbit.oak.spi.state.Clusterable]
> at
> org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources(DocumentNodeStoreConfigTest.groovy:110)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6788) java.io.IOException: Backing channel 'ubuntu-1' is disconnected.
[ https://issues.apache.org/jira/browse/OAK-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6788: --- Fix Version/s: 1.8 > java.io.IOException: Backing channel 'ubuntu-1' is disconnected. > > > Key: OAK-6788 > URL: https://issues.apache.org/jira/browse/OAK-6788 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > Fix For: 1.8 > > > No description is provided > The build Jackrabbit Oak #842 has failed. > First failed run: [Jackrabbit Oak > #842|https://builds.apache.org/job/Jackrabbit%20Oak/842/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/842/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6900) Build Jackrabbit Oak #940 failed
[ https://issues.apache.org/jira/browse/OAK-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6900: --- Fix Version/s: 1.8 > Build Jackrabbit Oak #940 failed > > > Key: OAK-6900 > URL: https://issues.apache.org/jira/browse/OAK-6900 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Trivial > Fix For: 1.8 > > > No description is provided > The build Jackrabbit Oak #940 has failed. > First failed run: [Jackrabbit Oak > #940|https://builds.apache.org/job/Jackrabbit%20Oak/940/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/940/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6814) Build Jackrabbit Oak #861 failed
[ https://issues.apache.org/jira/browse/OAK-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6814: --- Fix Version/s: 1.8 > Build Jackrabbit Oak #861 failed > > > Key: OAK-6814 > URL: https://issues.apache.org/jira/browse/OAK-6814 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > Fix For: 1.8 > > > No description is provided > The build Jackrabbit Oak #861 has failed. > First failed run: [Jackrabbit Oak > #861|https://builds.apache.org/job/Jackrabbit%20Oak/861/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/861/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6804) Build Jackrabbit Oak #854 failed
[ https://issues.apache.org/jira/browse/OAK-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6804: --- Fix Version/s: 1.8 > Build Jackrabbit Oak #854 failed > > > Key: OAK-6804 > URL: https://issues.apache.org/jira/browse/OAK-6804 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > Fix For: 1.8 > > > No description is provided > The build Jackrabbit Oak #854 has failed. > First failed run: [Jackrabbit Oak > #854|https://builds.apache.org/job/Jackrabbit%20Oak/854/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/854/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6795) Build Jackrabbit Oak #844 failed
[ https://issues.apache.org/jira/browse/OAK-6795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6795: --- Fix Version/s: 1.8 > Build Jackrabbit Oak #844 failed > > > Key: OAK-6795 > URL: https://issues.apache.org/jira/browse/OAK-6795 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > Fix For: 1.8 > > > No description is provided > The build Jackrabbit Oak #844 has failed. > First failed run: [Jackrabbit Oak > #844|https://builds.apache.org/job/Jackrabbit%20Oak/844/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/844/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6900) Build Jackrabbit Oak #940 failed
[ https://issues.apache.org/jira/browse/OAK-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240745#comment-16240745 ] Hudson commented on OAK-6900: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #949|https://builds.apache.org/job/Jackrabbit%20Oak/949/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/949/console] > Build Jackrabbit Oak #940 failed > > > Key: OAK-6900 > URL: https://issues.apache.org/jira/browse/OAK-6900 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Trivial > > No description is provided > The build Jackrabbit Oak #940 has failed. > First failed run: [Jackrabbit Oak > #940|https://builds.apache.org/job/Jackrabbit%20Oak/940/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/940/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6909) FileStore.compact does not persist compacted head to journal
[
https://issues.apache.org/jira/browse/OAK-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-6909.
Resolution: Fixed
Fix Version/s: (was: 1.7.12)
1.7.11
Fixed at http://svn.apache.org/viewvc?rev=1814430=rev
> FileStore.compact does not persist compacted head to journal
>
>
> Key: OAK-6909
> URL: https://issues.apache.org/jira/browse/OAK-6909
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction, gc
> Fix For: 1.8, 1.7.11
>
>
> When {{FileStore.compact()}} returns the {{journal.log}} does not necessarily
> contain the head created by the compactor. This can lead to problems
> downstream like e.g. in OAK-6894 where the compactor tool wrote the wrong
> (i.e. uncompacted) head to the {{journal.log}}.
> Proposed fix is to call on of the {{FileStore.flush()}} methods after
> compaction and add a test case that verifies the {{journal.log}} contains the
> correct head state.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-6883) The compaction estimator should take the compaction type (tail vs. full) into consideration
[ https://issues.apache.org/jira/browse/OAK-6883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari resolved OAK-6883. - Resolution: Fixed Fix Version/s: (was: 1.7.12) 1.7.11 Fixed at r1814429. > The compaction estimator should take the compaction type (tail vs. full) into > consideration > --- > > Key: OAK-6883 > URL: https://issues.apache.org/jira/browse/OAK-6883 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Michael Dürig >Assignee: Francesco Mari >Priority: Critical > Labels: compaction, gc > Fix For: 1.8, 1.7.11 > > > Currently the compaction estimator unconditionally looks at the growth of the > repository since the last compaction run. This turn out to be not optimal > when interleaving tail and full compaction. It would be better to have the > estimator look at the growth of the repository since last full compaction > when running full compaction. > cc [~frm] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6910) Offline compaction should not use mmap on Windows
[ https://issues.apache.org/jira/browse/OAK-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6910: --- Fix Version/s: (was: 1.7.11) 1.7.12 1.8 > Offline compaction should not use mmap on Windows > - > > Key: OAK-6910 > URL: https://issues.apache.org/jira/browse/OAK-6910 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: compaction, gc, tooling > Fix For: 1.8, 1.7.12 > > > The offline compaction tool should do an effort to detect whether it is being > run on windows and disable memory mapping if so. Rational: with memory > mapping enabled it might fail to remove the old tar files (see OAK-4274 and > [JDK-4724038|http://bugs.java.com/view_bug.do?bug_id=4724038]). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6909) FileStore.compact does not persist compacted head to journal
[
https://issues.apache.org/jira/browse/OAK-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6909:
---
Fix Version/s: (was: 1.7.11)
1.7.12
1.8
> FileStore.compact does not persist compacted head to journal
>
>
> Key: OAK-6909
> URL: https://issues.apache.org/jira/browse/OAK-6909
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction, gc
> Fix For: 1.8, 1.7.12
>
>
> When {{FileStore.compact()}} returns the {{journal.log}} does not necessarily
> contain the head created by the compactor. This can lead to problems
> downstream like e.g. in OAK-6894 where the compactor tool wrote the wrong
> (i.e. uncompacted) head to the {{journal.log}}.
> Proposed fix is to call on of the {{FileStore.flush()}} methods after
> compaction and add a test case that verifies the {{journal.log}} contains the
> correct head state.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6886) OffRC always logs 0 for the number of compacted nodes in gc.log
[
https://issues.apache.org/jira/browse/OAK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240534#comment-16240534
]
Michael Dürig commented on OAK-6886:
Making OAK-6909 and OAK-6910 blockers for this issue as the initial patch is
IMO still the right approach but would need these issues fixed as a
prerequisite.
> OffRC always logs 0 for the number of compacted nodes in gc.log
> ---
>
> Key: OAK-6886
> URL: https://issues.apache.org/jira/browse/OAK-6886
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction, gc
> Fix For: 1.8, 1.7.12
>
>
> After an offline compaction the {{gc.log}} always contains 0 for the number
> of compacted nodes. This is caused by
> {{org.apache.jackrabbit.oak.segment.tool.Compact.compact()}} instantiating a
> new {{FileStore}} to run cleanup. That file store has new {{GCMonitor}}
> instance, which did no see any of the nodes written by the compaction that
> was run on the previous {{FileStore}} instance.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6910) Offline compaction should not use mmap on Windows
Michael Dürig created OAK-6910: -- Summary: Offline compaction should not use mmap on Windows Key: OAK-6910 URL: https://issues.apache.org/jira/browse/OAK-6910 Project: Jackrabbit Oak Issue Type: Improvement Components: segment-tar Reporter: Michael Dürig Assignee: Michael Dürig Fix For: 1.7.11 The offline compaction tool should do an effort to detect whether it is being run on windows and disable memory mapping if so. Rational: with memory mapping enabled it might fail to remove the old tar files (see OAK-4274 and [JDK-4724038|http://bugs.java.com/view_bug.do?bug_id=4724038]). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6909) FileStore.compact does not persist compacted head to journal
Michael Dürig created OAK-6909:
--
Summary: FileStore.compact does not persist compacted head to
journal
Key: OAK-6909
URL: https://issues.apache.org/jira/browse/OAK-6909
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-tar
Reporter: Michael Dürig
Assignee: Michael Dürig
Fix For: 1.7.11
When {{FileStore.compact()}} returns the {{journal.log}} does not necessarily
contain the head created by the compactor. This can lead to problems downstream
like e.g. in OAK-6894 where the compactor tool wrote the wrong (i.e.
uncompacted) head to the {{journal.log}}.
Proposed fix is to call on of the {{FileStore.flush()}} methods after
compaction and add a test case that verifies the {{journal.log}} contains the
correct head state.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6908) Change RDB default scheduling on RDB
Marcel Reutegger created OAK-6908: - Summary: Change RDB default scheduling on RDB Key: OAK-6908 URL: https://issues.apache.org/jira/browse/OAK-6908 Project: Jackrabbit Oak Issue Type: Improvement Components: documentmk Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor Fix For: 1.7.11 The Revision GC schedule on RDB should be changed to disabled. This means the behaviour on RDB would be the same as in previous releases. The default schedule on RDB should be re-considered once Continuous RGC is ready on RDB. At which point it would probably be the same schedule as on MongoDB. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6894) org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments failing
[
https://issues.apache.org/jira/browse/OAK-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240505#comment-16240505
]
Michael Dürig commented on OAK-6894:
Apparently this is a regression introduced with OAK-6886. I reopenend that
issue, reverted the respective commit, re-enabled the test and re-tested on my
end. [~reschke], could you check whether this fixed things on your end?
Revision: http://svn.apache.org/viewvc?rev=1814426=rev If so we can
resolve this issue as fixed.
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments
> failing
> -
>
> Key: OAK-6894
> URL: https://issues.apache.org/jira/browse/OAK-6894
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Julian Reschke
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: compaction, gc
> Fix For: 1.8, 1.7.11
>
> Attachments:
> TEST-org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.xml,
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT-output.txt,
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.txt
>
>
> {noformat}
> [ERROR]
> offRCUpgradesSegments(org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT)
> Time elapsed: 7.446 s <<< FAILURE!
> java.lang.AssertionError: Segment version mismatch. Expected V_13, found V_12
> expected: but was:
> at
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.checkSegmentVersion(UpgradeIT.java:141)
> at
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments(UpgradeIT.java:107)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (OAK-6894) org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments failing
[
https://issues.apache.org/jira/browse/OAK-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reassigned OAK-6894:
--
Assignee: Julian Reschke (was: Michael Dürig)
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments
> failing
> -
>
> Key: OAK-6894
> URL: https://issues.apache.org/jira/browse/OAK-6894
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Blocker
> Labels: compaction, gc
> Fix For: 1.8, 1.7.11
>
> Attachments:
> TEST-org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.xml,
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT-output.txt,
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.txt
>
>
> {noformat}
> [ERROR]
> offRCUpgradesSegments(org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT)
> Time elapsed: 7.446 s <<< FAILURE!
> java.lang.AssertionError: Segment version mismatch. Expected V_13, found V_12
> expected: but was:
> at
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.checkSegmentVersion(UpgradeIT.java:141)
> at
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments(UpgradeIT.java:107)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6886) OffRC always logs 0 for the number of compacted nodes in gc.log
[
https://issues.apache.org/jira/browse/OAK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6886:
---
Fix Version/s: (was: 1.7.11)
1.7.12
> OffRC always logs 0 for the number of compacted nodes in gc.log
> ---
>
> Key: OAK-6886
> URL: https://issues.apache.org/jira/browse/OAK-6886
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction, gc
> Fix For: 1.8, 1.7.12
>
>
> After an offline compaction the {{gc.log}} always contains 0 for the number
> of compacted nodes. This is caused by
> {{org.apache.jackrabbit.oak.segment.tool.Compact.compact()}} instantiating a
> new {{FileStore}} to run cleanup. That file store has new {{GCMonitor}}
> instance, which did no see any of the nodes written by the compaction that
> was run on the previous {{FileStore}} instance.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (OAK-6886) OffRC always logs 0 for the number of compacted nodes in gc.log
[
https://issues.apache.org/jira/browse/OAK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reopened OAK-6886:
Reopening as these changes seem to have cause the regression observed in
OAK-6894
> OffRC always logs 0 for the number of compacted nodes in gc.log
> ---
>
> Key: OAK-6886
> URL: https://issues.apache.org/jira/browse/OAK-6886
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction, gc
> Fix For: 1.8, 1.7.12
>
>
> After an offline compaction the {{gc.log}} always contains 0 for the number
> of compacted nodes. This is caused by
> {{org.apache.jackrabbit.oak.segment.tool.Compact.compact()}} instantiating a
> new {{FileStore}} to run cleanup. That file store has new {{GCMonitor}}
> instance, which did no see any of the nodes written by the compaction that
> was run on the previous {{FileStore}} instance.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-5361) switch to stable release of org.apache.directory.api.api-all
[ https://issues.apache.org/jira/browse/OAK-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5361: Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 candidate_oak_1_6 patch-available (was: ) > switch to stable release of org.apache.directory.api.api-all > > > Key: OAK-5361 > URL: https://issues.apache.org/jira/browse/OAK-5361 > Project: Jackrabbit Oak > Issue Type: Task > Components: auth-ldap >Reporter: Julian Reschke >Assignee: Manfred Baedke > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, > candidate_oak_1_6, patch-available > Fix For: 1.8 > > Attachments: OAK-5361.diff > > > We currently use a release candidate, but could switch to 1.0.0 (see > https://mvnrepository.com/artifact/org.apache.directory.api/api-all) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5361) switch to stable release of org.apache.directory.api.api-all
[ https://issues.apache.org/jira/browse/OAK-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5361: Attachment: OAK-5361.diff Upgrades three dependencies; seems to work. [~baedke] - can you review and commit? > switch to stable release of org.apache.directory.api.api-all > > > Key: OAK-5361 > URL: https://issues.apache.org/jira/browse/OAK-5361 > Project: Jackrabbit Oak > Issue Type: Task > Components: auth-ldap >Reporter: Julian Reschke > Fix For: 1.8 > > Attachments: OAK-5361.diff > > > We currently use a release candidate, but could switch to 1.0.0 (see > https://mvnrepository.com/artifact/org.apache.directory.api/api-all) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OAK-5361) switch to stable release of org.apache.directory.api.api-all
[ https://issues.apache.org/jira/browse/OAK-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke reassigned OAK-5361: --- Assignee: Manfred Baedke > switch to stable release of org.apache.directory.api.api-all > > > Key: OAK-5361 > URL: https://issues.apache.org/jira/browse/OAK-5361 > Project: Jackrabbit Oak > Issue Type: Task > Components: auth-ldap >Reporter: Julian Reschke >Assignee: Manfred Baedke > Fix For: 1.8 > > Attachments: OAK-5361.diff > > > We currently use a release candidate, but could switch to 1.0.0 (see > https://mvnrepository.com/artifact/org.apache.directory.api/api-all) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5361) switch to stable release of org.apache.directory.api.api-all
[ https://issues.apache.org/jira/browse/OAK-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5361: Summary: switch to stable release of org.apache.directory.api.api-all (was: switch to stable release of org.apache.directory.api.api-all once available) > switch to stable release of org.apache.directory.api.api-all > > > Key: OAK-5361 > URL: https://issues.apache.org/jira/browse/OAK-5361 > Project: Jackrabbit Oak > Issue Type: Task > Components: auth-ldap >Reporter: Julian Reschke > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5361) switch to stable release of org.apache.directory.api.api-all
[ https://issues.apache.org/jira/browse/OAK-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-5361: Description: We currently use a release candidate, but could switch to 1.0.0 (see https://mvnrepository.com/artifact/org.apache.directory.api/api-all) > switch to stable release of org.apache.directory.api.api-all > > > Key: OAK-5361 > URL: https://issues.apache.org/jira/browse/OAK-5361 > Project: Jackrabbit Oak > Issue Type: Task > Components: auth-ldap >Reporter: Julian Reschke > Fix For: 1.8 > > > We currently use a release candidate, but could switch to 1.0.0 (see > https://mvnrepository.com/artifact/org.apache.directory.api/api-all) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6900) Build Jackrabbit Oak #940 failed
[ https://issues.apache.org/jira/browse/OAK-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240380#comment-16240380 ] Hudson commented on OAK-6900: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #947|https://builds.apache.org/job/Jackrabbit%20Oak/947/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/947/console] > Build Jackrabbit Oak #940 failed > > > Key: OAK-6900 > URL: https://issues.apache.org/jira/browse/OAK-6900 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Trivial > > No description is provided > The build Jackrabbit Oak #940 has failed. > First failed run: [Jackrabbit Oak > #940|https://builds.apache.org/job/Jackrabbit%20Oak/940/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/940/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6906) RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches compatible with Java 7)
[ https://issues.apache.org/jira/browse/OAK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240191#comment-16240191 ] Julian Reschke edited comment on OAK-6906 at 11/6/17 2:30 PM: -- trunk: [r1814397|http://svn.apache.org/r1814397] 1.6: [r1814405|http://svn.apache.org/r1814405] 1.4: [r1814415|http://svn.apache.org/r1814415] was (Author: reschke): trunk: [r1814397|http://svn.apache.org/r1814397] 1.6: [r1814405|http://svn.apache.org/r1814405] > RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches > compatible with Java 7) > - > > Key: OAK-6906 > URL: https://issues.apache.org/jira/browse/OAK-6906 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.8, 1.4.19, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6906) RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches compatible with Java 7)
[ https://issues.apache.org/jira/browse/OAK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6906: Fix Version/s: 1.4.19 > RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches > compatible with Java 7) > - > > Key: OAK-6906 > URL: https://issues.apache.org/jira/browse/OAK-6906 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.8, 1.4.19, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6906) RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches compatible with Java 7)
[ https://issues.apache.org/jira/browse/OAK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6906: Labels: (was: candidate_oak_1_4) > RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches > compatible with Java 7) > - > > Key: OAK-6906 > URL: https://issues.apache.org/jira/browse/OAK-6906 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.8, 1.4.19, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6894) org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments failing
[
https://issues.apache.org/jira/browse/OAK-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16237848#comment-16237848
]
Julian Reschke edited comment on OAK-6894 at 11/6/17 2:27 PM:
--
Test keeps failing randomly. Can we please disable it for now?
EDIT: test disabled in 1814414
was (Author: reschke):
Test keeps failing randomly. Can we please disable it for now?
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments
> failing
> -
>
> Key: OAK-6894
> URL: https://issues.apache.org/jira/browse/OAK-6894
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Julian Reschke
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: compaction, gc
> Fix For: 1.8, 1.7.11
>
> Attachments:
> TEST-org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.xml,
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT-output.txt,
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.txt
>
>
> {noformat}
> [ERROR]
> offRCUpgradesSegments(org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT)
> Time elapsed: 7.446 s <<< FAILURE!
> java.lang.AssertionError: Segment version mismatch. Expected V_13, found V_12
> expected: but was:
> at
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.checkSegmentVersion(UpgradeIT.java:141)
> at
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments(UpgradeIT.java:107)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OAK-6907) RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions
[ https://issues.apache.org/jira/browse/OAK-6907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240313#comment-16240313 ] Julian Reschke edited comment on OAK-6907 at 11/6/17 2:02 PM: -- trunk: [r1814407|http://svn.apache.org/r1814407] 1.6: [r1814409|http://svn.apache.org/r1814409] was (Author: reschke): trunk: [r1814407|http://svn.apache.org/r1814407] > RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions > - > > Key: OAK-6907 > URL: https://issues.apache.org/jira/browse/OAK-6907 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.8, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6907) RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions
[ https://issues.apache.org/jira/browse/OAK-6907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6907: Fix Version/s: 1.6.7 > RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions > - > > Key: OAK-6907 > URL: https://issues.apache.org/jira/browse/OAK-6907 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.8, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6907) RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions
[ https://issues.apache.org/jira/browse/OAK-6907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6907: Labels: (was: candidate_oak_1_6) > RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions > - > > Key: OAK-6907 > URL: https://issues.apache.org/jira/browse/OAK-6907 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.8, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6907) RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions
[ https://issues.apache.org/jira/browse/OAK-6907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240313#comment-16240313 ] Julian Reschke commented on OAK-6907: - trunk: [r1814407|http://svn.apache.org/r1814407] > RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions > - > > Key: OAK-6907 > URL: https://issues.apache.org/jira/browse/OAK-6907 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_6 > Fix For: 1.8, 1.7.11 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6907) RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions
[ https://issues.apache.org/jira/browse/OAK-6907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-6907. - Resolution: Fixed Fix Version/s: 1.7.11 > RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions > - > > Key: OAK-6907 > URL: https://issues.apache.org/jira/browse/OAK-6907 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_6 > Fix For: 1.8, 1.7.11 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6907) RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions
[ https://issues.apache.org/jira/browse/OAK-6907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6907: Summary: RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions (was: RDB*Store: require ojdbc 12.2.0.1 because of known issues) > RDB*Store: require ojdbc 12.2.0.1 because of known issues in earlier versions > - > > Key: OAK-6907 > URL: https://issues.apache.org/jira/browse/OAK-6907 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_6 > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6907) RDB*Store: require ojdbc 12.2.0.1 because of known issues
[ https://issues.apache.org/jira/browse/OAK-6907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6907: Labels: candidate_oak_1_6 (was: ) > RDB*Store: require ojdbc 12.2.0.1 because of known issues > - > > Key: OAK-6907 > URL: https://issues.apache.org/jira/browse/OAK-6907 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_6 > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6906) RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches compatible with Java 7)
[ https://issues.apache.org/jira/browse/OAK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240191#comment-16240191 ] Julian Reschke edited comment on OAK-6906 at 11/6/17 1:26 PM: -- trunk: [r1814397|http://svn.apache.org/r1814397] 1.6: [r1814405|http://svn.apache.org/r1814405] was (Author: reschke): trunk: [r1814397|http://svn.apache.org/r1814397] > RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches > compatible with Java 7) > - > > Key: OAK-6906 > URL: https://issues.apache.org/jira/browse/OAK-6906 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_4 > Fix For: 1.8, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6906) RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches compatible with Java 7)
[ https://issues.apache.org/jira/browse/OAK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6906: Labels: candidate_oak_1_4 (was: candidate_oak_1_4 candidate_oak_1_6) > RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches > compatible with Java 7) > - > > Key: OAK-6906 > URL: https://issues.apache.org/jira/browse/OAK-6906 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_4 > Fix For: 1.8, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6906) RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches compatible with Java 7)
[ https://issues.apache.org/jira/browse/OAK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6906: Fix Version/s: 1.6.7 > RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches > compatible with Java 7) > - > > Key: OAK-6906 > URL: https://issues.apache.org/jira/browse/OAK-6906 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_4, candidate_oak_1_6 > Fix For: 1.8, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6907) RDB*Store: require ojdbc 12.2.0.1 because of known issues
Julian Reschke created OAK-6907: --- Summary: RDB*Store: require ojdbc 12.2.0.1 because of known issues Key: OAK-6907 URL: https://issues.apache.org/jira/browse/OAK-6907 Project: Jackrabbit Oak Issue Type: Technical task Components: rdbmk Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 1.8 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6829) ExternalPrivateStoreIT/ExternalSharedStoreIT.testSyncBigBlob failures
[
https://issues.apache.org/jira/browse/OAK-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240117#comment-16240117
]
Julian Reschke edited comment on OAK-6829 at 11/6/17 1:03 PM:
--
[~frm] - will check...
EDIT: seems to pass; re-enabled on Windows in r1814404
was (Author: reschke):
[~frm] - will check...
> ExternalPrivateStoreIT/ExternalSharedStoreIT.testSyncBigBlob failures
> -
>
> Key: OAK-6829
> URL: https://issues.apache.org/jira/browse/OAK-6829
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.7.9
>Reporter: Julian Reschke
>Assignee: Francesco Mari
> Fix For: 1.8, 1.7.12
>
> Attachments:
> TEST-org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT.xml,
> TEST-org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.xml,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt
>
>
> {noformat}
> testSyncBigBlob(org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT)
> Time elapsed: 27.921 sec <<< FAILURE!
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> Running org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT
> Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 93.353 sec
> <<< FAILURE! - in
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT
> testSyncBigBlob(org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT)
> Time elapsed: 30.772 sec <<< FAILURE!
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-6901) Unknown channel option 'TCP_NODELAY' for channel warning in cold standby
[
https://issues.apache.org/jira/browse/OAK-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-6901.
-
Resolution: Fixed
Fix Version/s: (was: 1.7.12)
1.7.11
Fixed at r1814400.
> Unknown channel option 'TCP_NODELAY' for channel warning in cold standby
>
>
> Key: OAK-6901
> URL: https://issues.apache.org/jira/browse/OAK-6901
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.7.6
>Reporter: Andrei Dulceanu
>Assignee: Francesco Mari
>Priority: Minor
> Labels: cold-standby
> Fix For: 1.7.11
>
>
> After the netty upgrade in OAK-6564, there's a recurring warning appearing in
> the server thread:
> {noformat}
> 18:54:44.691 [main] WARN io.netty.bootstrap.ServerBootstrap - Unknown
> channel option 'TCP_NODELAY' for channel '[id: 0xa64bc5c4]'
> {noformat}
> We need to see what's causing it (i.e. was that option removed in the latest
> version? if yes, is there a substitute/change needed?).
> /cc [~frm]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6906) RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches compatible with Java 7)
[ https://issues.apache.org/jira/browse/OAK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240191#comment-16240191 ] Julian Reschke commented on OAK-6906: - trunk: [r1814397|http://svn.apache.org/r1814397] > RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches > compatible with Java 7) > - > > Key: OAK-6906 > URL: https://issues.apache.org/jira/browse/OAK-6906 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_4, candidate_oak_1_6 > Fix For: 1.8, 1.7.11 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6906) RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches compatible with Java 7)
[ https://issues.apache.org/jira/browse/OAK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-6906. - Resolution: Fixed Fix Version/s: 1.7.11 > RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches > compatible with Java 7) > - > > Key: OAK-6906 > URL: https://issues.apache.org/jira/browse/OAK-6906 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_4, candidate_oak_1_6 > Fix For: 1.8, 1.7.11 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6903) RDB*Store: update Tomcat JDBC pool dependency to 7.0.82
[ https://issues.apache.org/jira/browse/OAK-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16237623#comment-16237623 ] Julian Reschke edited comment on OAK-6903 at 11/6/17 12:05 PM: --- trunk: [r1814189|http://svn.apache.org/r1814189] 1.6: [r1814199|http://svn.apache.org/r1814199] 1.4: [r1814221|http://svn.apache.org/r1814221] 1.2: [r1814391|http://svn.apache.org/r1814391] 1.0: [r1814396|http://svn.apache.org/r1814396] was (Author: reschke): trunk: [r1814189|http://svn.apache.org/r1814189] 1.6: [r1814199|http://svn.apache.org/r1814199] 1.4: [r1814221|http://svn.apache.org/r1814221] 1.2: [r1814391|http://svn.apache.org/r1814391] > RDB*Store: update Tomcat JDBC pool dependency to 7.0.82 > --- > > Key: OAK-6903 > URL: https://issues.apache.org/jira/browse/OAK-6903 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.8, 1.2.28, 1.0.40, 1.4.19, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6903) RDB*Store: update Tomcat JDBC pool dependency to 7.0.82
[ https://issues.apache.org/jira/browse/OAK-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6903: Fix Version/s: 1.0.40 > RDB*Store: update Tomcat JDBC pool dependency to 7.0.82 > --- > > Key: OAK-6903 > URL: https://issues.apache.org/jira/browse/OAK-6903 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.8, 1.2.28, 1.0.40, 1.4.19, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6903) RDB*Store: update Tomcat JDBC pool dependency to 7.0.82
[ https://issues.apache.org/jira/browse/OAK-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6903: Labels: (was: candidate_oak_1_0) > RDB*Store: update Tomcat JDBC pool dependency to 7.0.82 > --- > > Key: OAK-6903 > URL: https://issues.apache.org/jira/browse/OAK-6903 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.8, 1.2.28, 1.0.40, 1.4.19, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6906) RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches compatible with Java 7)
[ https://issues.apache.org/jira/browse/OAK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6906: Labels: candidate_oak_1_4 candidate_oak_1_6 (was: ) > RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches > compatible with Java 7) > - > > Key: OAK-6906 > URL: https://issues.apache.org/jira/browse/OAK-6906 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_4, candidate_oak_1_6 > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6906) RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches compatible with Java 7)
[ https://issues.apache.org/jira/browse/OAK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6906: Fix Version/s: 1.8 > RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches > compatible with Java 7) > - > > Key: OAK-6906 > URL: https://issues.apache.org/jira/browse/OAK-6906 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6906) RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches compatible with Java 7)
Julian Reschke created OAK-6906: --- Summary: RDB*Store: update Tomcat JDBC pool dependency to 8.5.23 (for branches compatible with Java 7) Key: OAK-6906 URL: https://issues.apache.org/jira/browse/OAK-6906 Project: Jackrabbit Oak Issue Type: Technical task Components: rdbmk Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5859) Analyse and reduce IO amplification by OS
[ https://issues.apache.org/jira/browse/OAK-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-5859: --- Fix Version/s: (was: 1.8) > Analyse and reduce IO amplification by OS > - > > Key: OAK-5859 > URL: https://issues.apache.org/jira/browse/OAK-5859 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Michael Dürig > > Certain operation system settings might result in too much data actually > being read from disk causing early setting on of thrashing. E.g. transparent > huge pages or too big read aheads might be contra productive in combination > with the TarMKs memory mapping model. > * Determine the ratio of data being read by the TarMK and actual data being > read from disk. Determine the impact of relevant OS parameters (e.g. > transparent huge pages) on this ratio. > * Compare memory mapped mode with file IO mode with an accordingly increased > segment cache. This would move prediction of what is likely to be read next > from the OS layer into our segment cache eviction strategy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5655) TarMK: Analyse locality of reference
[ https://issues.apache.org/jira/browse/OAK-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-5655: --- Fix Version/s: (was: 1.8) > TarMK: Analyse locality of reference > - > > Key: OAK-5655 > URL: https://issues.apache.org/jira/browse/OAK-5655 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Michael Dürig > Labels: scalability > Attachments: compaction-time-vs-reposize.m, > compaction-time-vs.reposize.png, data00053a.tar-reads.png, offrc.jfr, > segment-per-path-compacted-nocache.png, > segment-per-path-compacted-nostringcache.png, segment-per-path-compacted.png, > segment-per-path.png > > > We need to better understand the locality aspects of content stored in TarMK: > * How is related content spread over segments? > * What content do we consider related? > * How does locality of related content develop over time when changes are > applied? > * What changes do we consider typical? > * What is the impact of compaction on locality? > * What is the impact of the deduplication caches on locality (during normal > operation and during compaction)? > * How good are checkpoints deduplicated? Can we monitor this online? > * ... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6707) TarWriter.close() must not throw an exception on subsequent invocations
[
https://issues.apache.org/jira/browse/OAK-6707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6707:
---
Fix Version/s: (was: 1.8)
> TarWriter.close() must not throw an exception on subsequent invocations
> ---
>
> Key: OAK-6707
> URL: https://issues.apache.org/jira/browse/OAK-6707
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Priority: Minor
>
> Invoking TarWriter.close() on an already closed writer throws an {{ISE}}.
> According to the general contract this is not allowed:
> {code}
> * Closes this stream and releases any system resources associated
> * with it. If the stream is already closed then invoking this
> * method has no effect.
> {code}
> We should adjust the behvaviour of that method accordingly.
> Failing to comply with that general contract causes {{TarWriter}} instances
> to fail in try-resource statements when multiple wrapped streams are involved.
> Consider
> {code}
> try (
> StringWriter string = new StringWriter();
> PrintWriter writer = new PrintWriter(string);
> WriterOutputStream out = new WriterOutputStream(writer, Charsets.UTF_8))
> {
> dumpHeader(out);
> writer.println("");
> dumpHex(out);
> writer.println("");
> return string.toString();
> }
> {code}
> This code would cause exceptions to be thrown if e.g. the
> {{PrintWriter.close}} method would not be idempotent.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-5635) Revisit FileStoreStats mbean stats format
[ https://issues.apache.org/jira/browse/OAK-5635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-5635: --- Fix Version/s: (was: 1.8) > Revisit FileStoreStats mbean stats format > - > > Key: OAK-5635 > URL: https://issues.apache.org/jira/browse/OAK-5635 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Alex Deparvu >Assignee: Michael Dürig > Labels: monitoring > > This is a bigger refactoring item to revisit the format of the exposed data, > moving towards having it in a more machine consumable friendly format. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6836) OnRC report
[
https://issues.apache.org/jira/browse/OAK-6836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6836:
---
Priority: Minor (was: Major)
> OnRC report
> ---
>
> Key: OAK-6836
> URL: https://issues.apache.org/jira/browse/OAK-6836
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Valentin Olteanu
>Priority: Minor
> Labels: production
> Fix For: 1.8, 1.7.12
>
>
> Currently, the information regarding an online revision cleanup execution is
> scattered across multiple log lines and partially available in the attributes
> of {{SegmentRevisionGarbageCollection}} MBean.
> While useful for debugging, this is hard to grasp for users that need to
> understand the full process to be able to read it.
> The idea would be to create a "report" with all the details of an execution
> and output it at the end - write to log, but also store it in the MBean, from
> where it can be consumed by monitoring and health checks.
> In the MBean, this would replace the _Last*_ attributes.
> In the logs, this could replace all the intermediary logs (switch them to
> DEBUG).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6890) Background threads might not be automatically restarted
[
https://issues.apache.org/jira/browse/OAK-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6890:
---
Priority: Critical (was: Major)
> Background threads might not be automatically restarted
> ---
>
> Key: OAK-6890
> URL: https://issues.apache.org/jira/browse/OAK-6890
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Michael Dürig
>Priority: Critical
> Labels: resilience
> Fix For: 1.8, 1.7.12
>
>
> The background threads used in {{FileStore}} are implemented by wrapping
> {{Runnable}} instances in {{SafeRunnable}}, and by handing the
> {{SafeRunnable}} instances over to a {{ScheduledExecutorService}}.
> The documentation of {{ScheduledExecutorService#scheduleAtFixedRate}} states
> that "if any execution of the task encounters an exception, subsequent
> executions are suppressed". But a {{SafeRunnable}} always re-throws any
> {{Throwable}} that it catches, effectively preventing itself from executing
> again in the future.
> There is more than one solution to this problem. One of these is to never
> re-throw any exception. Even if it doesn't always make sense, e.g. in case of
> an {{OutOfMemoryError}}, never re-throwing an exception would better fulfil
> the assumption that background threads should always be up and running even
> in case of error.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6883) The compaction estimator should take the compaction type (tail vs. full) into consideration
[ https://issues.apache.org/jira/browse/OAK-6883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6883: --- Priority: Critical (was: Major) > The compaction estimator should take the compaction type (tail vs. full) into > consideration > --- > > Key: OAK-6883 > URL: https://issues.apache.org/jira/browse/OAK-6883 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Michael Dürig >Assignee: Francesco Mari >Priority: Critical > Labels: compaction, gc > Fix For: 1.8, 1.7.12 > > > Currently the compaction estimator unconditionally looks at the growth of the > repository since the last compaction run. This turn out to be not optimal > when interleaving tail and full compaction. It would be better to have the > estimator look at the growth of the repository since last full compaction > when running full compaction. > cc [~frm] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OAK-6890) Background threads might not be automatically restarted
[
https://issues.apache.org/jira/browse/OAK-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reassigned OAK-6890:
--
Assignee: Michael Dürig
> Background threads might not be automatically restarted
> ---
>
> Key: OAK-6890
> URL: https://issues.apache.org/jira/browse/OAK-6890
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Michael Dürig
> Labels: resilience
> Fix For: 1.8, 1.7.12
>
>
> The background threads used in {{FileStore}} are implemented by wrapping
> {{Runnable}} instances in {{SafeRunnable}}, and by handing the
> {{SafeRunnable}} instances over to a {{ScheduledExecutorService}}.
> The documentation of {{ScheduledExecutorService#scheduleAtFixedRate}} states
> that "if any execution of the task encounters an exception, subsequent
> executions are suppressed". But a {{SafeRunnable}} always re-throws any
> {{Throwable}} that it catches, effectively preventing itself from executing
> again in the future.
> There is more than one solution to this problem. One of these is to never
> re-throw any exception. Even if it doesn't always make sense, e.g. in case of
> an {{OutOfMemoryError}}, never re-throwing an exception would better fulfil
> the assumption that background threads should always be up and running even
> in case of error.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6606) Move BulkTransferBenchmark to oak-benchmarks module
[
https://issues.apache.org/jira/browse/OAK-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6606:
---
Fix Version/s: (was: 1.7.12)
1.7.13
> Move BulkTransferBenchmark to oak-benchmarks module
> ---
>
> Key: OAK-6606
> URL: https://issues.apache.org/jira/browse/OAK-6606
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: cold-standby
> Fix For: 1.8, 1.7.13
>
>
> {{BulkTransferBenchmark}} should be moved from {{oak-segment-tar}} to
> {{oak-benchmarks}} to allow standard run of this cold standby related
> benchmark.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6674) Create a more complex IT for cold standby
[
https://issues.apache.org/jira/browse/OAK-6674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6674:
---
Fix Version/s: (was: 1.7.12)
1.7.13
> Create a more complex IT for cold standby
> -
>
> Key: OAK-6674
> URL: https://issues.apache.org/jira/browse/OAK-6674
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar, tarmk-standby
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
> Labels: cold-standby
> Fix For: 1.8, 1.7.13
>
>
> At the moment all integration tests for cold standby are using the same
> scenario in their tests: some content is created on the server (including
> binaries), a standby sync cycle is started and then the content is checked on
> the client. The only twist here is using/not using a data store for storing
> binaries.
> Although good, this model could be extended to cover many more cases. For
> example, {{StandbyDiff}} covers the following 6 cases node/property
> added/changed/deleted. From these, with the scenario described, the removal
> part is never tested (and the change part is covered in only one test).
> It would be nice to have an IT which would add content on the server, do a
> sync, remove some of the content, do a sync and then call OnRC. This way all
> cases will be covered, including if cleanup works as expected on the client.
> /cc [~frm]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6166) Support versioning in the federated node store
[ https://issues.apache.org/jira/browse/OAK-6166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240118#comment-16240118 ] Tomek Rękawek commented on OAK-6166: [~rombert] - sure, done. > Support versioning in the federated node store > -- > > Key: OAK-6166 > URL: https://issues.apache.org/jira/browse/OAK-6166 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: composite >Reporter: Tomek Rękawek >Priority: Minor > Fix For: 1.9.0 > > > The mount info provider should affect the versioning code as well, so version > histories for the mounted paths are stored separately. Similarly to what we > have in the indexing, let's store the mounted version histories under: > /jcr:system/jcr:versionStorage/:oak:mount-MOUNTNAME -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6166) Support versioning in the federated node store
[ https://issues.apache.org/jira/browse/OAK-6166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek updated OAK-6166: --- Fix Version/s: 1.9.0 > Support versioning in the federated node store > -- > > Key: OAK-6166 > URL: https://issues.apache.org/jira/browse/OAK-6166 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: composite >Reporter: Tomek Rękawek >Priority: Minor > Fix For: 1.9.0 > > > The mount info provider should affect the versioning code as well, so version > histories for the mounted paths are stored separately. Similarly to what we > have in the indexing, let's store the mounted version histories under: > /jcr:system/jcr:versionStorage/:oak:mount-MOUNTNAME -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6166) Support versioning in the federated node store
[ https://issues.apache.org/jira/browse/OAK-6166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek updated OAK-6166: --- Fix Version/s: (was: 1.8) > Support versioning in the federated node store > -- > > Key: OAK-6166 > URL: https://issues.apache.org/jira/browse/OAK-6166 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: composite >Reporter: Tomek Rękawek >Priority: Minor > > The mount info provider should affect the versioning code as well, so version > histories for the mounted paths are stored separately. Similarly to what we > have in the indexing, let's store the mounted version histories under: > /jcr:system/jcr:versionStorage/:oak:mount-MOUNTNAME -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6829) ExternalPrivateStoreIT/ExternalSharedStoreIT.testSyncBigBlob failures
[
https://issues.apache.org/jira/browse/OAK-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240117#comment-16240117
]
Julian Reschke commented on OAK-6829:
-
[~frm] - will check...
> ExternalPrivateStoreIT/ExternalSharedStoreIT.testSyncBigBlob failures
> -
>
> Key: OAK-6829
> URL: https://issues.apache.org/jira/browse/OAK-6829
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.7.9
>Reporter: Julian Reschke
>Assignee: Francesco Mari
> Fix For: 1.8, 1.7.12
>
> Attachments:
> TEST-org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT.xml,
> TEST-org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.xml,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt
>
>
> {noformat}
> testSyncBigBlob(org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT)
> Time elapsed: 27.921 sec <<< FAILURE!
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> Running org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT
> Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 93.353 sec
> <<< FAILURE! - in
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT
> testSyncBigBlob(org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT)
> Time elapsed: 30.772 sec <<< FAILURE!
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OAK-6903) RDB*Store: update Tomcat JDBC pool dependency to 7.0.82
[ https://issues.apache.org/jira/browse/OAK-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16237623#comment-16237623 ] Julian Reschke edited comment on OAK-6903 at 11/6/17 10:18 AM: --- trunk: [r1814189|http://svn.apache.org/r1814189] 1.6: [r1814199|http://svn.apache.org/r1814199] 1.4: [r1814221|http://svn.apache.org/r1814221] 1.2: [r1814391|http://svn.apache.org/r1814391] was (Author: reschke): trunk: [r1814189|http://svn.apache.org/r1814189] 1.6: [r1814199|http://svn.apache.org/r1814199] 1.4: [r1814221|http://svn.apache.org/r1814221] > RDB*Store: update Tomcat JDBC pool dependency to 7.0.82 > --- > > Key: OAK-6903 > URL: https://issues.apache.org/jira/browse/OAK-6903 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_0 > Fix For: 1.8, 1.2.28, 1.4.19, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6903) RDB*Store: update Tomcat JDBC pool dependency to 7.0.82
[ https://issues.apache.org/jira/browse/OAK-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6903: Labels: candidate_oak_1_0 (was: candidate_oak_1_0 candidate_oak_1_2) > RDB*Store: update Tomcat JDBC pool dependency to 7.0.82 > --- > > Key: OAK-6903 > URL: https://issues.apache.org/jira/browse/OAK-6903 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_0 > Fix For: 1.8, 1.2.28, 1.4.19, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6903) RDB*Store: update Tomcat JDBC pool dependency to 7.0.82
[ https://issues.apache.org/jira/browse/OAK-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6903: Fix Version/s: 1.2.28 > RDB*Store: update Tomcat JDBC pool dependency to 7.0.82 > --- > > Key: OAK-6903 > URL: https://issues.apache.org/jira/browse/OAK-6903 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_0 > Fix For: 1.8, 1.2.28, 1.4.19, 1.7.11, 1.6.7 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6901) Unknown channel option 'TCP_NODELAY' for channel warning in cold standby
[
https://issues.apache.org/jira/browse/OAK-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240089#comment-16240089
]
Andrei Dulceanu commented on OAK-6901:
--
bq. The option should be removed from the parent channel in the server, it
definitely doesn't make sense there.
Makes sense. Thanks for the analysis, Francesco!
> Unknown channel option 'TCP_NODELAY' for channel warning in cold standby
>
>
> Key: OAK-6901
> URL: https://issues.apache.org/jira/browse/OAK-6901
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.7.6
>Reporter: Andrei Dulceanu
>Assignee: Francesco Mari
>Priority: Minor
> Labels: cold-standby
> Fix For: 1.7.12
>
>
> After the netty upgrade in OAK-6564, there's a recurring warning appearing in
> the server thread:
> {noformat}
> 18:54:44.691 [main] WARN io.netty.bootstrap.ServerBootstrap - Unknown
> channel option 'TCP_NODELAY' for channel '[id: 0xa64bc5c4]'
> {noformat}
> We need to see what's causing it (i.e. was that option removed in the latest
> version? if yes, is there a substitute/change needed?).
> /cc [~frm]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6166) Support versioning in the federated node store
[ https://issues.apache.org/jira/browse/OAK-6166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240088#comment-16240088 ] Robert Munteanu commented on OAK-6166: -- [~tomek.rekawek] - should we postpone this for a later version? > Support versioning in the federated node store > -- > > Key: OAK-6166 > URL: https://issues.apache.org/jira/browse/OAK-6166 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: composite >Reporter: Tomek Rękawek >Priority: Minor > Fix For: 1.8 > > > The mount info provider should affect the versioning code as well, so version > histories for the mounted paths are stored separately. Similarly to what we > have in the indexing, let's store the mounted version histories under: > /jcr:system/jcr:versionStorage/:oak:mount-MOUNTNAME -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6901) Unknown channel option 'TCP_NODELAY' for channel warning in cold standby
[
https://issues.apache.org/jira/browse/OAK-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240089#comment-16240089
]
Andrei Dulceanu edited comment on OAK-6901 at 11/6/17 9:58 AM:
---
bq. The option should be removed from the parent channel in the server, it
definitely doesn't make sense there.
Makes sense. Thanks for the analysis, [~frm]!
was (Author: dulceanu):
bq. The option should be removed from the parent channel in the server, it
definitely doesn't make sense there.
Makes sense. Thanks for the analysis, Francesco!
> Unknown channel option 'TCP_NODELAY' for channel warning in cold standby
>
>
> Key: OAK-6901
> URL: https://issues.apache.org/jira/browse/OAK-6901
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.7.6
>Reporter: Andrei Dulceanu
>Assignee: Francesco Mari
>Priority: Minor
> Labels: cold-standby
> Fix For: 1.7.12
>
>
> After the netty upgrade in OAK-6564, there's a recurring warning appearing in
> the server thread:
> {noformat}
> 18:54:44.691 [main] WARN io.netty.bootstrap.ServerBootstrap - Unknown
> channel option 'TCP_NODELAY' for channel '[id: 0xa64bc5c4]'
> {noformat}
> We need to see what's causing it (i.e. was that option removed in the latest
> version? if yes, is there a substitute/change needed?).
> /cc [~frm]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (OAK-6901) Unknown channel option 'TCP_NODELAY' for channel warning in cold standby
[
https://issues.apache.org/jira/browse/OAK-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari reassigned OAK-6901:
---
Assignee: Francesco Mari (was: Andrei Dulceanu)
> Unknown channel option 'TCP_NODELAY' for channel warning in cold standby
>
>
> Key: OAK-6901
> URL: https://issues.apache.org/jira/browse/OAK-6901
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.7.6
>Reporter: Andrei Dulceanu
>Assignee: Francesco Mari
>Priority: Minor
> Labels: cold-standby
> Fix For: 1.7.12
>
>
> After the netty upgrade in OAK-6564, there's a recurring warning appearing in
> the server thread:
> {noformat}
> 18:54:44.691 [main] WARN io.netty.bootstrap.ServerBootstrap - Unknown
> channel option 'TCP_NODELAY' for channel '[id: 0xa64bc5c4]'
> {noformat}
> We need to see what's causing it (i.e. was that option removed in the latest
> version? if yes, is there a substitute/change needed?).
> /cc [~frm]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6829) ExternalPrivateStoreIT/ExternalSharedStoreIT.testSyncBigBlob failures
[
https://issues.apache.org/jira/browse/OAK-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240081#comment-16240081
]
Francesco Mari commented on OAK-6829:
-
[~reschke], have you experienced any failures of the test after my latest
change?
> ExternalPrivateStoreIT/ExternalSharedStoreIT.testSyncBigBlob failures
> -
>
> Key: OAK-6829
> URL: https://issues.apache.org/jira/browse/OAK-6829
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.7.9
>Reporter: Julian Reschke
>Assignee: Francesco Mari
> Fix For: 1.8, 1.7.12
>
> Attachments:
> TEST-org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT.xml,
> TEST-org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.xml,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt
>
>
> {noformat}
> testSyncBigBlob(org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT)
> Time elapsed: 27.921 sec <<< FAILURE!
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> Running org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT
> Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 93.353 sec
> <<< FAILURE! - in
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT
> testSyncBigBlob(org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT)
> Time elapsed: 30.772 sec <<< FAILURE!
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6901) Unknown channel option 'TCP_NODELAY' for channel warning in cold standby
[
https://issues.apache.org/jira/browse/OAK-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240077#comment-16240077
]
Francesco Mari commented on OAK-6901:
-
{{TCP_NODELAY}} disables TCP's internal buffering for small packets. It makes
sense for the client channels and the worker channels on the server, since we
make buffering at application's level and don't need support from the protocol
to optimize small writes. The option should be removed from the parent channel
in the server, it definitely doesn't make sense there.
Regarding the reason why we are seeing the warning now, it might be related to
[issue 6192|https://github.com/netty/netty/issues/6192] in Netty.
> Unknown channel option 'TCP_NODELAY' for channel warning in cold standby
>
>
> Key: OAK-6901
> URL: https://issues.apache.org/jira/browse/OAK-6901
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.7.6
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: cold-standby
> Fix For: 1.7.12
>
>
> After the netty upgrade in OAK-6564, there's a recurring warning appearing in
> the server thread:
> {noformat}
> 18:54:44.691 [main] WARN io.netty.bootstrap.ServerBootstrap - Unknown
> channel option 'TCP_NODELAY' for channel '[id: 0xa64bc5c4]'
> {noformat}
> We need to see what's causing it (i.e. was that option removed in the latest
> version? if yes, is there a substitute/change needed?).
> /cc [~frm]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6711) Refactor IndexConstants so it can be referenced from outside oak-core
[ https://issues.apache.org/jira/browse/OAK-6711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-6711: -- Fix Version/s: (was: 1.8) > Refactor IndexConstants so it can be referenced from outside oak-core > - > > Key: OAK-6711 > URL: https://issues.apache.org/jira/browse/OAK-6711 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: core >Reporter: Alex Deparvu > > This is blocking OAK-6318, the security spi code depends on this constants > class so I'd like to move it to a different location. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OAK-5499) IndexUpdate can do mulitple traversal of a content tree during initial index when there are sub-root indices
[
https://issues.apache.org/jira/browse/OAK-5499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu reassigned OAK-5499:
-
Assignee: (was: Alex Deparvu)
> IndexUpdate can do mulitple traversal of a content tree during initial index
> when there are sub-root indices
>
>
> Key: OAK-5499
> URL: https://issues.apache.org/jira/browse/OAK-5499
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing
>Reporter: Vikas Saurabh
>Priority: Minor
> Attachments: OAK-5499-v2-demo.patch, OAK-5499-v2-fix.patch,
> OAK-5499.patch
>
>
> In case we've index defs such as:
> {noformat}
> /oak:index/foo1Index
> /content
>/oak:index/foo2Index
> {noformat}
> then initial indexing process \[0] would traverse tree under {{/content}}
> twice - once while indexing for top-level indices and next when it starts to
> index newly discovered {{foo2Index}} while traversing {{/content/oak:index}}.
> What we can do is that while first diff processes {{/content}} and discovers
> a node named {{oak:index}}, it can actively go in that tree and peek into
> index defs from under it and register as required. The diff can then proceed
> under {{/content}} while the new indices would also get diffs (avoiding
> another traversal)
> \[0] first time indexing or in case {{/:async}} gets deleted or checkpoint
> for async index couldn't be retrieved
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-5499) IndexUpdate can do mulitple traversal of a content tree during initial index when there are sub-root indices
[
https://issues.apache.org/jira/browse/OAK-5499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-5499:
--
Fix Version/s: (was: 1.8)
> IndexUpdate can do mulitple traversal of a content tree during initial index
> when there are sub-root indices
>
>
> Key: OAK-5499
> URL: https://issues.apache.org/jira/browse/OAK-5499
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing
>Reporter: Vikas Saurabh
>Priority: Minor
> Attachments: OAK-5499-v2-demo.patch, OAK-5499-v2-fix.patch,
> OAK-5499.patch
>
>
> In case we've index defs such as:
> {noformat}
> /oak:index/foo1Index
> /content
>/oak:index/foo2Index
> {noformat}
> then initial indexing process \[0] would traverse tree under {{/content}}
> twice - once while indexing for top-level indices and next when it starts to
> index newly discovered {{foo2Index}} while traversing {{/content/oak:index}}.
> What we can do is that while first diff processes {{/content}} and discovers
> a node named {{oak:index}}, it can actively go in that tree and peek into
> index defs from under it and register as required. The diff can then proceed
> under {{/content}} while the new indices would also get diffs (avoiding
> another traversal)
> \[0] first time indexing or in case {{/:async}} gets deleted or checkpoint
> for async index couldn't be retrieved
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-5229:
--
Fix Version/s: (was: 1.8)
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Alex Deparvu
>Priority: Critical
> Attachments: OAK-5229-tests.patch, OAK-5229-v2.patch,
> OAK-5229-v3.patch, OAK-5229-v4.patch, OAK-5229-v5.patch, OAK-5229-v6.patch,
> OAK-5229.patch
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-1980) Use index on non-root node
[ https://issues.apache.org/jira/browse/OAK-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella resolved OAK-1980. --- Resolution: Won't Fix Thanks for sharing your opinion Marcel. This won't fix then. > Use index on non-root node > -- > > Key: OAK-1980 > URL: https://issues.apache.org/jira/browse/OAK-1980 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: property-index >Reporter: Marcel Reutegger >Assignee: Davide Giannella > Attachments: OAK-1980.patch > > > Oak is able to maintain indexes on any location in the hierarchy. However the > lookup for most index implementations only make use of an index under the > root node. There are various TODOs in the code regarding this, e.g. in > PropertyIndex. Looking up an index along the filter path adds some additional > cost, but should be within reasonable bounds. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-3878) Avoid caching of NodeDocument while iterating in BlobReferenceIterator
[
https://issues.apache.org/jira/browse/OAK-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved OAK-3878.
-
Resolution: Fixed
Fix Version/s: 1.7.11
Fixed by the changes for OAK-6839 and earlier improvements to Blob GC.
> Avoid caching of NodeDocument while iterating in BlobReferenceIterator
> --
>
> Key: OAK-3878
> URL: https://issues.apache.org/jira/browse/OAK-3878
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.8, 1.7.11
>
>
> {{BlobReferenceIterator}} in DocumentMK makes use of {{DocumentStore}} API to
> query the NodeDocument. This would cause all those NodeDocuments to be added
> to cache in DocumentStore. Due to this when blob gc is running cache usage
> would not be that effective due to all the associated churn.
> As these NodeDocument are only required for BlobGC logic and its not expected
> that this document would read again soon it would be better to skip caching
> of these documents within DocumentStore
> Similar requirement exist in VersionGC logic but there we use direct store
> based API which does not add such documents to the cache
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-4760) Adjust default timeout values for RDBDocumentStore
[ https://issues.apache.org/jira/browse/OAK-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4760: Summary: Adjust default timeout values for RDBDocumentStore (was: CLONE - Adjust default timeout values for RDBDocumentStore) > Adjust default timeout values for RDBDocumentStore > -- > > Key: OAK-4760 > URL: https://issues.apache.org/jira/browse/OAK-4760 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, rdbmk >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: resilience > Fix For: 1.8 > > > Some default values timeouts of the RDBDocumentStore driver do not work well > with the lease time we use in Oak. > See also OAK-4739. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-5387) Test failure: ConcurrentQueryAndUpdateIT.cacheUpdate[RDBFixture: RDB-H2(file)]
[
https://issues.apache.org/jira/browse/OAK-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5387:
Fix Version/s: (was: 1.8)
> Test failure: ConcurrentQueryAndUpdateIT.cacheUpdate[RDBFixture: RDB-H2(file)]
> --
>
> Key: OAK-5387
> URL: https://issues.apache.org/jira/browse/OAK-5387
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, rdbmk
>Affects Versions: 1.2.23, 1.6.0
>Reporter: Hudson
>Assignee: Julian Reschke
> Labels: Windows, test-failure
> Attachments: Build 448 Windows log.zip, unit-tests.log.zip
>
>
> Jenkins CI failure:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
> The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8
> (latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting #1345 has failed.
> First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK
> 1.8 (latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting
> #1345|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting/1345/]
> [console
> log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting/1345/console]
> {noformat}
> cacheUpdate[RDBFixture:
> RDB-H2(file)](org.apache.jackrabbit.oak.plugins.document.ConcurrentQueryAndUpdateIT)
> Time elapsed: 54.353 sec <<< FAILURE!
> java.lang.AssertionError: Unexpected revision timestamp for 1:/node-39
> expected:<867> but was:<866>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.jackrabbit.oak.plugins.document.ConcurrentQueryAndUpdateIT.cacheUpdate(ConcurrentQueryAndUpdateIT.java:80)
> Failed tests: cacheUpdate[RDBFixture:
> RDB-H2(file)](org.apache.jackrabbit.oak.plugins.document.ConcurrentQueryAndUpdateIT):
> Unexpected revision timestamp for 1:/node-39 expected:<867> but was:<866>
> {noformat}
> Also seen on Windows:
> https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.8%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_NS,profile=integrationTesting/448/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-6870) Update dependency to org.apache.directory.api.api-all
[ https://issues.apache.org/jira/browse/OAK-6870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-6870. - Resolution: Duplicate > Update dependency to org.apache.directory.api.api-all > - > > Key: OAK-6870 > URL: https://issues.apache.org/jira/browse/OAK-6870 > Project: Jackrabbit Oak > Issue Type: Task > Components: auth-ldap >Reporter: Julian Reschke > > We currently use a release candidate, but could switch to 1.0.0 (see > https://mvnrepository.com/artifact/org.apache.directory.api/api-all) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6178) Test failure: DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources
[
https://issues.apache.org/jira/browse/OAK-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-6178:
Fix Version/s: (was: 1.8)
> Test failure: DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources
> --
>
> Key: OAK-6178
> URL: https://issues.apache.org/jira/browse/OAK-6178
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, rdbmk
>Reporter: Hudson
> Labels: CI, jenkins, test-failure
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #259 has failed.
> First failed run: [Jackrabbit Oak
> #259|https://builds.apache.org/job/Jackrabbit%20Oak/259/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/259/console]
> {code}
> Error Message
> Service of type interface org.apache.jackrabbit.oak.spi.state.NodeStore was
> found. Expression: (sr == null). Values: sr =
> [org.apache.jackrabbit.oak.spi.state.NodeStore,
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore,
> org.apache.jackrabbit.oak.spi.state.Clusterable]
> Stacktrace
> java.lang.AssertionError: Service of type interface
> org.apache.jackrabbit.oak.spi.state.NodeStore was found. Expression: (sr ==
> null). Values: sr = [org.apache.jackrabbit.oak.spi.state.NodeStore,
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore,
> org.apache.jackrabbit.oak.spi.state.Clusterable]
> at
> org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStore2Datasources(DocumentNodeStoreConfigTest.groovy:110)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6594) UpgradeIT produces unwanted output
[
https://issues.apache.org/jira/browse/OAK-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6594:
---
Fix Version/s: (was: 1.7.12)
> UpgradeIT produces unwanted output
> --
>
> Key: OAK-6594
> URL: https://issues.apache.org/jira/browse/OAK-6594
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Michael Dürig
>Priority: Minor
> Fix For: 1.8
>
>
> When {{UpgradeIT}} is executed, the following output is produced.
> {noformat}
> Running org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT
> Apache Jackrabbit Oak 1.6.1
> ===> true
> ===> org.apache.jackrabbit.oak.plugins.document.*,
> org.apache.jackrabbit.oak.plugins.segment.*,
> org.apache.jackrabbit.oak.segment.SegmentNodeBuilder
> ===> org.apache.jackrabbit.oak.plugins.document.*,
> org.apache.jackrabbit.oak.plugins.segment.*,
> org.apache.jackrabbit.oak.segment.SegmentNodeBuilder,
> org.apache.jackrabbit.oak.spi.commit.EmptyHook
> ===> org.apache.jackrabbit.oak.plugins.document.*,
> org.apache.jackrabbit.oak.plugins.segment.*,
> org.apache.jackrabbit.oak.segment.SegmentNodeBuilder,
> org.apache.jackrabbit.oak.spi.commit.EmptyHook,
> org.apache.jackrabbit.oak.spi.commit.CommitInfo
> ===> true
> ===> org.apache.jackrabbit.oak.segment.SegmentNodeStore@75e01201
> ===> SegmentNodeBuilder{path=/}
> ===> null
> ===> { property-name-5-0 = property-value-5-0, property-name-5-1 =
> property-value-5-1, property-name-5-2 = property-value-5-2, property-name-5-3
> = property-value-5-3, property-name-5-4 = property-value-5-4,
> property-name-5-5 = property-value-5-5, property-name-5-6 =
> property-value-5-6, property-name-5-7 = property-value-5-7, property-name-5-8
> = property-value-5-8, property-name-5-9 = property-value-5-9, node-5-3 = {
> ... }, node-5-4 = { ... }, node-5-9 = { ... }, node-5-1 = { ... }, node-5-2 =
> { ... }, node-5-7 = { ... }, node-5-8 = { ... }, node-5-5 = { ... }, node-5-0
> = { ... }, node-5-6 = { ... } }
> Apache Jackrabbit Oak 1.6.1
> ===> true
> ===> org.apache.jackrabbit.oak.plugins.document.*,
> org.apache.jackrabbit.oak.plugins.segment.*,
> org.apache.jackrabbit.oak.segment.SegmentNodeBuilder
> ===> org.apache.jackrabbit.oak.plugins.document.*,
> org.apache.jackrabbit.oak.plugins.segment.*,
> org.apache.jackrabbit.oak.segment.SegmentNodeBuilder,
> org.apache.jackrabbit.oak.spi.commit.EmptyHook
> ===> org.apache.jackrabbit.oak.plugins.document.*,
> org.apache.jackrabbit.oak.plugins.segment.*,
> org.apache.jackrabbit.oak.segment.SegmentNodeBuilder,
> org.apache.jackrabbit.oak.spi.commit.EmptyHook,
> org.apache.jackrabbit.oak.spi.commit.CommitInfo
> ===> true
> ===> org.apache.jackrabbit.oak.segment.SegmentNodeStore@75e01201
> ===> SegmentNodeBuilder{path=/}
> ===> null
> ===> { property-name-5-0 = property-value-5-0, property-name-5-1 =
> property-value-5-1, property-name-5-2 = property-value-5-2, property-name-5-3
> = property-value-5-3, property-name-5-4 = property-value-5-4,
> property-name-5-5 = property-value-5-5, property-name-5-6 =
> property-value-5-6, property-name-5-7 = property-value-5-7, property-name-5-8
> = property-value-5-8, property-name-5-9 = property-value-5-9, node-5-3 = {
> ... }, node-5-4 = { ... }, node-5-9 = { ... }, node-5-1 = { ... }, node-5-2 =
> { ... }, node-5-7 = { ... }, node-5-8 = { ... }, node-5-5 = { ... }, node-5-0
> = { ... }, node-5-6 = { ... } }
> Apache Jackrabbit Oak 1.6.1
> ===> true
> ===> org.apache.jackrabbit.oak.plugins.document.*,
> org.apache.jackrabbit.oak.plugins.segment.*,
> org.apache.jackrabbit.oak.segment.SegmentNodeBuilder
> ===> org.apache.jackrabbit.oak.plugins.document.*,
> org.apache.jackrabbit.oak.plugins.segment.*,
> org.apache.jackrabbit.oak.segment.SegmentNodeBuilder,
> org.apache.jackrabbit.oak.spi.commit.EmptyHook
> ===> org.apache.jackrabbit.oak.plugins.document.*,
> org.apache.jackrabbit.oak.plugins.segment.*,
> org.apache.jackrabbit.oak.segment.SegmentNodeBuilder,
> org.apache.jackrabbit.oak.spi.commit.EmptyHook,
> org.apache.jackrabbit.oak.spi.commit.CommitInfo
> ===> true
> ===> org.apache.jackrabbit.oak.segment.SegmentNodeStore@75e01201
> ===> SegmentNodeBuilder{path=/}
> ===> null
> ===> { property-name-5-0 = property-value-5-0, property-name-5-1 =
> property-value-5-1, property-name-5-2 = property-value-5-2, property-name-5-3
> = property-value-5-3, property-name-5-4 = property-value-5-4,
> property-name-5-5 = property-value-5-5, property-name-5-6 =
> property-value-5-6, property-name-5-7 = property-value-5-7, property-name-5-8
> = property-value-5-8, property-name-5-9 = property-value-5-9, node-5-3 = {
> ... }, node-5-4 = { ... }, node-5-9 = { ... }, node-5-1 = { ... }, node-5-2 =
> { ... }, node-5-7 = { ... }, node-5-8 = {
[jira] [Updated] (OAK-6606) Move BulkTransferBenchmark to oak-benchmarks module
[
https://issues.apache.org/jira/browse/OAK-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6606:
---
Fix Version/s: (was: 1.7.11)
1.7.12
> Move BulkTransferBenchmark to oak-benchmarks module
> ---
>
> Key: OAK-6606
> URL: https://issues.apache.org/jira/browse/OAK-6606
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: cold-standby
> Fix For: 1.8, 1.7.12
>
>
> {{BulkTransferBenchmark}} should be moved from {{oak-segment-tar}} to
> {{oak-benchmarks}} to allow standard run of this cold standby related
> benchmark.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6883) The compaction estimator should take the compaction type (tail vs. full) into consideration
[ https://issues.apache.org/jira/browse/OAK-6883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6883: --- Fix Version/s: (was: 1.7.11) 1.7.12 > The compaction estimator should take the compaction type (tail vs. full) into > consideration > --- > > Key: OAK-6883 > URL: https://issues.apache.org/jira/browse/OAK-6883 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Michael Dürig >Assignee: Francesco Mari > Labels: compaction, gc > Fix For: 1.8, 1.7.12 > > > Currently the compaction estimator unconditionally looks at the growth of the > repository since the last compaction run. This turn out to be not optimal > when interleaving tail and full compaction. It would be better to have the > estimator look at the growth of the repository since last full compaction > when running full compaction. > cc [~frm] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6674) Create a more complex IT for cold standby
[
https://issues.apache.org/jira/browse/OAK-6674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6674:
---
Fix Version/s: (was: 1.7.11)
1.7.12
> Create a more complex IT for cold standby
> -
>
> Key: OAK-6674
> URL: https://issues.apache.org/jira/browse/OAK-6674
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar, tarmk-standby
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
> Labels: cold-standby
> Fix For: 1.8, 1.7.12
>
>
> At the moment all integration tests for cold standby are using the same
> scenario in their tests: some content is created on the server (including
> binaries), a standby sync cycle is started and then the content is checked on
> the client. The only twist here is using/not using a data store for storing
> binaries.
> Although good, this model could be extended to cover many more cases. For
> example, {{StandbyDiff}} covers the following 6 cases node/property
> added/changed/deleted. From these, with the scenario described, the removal
> part is never tested (and the change part is covered in only one test).
> It would be nice to have an IT which would add content on the server, do a
> sync, remove some of the content, do a sync and then call OnRC. This way all
> cases will be covered, including if cleanup works as expected on the client.
> /cc [~frm]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6737) Standby server should send timely responses to all client requests
[
https://issues.apache.org/jira/browse/OAK-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6737:
---
Fix Version/s: (was: 1.7.11)
1.7.12
> Standby server should send timely responses to all client requests
> --
>
> Key: OAK-6737
> URL: https://issues.apache.org/jira/browse/OAK-6737
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar, tarmk-standby
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: cold-standby
> Fix For: 1.8, 1.7.12
>
>
> Currently all the {{GetXXXRequestHandler}} (where XXX stands for Blob, Head,
> References and Segment), on the server discard client requests which cannot
> be satisfied (i.e. the requested object does not exist (yet) on the server).
> A more transparent approach would be to timely respond to all client
> requests, clearly stating that the object was not found. This would improve a
> lot debugging for example, because all requests and their responses could be
> easily followed from the client log, without needing to know what actually
> happened on the server.
> Below, a possible implementation for {{GetHeadRequestHandler}}, suggested by
> [~frm] in a comment on OAK-6678:
> {noformat}
> String id = reader.readHeadRecordId();
> if (id == null) {
> ctx.writeAndFlush(new NotFoundGetHeadResponse(msg.getClientId(), id));
> return;
> }
> ctx.writeAndFlush(new GetHeadResponse(msg.getClientId(), id));
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6829) ExternalPrivateStoreIT/ExternalSharedStoreIT.testSyncBigBlob failures
[
https://issues.apache.org/jira/browse/OAK-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6829:
---
Fix Version/s: (was: 1.7.11)
1.7.12
> ExternalPrivateStoreIT/ExternalSharedStoreIT.testSyncBigBlob failures
> -
>
> Key: OAK-6829
> URL: https://issues.apache.org/jira/browse/OAK-6829
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.7.9
>Reporter: Julian Reschke
>Assignee: Francesco Mari
> Fix For: 1.8, 1.7.12
>
> Attachments:
> TEST-org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT.xml,
> TEST-org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.xml,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt,
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT-output.txt
>
>
> {noformat}
> testSyncBigBlob(org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT)
> Time elapsed: 27.921 sec <<< FAILURE!
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> Running org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT
> Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 93.353 sec
> <<< FAILURE! - in
> org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT
> testSyncBigBlob(org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT)
> Time elapsed: 30.772 sec <<< FAILURE!
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6542) java.lang.NoClassDefFoundError: com/codahale/metrics/Reservoir
[ https://issues.apache.org/jira/browse/OAK-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-6542: --- Fix Version/s: (was: 1.7.11) 1.7.12 > java.lang.NoClassDefFoundError: com/codahale/metrics/Reservoir > -- > > Key: OAK-6542 > URL: https://issues.apache.org/jira/browse/OAK-6542 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Affects Versions: 1.7.5 >Reporter: Olivier Lamy (*$^¨%`£) >Assignee: Andrei Dulceanu > Fix For: 1.8, 1.7.12 > > > Upgrading to last 1.7.5. > I get this exception > java.lang.NoClassDefFoundError: com/codahale/metrics/Reservoir > at > org.apache.jackrabbit.oak.segment.SegmentNodeStore.(SegmentNodeStore.java:166) > at > org.apache.jackrabbit.oak.segment.SegmentNodeStore.(SegmentNodeStore.java:63) > at > org.apache.jackrabbit.oak.segment.SegmentNodeStore$SegmentNodeStoreBuilder.build(SegmentNodeStore.java:121) > Looking at the pom the dependency has a scope provided > (http://repo.maven.apache.org/maven2/org/apache/jackrabbit/oak-segment-tar/1.7.5/oak-segment-tar-1.7.5.pom) > IMHO it's a wrong dependency scope at it's definitely needed as there is no > usage of reflection to avoid loading of the classes -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OAK-6894) org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments failing
[
https://issues.apache.org/jira/browse/OAK-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reassigned OAK-6894:
--
Assignee: Michael Dürig
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments
> failing
> -
>
> Key: OAK-6894
> URL: https://issues.apache.org/jira/browse/OAK-6894
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Julian Reschke
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: compaction, gc
> Fix For: 1.8, 1.7.11
>
> Attachments:
> TEST-org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.xml,
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT-output.txt,
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.txt
>
>
> {noformat}
> [ERROR]
> offRCUpgradesSegments(org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT)
> Time elapsed: 7.446 s <<< FAILURE!
> java.lang.AssertionError: Segment version mismatch. Expected V_13, found V_12
> expected: but was:
> at
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.checkSegmentVersion(UpgradeIT.java:141)
> at
> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments(UpgradeIT.java:107)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-1980) Use index on non-root node
[ https://issues.apache.org/jira/browse/OAK-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240018#comment-16240018 ] Marcel Reutegger commented on OAK-1980: --- In my view the actual index implementation is not relevant for this discussion. The main benefit I see with non-root index definitions is that they are closer to the content they index and allow use cases that are difficult to implement with only index definitions under the root. E.g. consider a larger system that has many users or tenants where each of them can only see their content. If their content is part of a single big index under the root, then the query engine will have to filter out many nodes returned by the index because of access control, resulting in poor query performance. Such a query limited to the content of a user/tenant would be more efficient if it was able to use an index that just covers the users/tenants content. I guess the reason why this issue is still open means above use case isn't that important at the moment. Feel free to close the issue WONTFIX. > Use index on non-root node > -- > > Key: OAK-1980 > URL: https://issues.apache.org/jira/browse/OAK-1980 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: property-index >Reporter: Marcel Reutegger >Assignee: Davide Giannella > Attachments: OAK-1980.patch > > > Oak is able to maintain indexes on any location in the hierarchy. However the > lookup for most index implementations only make use of an index under the > root node. There are various TODOs in the code regarding this, e.g. in > PropertyIndex. Looking up an index along the filter path adds some additional > cost, but should be within reasonable bounds. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
