[jira] [Updated] (OAK-8014) Commits carrying over from previous GC generation can block other threads from committing
[
https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-8014:
---
Fix Version/s: (was: 1.11.0)
(was: 1.12)
> Commits carrying over from previous GC generation can block other threads
> from committing
> -
>
> Key: OAK-8014
> URL: https://issues.apache.org/jira/browse/OAK-8014
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.10.0, 1.8.11
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
> Attachments: OAK-8014.patch
>
>
> A commit that is based on a previous (full) generation can block other
> commits from progressing for a long time. This happens because such a commit
> will do a deep copy of its state to avoid linking to old segments (see
> OAK-3348). Most of the deep copying is usually avoided by the deduplication
> caches. However, in cases where the cache hit rate is not good enough we have
> seen deep copy operations up to several minutes. Sometimes this deep copy
> operation happens inside the commit lock of
> {{LockBasedScheduler.schedule()}}, which then causes all other commits to
> become blocked.
> cc [~rma61...@adobe.com], [~edivad]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-4689) Add information about amount of data vs. waste to oak-run
[
https://issues.apache.org/jira/browse/OAK-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4689:
---
Fix Version/s: (was: 1.12)
> Add information about amount of data vs. waste to oak-run
> -
>
> Key: OAK-4689
> URL: https://issues.apache.org/jira/browse/OAK-4689
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: production, tooling
>
> This is a follow up for OAK-3695, where we decided that it would be to
> expensive doing this as live monitoring.
> Instead we should add functionality to {{oak-run}} that could connect in read
> only mode to a running repository and collect information about how much data
> and how must wast the repository contains.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8014) Commits carrying over from previous GC generation can block other threads from committing
[
https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-8014:
---
Fix Version/s: (was: 1.10.2)
(was: 1.8.12)
> Commits carrying over from previous GC generation can block other threads
> from committing
> -
>
> Key: OAK-8014
> URL: https://issues.apache.org/jira/browse/OAK-8014
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.10.0, 1.8.11
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8014.patch
>
>
> A commit that is based on a previous (full) generation can block other
> commits from progressing for a long time. This happens because such a commit
> will do a deep copy of its state to avoid linking to old segments (see
> OAK-3348). Most of the deep copying is usually avoided by the deduplication
> caches. However, in cases where the cache hit rate is not good enough we have
> seen deep copy operations up to several minutes. Sometimes this deep copy
> operation happens inside the commit lock of
> {{LockBasedScheduler.schedule()}}, which then causes all other commits to
> become blocked.
> cc [~rma61...@adobe.com], [~edivad]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5360) Cancellation of gc should be reflected by RevisionGC.getRevisionGCStatus()
[
https://issues.apache.org/jira/browse/OAK-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-5360:
---
Fix Version/s: (was: 1.12)
> Cancellation of gc should be reflected by RevisionGC.getRevisionGCStatus()
> --
>
> Key: OAK-5360
> URL: https://issues.apache.org/jira/browse/OAK-5360
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: gc, management, monitoring, production
>
> Currently when a garbage collection cycle is cancelled from "within" (i.e.
> through {{CancelCompactionSupplier}} then this is not reflected through
> {{RevisionGC.getRevisionGCStatus()}} but rather reported as successful run.
> We should change this and return a failure result indication the cancellation
> so downstream consumers get an proper indication whether and which gc runs
> actually succeeded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7234) Check for outdated journal at startup
[
https://issues.apache.org/jira/browse/OAK-7234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-7234:
---
Fix Version/s: (was: 1.12)
> Check for outdated journal at startup
> -
>
> Key: OAK-7234
> URL: https://issues.apache.org/jira/browse/OAK-7234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Minor
> Labels: resilience, tooling
>
> To prevent accidentally branching the repository when the {{journal.log}}
> became outdated (e.g. OAK-3702) we could add an additional safety feature
> which would prevent the repository from starting in such cases. There's a
> couple of concerns to address:
> * What kind of tooling / guidance do we need to provide to recover should
> such a situation be detected?
> * How do we detect the {{journal.log}} being outdated?
> * How do we prevent false positives?
> * How do we deal with situation where the {{journal.log}} modifications are
> intended (e.g. by tools, of manual interventions)?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8066) Nodes with many direct children can lead to OOME when saving
[
https://issues.apache.org/jira/browse/OAK-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-8066:
---
Fix Version/s: 1.12
> Nodes with many direct children can lead to OOME when saving
>
>
> Key: OAK-8066
> URL: https://issues.apache.org/jira/browse/OAK-8066
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
> Fix For: 1.12
>
>
> {{DefaultSegmentWriter}} keeps a map of [child
> nodes|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/DefaultSegmentWriter.java#L805]
> of a node being written. This can lead to high memory consumption in the
> case where many child nodes are added at the same time. The latter could
> happen in the case where a node needs to be rewritten because of an increase
> in the GC generation from a concurrently completed revision garbage
> collection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (OAK-8014) Commits carrying over from previous GC generation can block other threads from committing
[
https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8014:
Comment: was deleted
(was: trunk: [r1853332|http://svn.apache.org/r1853332])
> Commits carrying over from previous GC generation can block other threads
> from committing
> -
>
> Key: OAK-8014
> URL: https://issues.apache.org/jira/browse/OAK-8014
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.10.0, 1.8.11
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8014.patch
>
>
> A commit that is based on a previous (full) generation can block other
> commits from progressing for a long time. This happens because such a commit
> will do a deep copy of its state to avoid linking to old segments (see
> OAK-3348). Most of the deep copying is usually avoided by the deduplication
> caches. However, in cases where the cache hit rate is not good enough we have
> seen deep copy operations up to several minutes. Sometimes this deep copy
> operation happens inside the commit lock of
> {{LockBasedScheduler.schedule()}}, which then causes all other commits to
> become blocked.
> cc [~rma61...@adobe.com], [~edivad]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-8071. Resolution: Fixed > Logging to detect commits carrying over from previous GC generation can block > other threads from committing > --- > > Key: OAK-8071 > URL: https://issues.apache.org/jira/browse/OAK-8071 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.12, 1.11.0, 1.8.12, 1.10.2 > > > Add logging / monitoring to detect the situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781377#comment-16781377 ] Michael Dürig commented on OAK-8071: Fix for 1.10: http://svn.apache.org/viewvc?rev=1854559=rev Fix for 1.8: http://svn.apache.org/viewvc?rev=1854560=rev > Logging to detect commits carrying over from previous GC generation can block > other threads from committing > --- > > Key: OAK-8071 > URL: https://issues.apache.org/jira/browse/OAK-8071 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.12, 1.11.0, 1.8.12, 1.10.2 > > > Add logging / monitoring to detect the situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8100) Adding the Support for Oak-Segment-Tar-DS to the Server Command
Andreas Schaefer created OAK-8100: - Summary: Adding the Support for Oak-Segment-Tar-DS to the Server Command Key: OAK-8100 URL: https://issues.apache.org/jira/browse/OAK-8100 Project: Jackrabbit Oak Issue Type: Improvement Components: oak-run Affects Versions: 1.10.1 Reporter: Andreas Schaefer Fix For: 1.2.0 Attachments: 0001-Added-Oak-Segment-Tar-DS-as-boot-option-to-Oak-run.patch, ServerCommandTest.java The ServerCommand class is not support Oak-Segment-Tar-DS as startup option. The attached patch and test class is adding this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8099) Build Jackrabbit Oak #1983 failed
Hudson created OAK-8099: --- Summary: Build Jackrabbit Oak #1983 failed Key: OAK-8099 URL: https://issues.apache.org/jira/browse/OAK-8099 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #1983 has failed. First failed run: [Jackrabbit Oak #1983|https://builds.apache.org/job/Jackrabbit%20Oak/1983/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1983/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8089) DocumentNodeStore dispose can fail when duration of final background ops exceeds lease time
[
https://issues.apache.org/jira/browse/OAK-8089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780767#comment-16780767
]
Manfred Baedke commented on OAK-8089:
-
Attached proposed patch oak-8089.patch
> DocumentNodeStore dispose can fail when duration of final background ops
> exceeds lease time
> ---
>
> Key: OAK-8089
> URL: https://issues.apache.org/jira/browse/OAK-8089
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.12
>
> Attachments: oak-8089.patch
>
>
> The problem is that {{dispose()}} let's the {{BackgroundLeaseUpdateThread}}
> run once.
> If the duration of the remaining operations then exceeds the lease update
> interval, these operations will fail with a {{DocumentStoreException}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8089) DocumentNodeStore dispose can fail when duration of final background ops exceeds lease time
[
https://issues.apache.org/jira/browse/OAK-8089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated OAK-8089:
Attachment: oak-8089.patch
> DocumentNodeStore dispose can fail when duration of final background ops
> exceeds lease time
> ---
>
> Key: OAK-8089
> URL: https://issues.apache.org/jira/browse/OAK-8089
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.12
>
> Attachments: oak-8089.patch
>
>
> The problem is that {{dispose()}} let's the {{BackgroundLeaseUpdateThread}}
> run once.
> If the duration of the remaining operations then exceeds the lease update
> interval, these operations will fail with a {{DocumentStoreException}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8091) Build failure: artifact does not exist on remote repository
[
https://issues.apache.org/jira/browse/OAK-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780759#comment-16780759
]
Hudson commented on OAK-8091:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#1982|https://builds.apache.org/job/Jackrabbit%20Oak/1982/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1982/console]
> Build failure: artifact does not exist on remote repository
> ---
>
> Key: OAK-8091
> URL: https://issues.apache.org/jira/browse/OAK-8091
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1979 has failed.
> First failed run: [Jackrabbit Oak
> #1979|https://builds.apache.org/job/Jackrabbit%20Oak/1979/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1979/console]
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.felix:maven-bundle-plugin:3.5.1:baseline (baseline) on project
> oak-commons: Artifact org.apache.jackrabbit:oak-commons:bundle:1.10.1:compile
> does not exist on local/remote repositories: Could not find artifact
> org.apache.jackrabbit:oak-commons:jar:1.10.1 in central
> (https://repo.maven.apache.org/maven2)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8098) oak-examples/webapp: update spring boot dependency to 1.5.19
[ https://issues.apache.org/jira/browse/OAK-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780738#comment-16780738 ] Julian Reschke commented on OAK-8098: - trunk: [r1854539|http://svn.apache.org/r1854539] > oak-examples/webapp: update spring boot dependency to 1.5.19 > > > Key: OAK-8098 > URL: https://issues.apache.org/jira/browse/OAK-8098 > Project: Jackrabbit Oak > Issue Type: Task > Components: examples >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8098) oak-examples/webapp: update spring boot dependency to 1.5.19
[ https://issues.apache.org/jira/browse/OAK-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8098: Labels: candidate_oak_1_10 (was: ) > oak-examples/webapp: update spring boot dependency to 1.5.19 > > > Key: OAK-8098 > URL: https://issues.apache.org/jira/browse/OAK-8098 > Project: Jackrabbit Oak > Issue Type: Task > Components: examples >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8098) oak-examples/webapp: update spring boot dependency to 1.5.19
[ https://issues.apache.org/jira/browse/OAK-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-8098. - Resolution: Fixed Fix Version/s: 1.11.0 > oak-examples/webapp: update spring boot dependency to 1.5.19 > > > Key: OAK-8098 > URL: https://issues.apache.org/jira/browse/OAK-8098 > Project: Jackrabbit Oak > Issue Type: Task > Components: examples >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.12, 1.11.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8098) oak-examples/webapp: update spring boot dependency to 1.5.19
Julian Reschke created OAK-8098: --- Summary: oak-examples/webapp: update spring boot dependency to 1.5.19 Key: OAK-8098 URL: https://issues.apache.org/jira/browse/OAK-8098 Project: Jackrabbit Oak Issue Type: Task Components: examples Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 1.12 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8092) The cold standby server cannot handle blob requests for long blob IDs
[
https://issues.apache.org/jira/browse/OAK-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8092:
-
Fix Version/s: 1.12
> The cold standby server cannot handle blob requests for long blob IDs
> -
>
> Key: OAK-8092
> URL: https://issues.apache.org/jira/browse/OAK-8092
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.10.1
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: cold-standby
> Fix For: 1.12, 1.10.2
>
> Attachments: OAK-8092.patch
>
>
> If the standby client issues a request for a binary ID larger than 8192
> bytes, it will fail on the server side due to the current frame limitation,
> set to 8192 bytes:
> {noformat}
> 28.02.2019 00:01:36.034 *WARN* [primary-32]
> org.apache.jackrabbit.oak.segment.standby.server.ExceptionHandler Exception
> caught on the server
> io.netty.handler.codec.TooLongFrameException: frame length (35029) exceeds
> the allowed maximum (8192)
> at
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:146)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:142)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:131)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:75)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1342)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:934)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
>
[jira] [Commented] (OAK-8097) Load Lucene index files before writing to the index
[
https://issues.apache.org/jira/browse/OAK-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780717#comment-16780717
]
Thomas Mueller commented on OAK-8097:
-
Possible patch, [~catholicon] could you review please? I locally tested it and
the warnings were resolved. It causes the index to be downloaded when I change
indexed content.
{noformat}
Index:
src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnWriteDirectory.java
===
---
src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnWriteDirectory.java
(revision 1853204)
+++
src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnWriteDirectory.java
(working copy)
@@ -428,7 +428,7 @@
if (!validLocalCopyPresent) {
log.warn("COWRemoteFileReference::file ({}) differs in
length. local: {}; remote: {}, init-remote-length",
- localFileLength, remoteFileLength, length);
+ name, localFileLength, remoteFileLength);
}
} else if (!IndexCopier.REMOTE_ONLY.contains(name)) {
log.warn("COWRemoteFileReference::local file ({}) doesn't
exist", name);
Index:
src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/DefaultDirectoryFactory.java
===
---
src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/DefaultDirectoryFactory.java
(revision 1853204)
+++
src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/DefaultDirectoryFactory.java
(working copy)
@@ -37,6 +37,7 @@
import static org.apache.lucene.store.NoLockFactory.getNoLockFactory;
public class DefaultDirectoryFactory implements DirectoryFactory {
+private static final boolean READ_BEFORE_WRITE =
!Boolean.getBoolean("oak.lucene.readBeforeWriteDisabled");
private final IndexCopier indexCopier;
private final GarbageCollectableBlobStore blobStore;
private final BlobDeletionCallback blobDeletionCallback;
@@ -56,6 +57,13 @@
String dirName, boolean reindex) throws
IOException {
Directory directory = newIndexDirectory(definition, builder, dirName);
if (indexCopier != null && !(SUGGEST_DATA_CHILD_NAME.equals(dirName)
&& definition.getUniqueId() == null)) {
+if (READ_BEFORE_WRITE) {
+// prefetch the index when writing to it
+// (copy from the remote directory to the local directory)
+// to avoid having to stream it when merging
+String indexPath = definition.getIndexPath();
+indexCopier.wrapForRead(indexPath, definition, directory,
dirName);
+}
directory = indexCopier.wrapForWrite(definition, directory,
reindex, dirName);
}
return directory;
{noformat}
> Load Lucene index files before writing to the index
> ---
>
> Key: OAK-8097
> URL: https://issues.apache.org/jira/browse/OAK-8097
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Thomas Mueller
>Priority: Major
>
> Right now, Lucene index files are downloaded from the datastore when reading
> from the index (when running a query). However, when updating the index, they
> are not downloaded. So if lazy loading of index files is enabled (OAK-7947),
> files are read from the datastore (streaming). Leading to the following
> warnings in the log file:
> {noformat}
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory
> COWRemoteFileReference::local file (_2.cfs) doesn't exist
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8097) Load Lucene index files before writing to the index
Thomas Mueller created OAK-8097:
---
Summary: Load Lucene index files before writing to the index
Key: OAK-8097
URL: https://issues.apache.org/jira/browse/OAK-8097
Project: Jackrabbit Oak
Issue Type: Improvement
Components: lucene
Reporter: Thomas Mueller
Right now, Lucene index files are downloaded from the datastore when reading
from the index (when running a query). However, when updating the index, they
are not downloaded. So if lazy loading of index files is enabled (OAK-7947),
files are read from the datastore (streaming). Leading to the following
warnings in the log file:
{noformat}
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory
COWRemoteFileReference::local file (_2.cfs) doesn't exist
...
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8092) The cold standby server cannot handle blob requests for long blob IDs
[
https://issues.apache.org/jira/browse/OAK-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8092:
-
Affects Version/s: (was: 1.6.0)
1.10.1
> The cold standby server cannot handle blob requests for long blob IDs
> -
>
> Key: OAK-8092
> URL: https://issues.apache.org/jira/browse/OAK-8092
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.10.1
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: cold-standby
> Fix For: 1.12, 1.8.12, 1.10.2
>
> Attachments: OAK-8092.patch
>
>
> If the standby client issues a request for a binary ID larger than 8192
> bytes, it will fail on the server side due to the current frame limitation,
> set to 8192 bytes:
> {noformat}
> 28.02.2019 00:01:36.034 *WARN* [primary-32]
> org.apache.jackrabbit.oak.segment.standby.server.ExceptionHandler Exception
> caught on the server
> io.netty.handler.codec.TooLongFrameException: frame length (35029) exceeds
> the allowed maximum (8192)
> at
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:146)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:142)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:131)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:75)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1342)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:934)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
>
[jira] [Updated] (OAK-8092) The cold standby server cannot handle blob requests for long blob IDs
[
https://issues.apache.org/jira/browse/OAK-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8092:
-
Fix Version/s: (was: 1.8.12)
(was: 1.12)
> The cold standby server cannot handle blob requests for long blob IDs
> -
>
> Key: OAK-8092
> URL: https://issues.apache.org/jira/browse/OAK-8092
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.10.1
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: cold-standby
> Fix For: 1.10.2
>
> Attachments: OAK-8092.patch
>
>
> If the standby client issues a request for a binary ID larger than 8192
> bytes, it will fail on the server side due to the current frame limitation,
> set to 8192 bytes:
> {noformat}
> 28.02.2019 00:01:36.034 *WARN* [primary-32]
> org.apache.jackrabbit.oak.segment.standby.server.ExceptionHandler Exception
> caught on the server
> io.netty.handler.codec.TooLongFrameException: frame length (35029) exceeds
> the allowed maximum (8192)
> at
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:146)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:142)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:131)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:75)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1342)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:934)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
>
[jira] [Updated] (OAK-8089) DocumentNodeStore dispose can fail when duration of final background ops exceeds lease time
[
https://issues.apache.org/jira/browse/OAK-8089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8089:
Description:
The problem is that {{dispose()}} let's the {{BackgroundLeaseUpdateThread}} run
once.
If the duration of the remaining operations then exceeds the lease update
interval, these operations will fail with a {{DocumentStoreException}}.
was:
The problem is that {{dispose()}} let's the {{BackgroundLeaseUpdateThread}}
once.
If the duration of the remaining operations then exceeds the lease update
interval, these operations will fail with a {{DocumentStoreException}}.
> DocumentNodeStore dispose can fail when duration of final background ops
> exceeds lease time
> ---
>
> Key: OAK-8089
> URL: https://issues.apache.org/jira/browse/OAK-8089
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.12
>
>
> The problem is that {{dispose()}} let's the {{BackgroundLeaseUpdateThread}}
> run once.
> If the duration of the remaining operations then exceeds the lease update
> interval, these operations will fail with a {{DocumentStoreException}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8091) Build failure: artifact does not exist on remote repository
[
https://issues.apache.org/jira/browse/OAK-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780668#comment-16780668
]
Hudson commented on OAK-8091:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#1981|https://builds.apache.org/job/Jackrabbit%20Oak/1981/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1981/console]
> Build failure: artifact does not exist on remote repository
> ---
>
> Key: OAK-8091
> URL: https://issues.apache.org/jira/browse/OAK-8091
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1979 has failed.
> First failed run: [Jackrabbit Oak
> #1979|https://builds.apache.org/job/Jackrabbit%20Oak/1979/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1979/console]
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.felix:maven-bundle-plugin:3.5.1:baseline (baseline) on project
> oak-commons: Artifact org.apache.jackrabbit:oak-commons:bundle:1.10.1:compile
> does not exist on local/remote repositories: Could not find artifact
> org.apache.jackrabbit:oak-commons:jar:1.10.1 in central
> (https://repo.maven.apache.org/maven2)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8094) JMX monitoring to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780632#comment-16780632 ] Axel Hanikel commented on OAK-8094: --- [~mduerig] perhaps we could make the link between the otherWritersLimit parameter in the CommitsTracker, the number of iterations in the for loop, and the min value more clear as in [https://github.com/ahanikel/jackrabbit-oak/commit/c9b20741d2c12b9360da8352d212b116956ba721] - otherwise I'd say: nihil obstat :) > JMX monitoring to detect commits carrying over from previous GC generation > can block other threads from committing > -- > > Key: OAK-8094 > URL: https://issues.apache.org/jira/browse/OAK-8094 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Major > Fix For: 1.12 > > > This is a follow up of OAK-8071 to implement JMX monitoring to detect the > situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8096) CompositeAccessControlManager: misleading local field name
[
https://issues.apache.org/jira/browse/OAK-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-8096.
-
Resolution: Fixed
Fix Version/s: 1.11.0
1.12
Committed revision 1854535.
> CompositeAccessControlManager: misleading local field name
> --
>
> Key: OAK-8096
> URL: https://issues.apache.org/jira/browse/OAK-8096
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Trivial
> Fix For: 1.12, 1.11.0
>
>
> the {{CompositeAccessControlManager}} contains methods that collect policies
> from the aggregated ac-mgr implementations. unfortunately the local fields
> have a misleading name. should rather be 'policies' than 'privs'.
> [~stillalex], fyi
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8094) JMX monitoring to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780643#comment-16780643 ] Michael Dürig commented on OAK-8094: Good point. Just merged this to https://github.com/mduerig/jackrabbit-oak/commits/OAK-8071-2 > JMX monitoring to detect commits carrying over from previous GC generation > can block other threads from committing > -- > > Key: OAK-8094 > URL: https://issues.apache.org/jira/browse/OAK-8094 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Major > Fix For: 1.12 > > > This is a follow up of OAK-8071 to implement JMX monitoring to detect the > situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8095) VersionStorageEditor can prevent upgrade of version store
[ https://issues.apache.org/jira/browse/OAK-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu resolved OAK-8095. --- Resolution: Fixed Fix Version/s: 1.11.0 1.12 fixed with http://svn.apache.org/viewvc?rev=1854533=rev Thanks to [~mreutegg] for the help in debugging this one! > VersionStorageEditor can prevent upgrade of version store > - > > Key: OAK-8095 > URL: https://issues.apache.org/jira/browse/OAK-8095 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.10.0, 1.10.1 >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0 > > > Followup of OAK-7532, the code that detects an initial startup can miss some > setups, failing legal commits like upgrades. > So far it looks like this only affects direct Oak 1.0 -> 1.10 upgrades, in > cases where the version store has some data at the moment of the upgrade. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8096) CompositeAccessControlManager: misleading local field name
[
https://issues.apache.org/jira/browse/OAK-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8096:
Component/s: security
core
> CompositeAccessControlManager: misleading local field name
> --
>
> Key: OAK-8096
> URL: https://issues.apache.org/jira/browse/OAK-8096
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Trivial
>
> the {{CompositeAccessControlManager}} contains methods that collect policies
> from the aggregated ac-mgr implementations. unfortunately the local fields
> have a misleading name. should rather be 'policies' than 'privs'.
> [~stillalex], fyi
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8095) VersionStorageEditor can prevent upgrade of version store
[ https://issues.apache.org/jira/browse/OAK-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8095: -- Description: Followup of OAK-7532, the code that detects an initial startup can miss some setups, failing legal commits like upgrades. So far it looks like this only affects direct Oak 1.0 -> 1.10 upgrades, in cases where the version store has some data at the moment of the upgrade. was:Followup of OAK-7532, the code that detects an initial startup can miss some setups, failing legal commits like upgrades. > VersionStorageEditor can prevent upgrade of version store > - > > Key: OAK-8095 > URL: https://issues.apache.org/jira/browse/OAK-8095 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.10.0, 1.10.1 >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Labels: candidate_oak_1_10 > > Followup of OAK-7532, the code that detects an initial startup can miss some > setups, failing legal commits like upgrades. > So far it looks like this only affects direct Oak 1.0 -> 1.10 upgrades, in > cases where the version store has some data at the moment of the upgrade. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8096) CompositeAccessControlManager: misleading local field name
angela created OAK-8096:
---
Summary: CompositeAccessControlManager: misleading local field name
Key: OAK-8096
URL: https://issues.apache.org/jira/browse/OAK-8096
Project: Jackrabbit Oak
Issue Type: Improvement
Reporter: angela
Assignee: angela
the {{CompositeAccessControlManager}} contains methods that collect policies
from the aggregated ac-mgr implementations. unfortunately the local fields have
a misleading name. should rather be 'policies' than 'privs'.
[~stillalex], fyi
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8093) AccessControlManagerImpl: respect local namespaces when writing back ACEs
[
https://issues.apache.org/jira/browse/OAK-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8093:
Priority: Minor (was: Trivial)
> AccessControlManagerImpl: respect local namespaces when writing back ACEs
> -
>
> Key: OAK-8093
> URL: https://issues.apache.org/jira/browse/OAK-8093
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Attachments: OAK-8093.patch
>
>
> [~stillalex], i noticed that the {{AccessControlManager}} doesn't properly
> handle local namespaces when writing back ACEs. This may lead to
> {{CommitFailedException}} or incomplete permission setup.
> Patch for review will follow as well as tests illustrating the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8062) PrincipalProvider: optional lookup of ItemBasedPrincipal by path
[
https://issues.apache.org/jira/browse/OAK-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780596#comment-16780596
]
angela edited comment on OAK-8062 at 2/28/19 2:53 PM:
--
[~stillalex], sure :-) used your variant.
was (Author: anchela):
[~stillalex], sure :-) will use your variant.
> PrincipalProvider: optional lookup of ItemBasedPrincipal by path
>
>
> Key: OAK-8062
> URL: https://issues.apache.org/jira/browse/OAK-8062
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, security, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8062.patch
>
>
> while there exists API to check if a given {{Principal}} is backed by an
> {{Item}} in the repository (see {{ItemBasedPrincipal.getPath}}, we currently
> lack the ability to retrieve these principals by path. In other words the
> round trip is incomplete and forces consumers the workaround by involving
> user management API, which may or may not work depending on the
> implementation details of the underlying {{PrincipalProvider}}.
> the suggested extension would (in correspondence to the recent search
> extensions) be made optional by adding a default implementation to the
> {{PrincipalProvider}} interface.
> [~stillalex], will attach an initial patch. feedback both on the proposal and
> on the patch welcome as always.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8062) PrincipalProvider: optional lookup of ItemBasedPrincipal by path
[
https://issues.apache.org/jira/browse/OAK-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780596#comment-16780596
]
angela commented on OAK-8062:
-
[~stillalex], sure :-) will use your variant.
> PrincipalProvider: optional lookup of ItemBasedPrincipal by path
>
>
> Key: OAK-8062
> URL: https://issues.apache.org/jira/browse/OAK-8062
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, security, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8062.patch
>
>
> while there exists API to check if a given {{Principal}} is backed by an
> {{Item}} in the repository (see {{ItemBasedPrincipal.getPath}}, we currently
> lack the ability to retrieve these principals by path. In other words the
> round trip is incomplete and forces consumers the workaround by involving
> user management API, which may or may not work depending on the
> implementation details of the underlying {{PrincipalProvider}}.
> the suggested extension would (in correspondence to the recent search
> extensions) be made optional by adding a default implementation to the
> {{PrincipalProvider}} interface.
> [~stillalex], will attach an initial patch. feedback both on the proposal and
> on the patch welcome as always.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8062) PrincipalProvider: optional lookup of ItemBasedPrincipal by path
[
https://issues.apache.org/jira/browse/OAK-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8062:
Component/s: security
> PrincipalProvider: optional lookup of ItemBasedPrincipal by path
>
>
> Key: OAK-8062
> URL: https://issues.apache.org/jira/browse/OAK-8062
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, security, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8062.patch
>
>
> while there exists API to check if a given {{Principal}} is backed by an
> {{Item}} in the repository (see {{ItemBasedPrincipal.getPath}}, we currently
> lack the ability to retrieve these principals by path. In other words the
> round trip is incomplete and forces consumers the workaround by involving
> user management API, which may or may not work depending on the
> implementation details of the underlying {{PrincipalProvider}}.
> the suggested extension would (in correspondence to the recent search
> extensions) be made optional by adding a default implementation to the
> {{PrincipalProvider}} interface.
> [~stillalex], will attach an initial patch. feedback both on the proposal and
> on the patch welcome as always.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8095) VersionStorageEditor can prevent upgrade of version store
[ https://issues.apache.org/jira/browse/OAK-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8095: -- Issue Type: Bug (was: Improvement) > VersionStorageEditor can prevent upgrade of version store > - > > Key: OAK-8095 > URL: https://issues.apache.org/jira/browse/OAK-8095 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.10.0, 1.10.1 >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > > Followup of OAK-7532, the code that detects an initial startup can miss some > setups, failing legal commits like upgrades. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8095) VersionStorageEditor can prevent upgrade of version store
[ https://issues.apache.org/jira/browse/OAK-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8095: -- Labels: candidate_oak_1_10 (was: ) > VersionStorageEditor can prevent upgrade of version store > - > > Key: OAK-8095 > URL: https://issues.apache.org/jira/browse/OAK-8095 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.10.0, 1.10.1 >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Labels: candidate_oak_1_10 > > Followup of OAK-7532, the code that detects an initial startup can miss some > setups, failing legal commits like upgrades. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8062) PrincipalProvider: optional lookup of ItemBasedPrincipal by path
[
https://issues.apache.org/jira/browse/OAK-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-8062.
-
Resolution: Fixed
Fix Version/s: 1.11.0
1.12
Committed revision 1854530.
> PrincipalProvider: optional lookup of ItemBasedPrincipal by path
>
>
> Key: OAK-8062
> URL: https://issues.apache.org/jira/browse/OAK-8062
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8062.patch
>
>
> while there exists API to check if a given {{Principal}} is backed by an
> {{Item}} in the repository (see {{ItemBasedPrincipal.getPath}}, we currently
> lack the ability to retrieve these principals by path. In other words the
> round trip is incomplete and forces consumers the workaround by involving
> user management API, which may or may not work depending on the
> implementation details of the underlying {{PrincipalProvider}}.
> the suggested extension would (in correspondence to the recent search
> extensions) be made optional by adding a default implementation to the
> {{PrincipalProvider}} interface.
> [~stillalex], will attach an initial patch. feedback both on the proposal and
> on the patch welcome as always.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8095) VersionStorageEditor can prevent upgrade of version store
Alex Deparvu created OAK-8095: - Summary: VersionStorageEditor can prevent upgrade of version store Key: OAK-8095 URL: https://issues.apache.org/jira/browse/OAK-8095 Project: Jackrabbit Oak Issue Type: Improvement Components: core Affects Versions: 1.10.1, 1.10.0 Reporter: Alex Deparvu Assignee: Alex Deparvu Followup of OAK-7532, the code that detects an initial startup can miss some setups, failing legal commits like upgrades. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780553#comment-16780553 ] Michael Dürig commented on OAK-8071: [~reschke], this should still be blocking the release for the 1.10 and 1.8 branches. This I'd rather leave it open until backported. ETA: tomorrow morning (UTC+1). > Logging to detect commits carrying over from previous GC generation can block > other threads from committing > --- > > Key: OAK-8071 > URL: https://issues.apache.org/jira/browse/OAK-8071 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.12, 1.11.0, 1.8.12, 1.10.2 > > > Add logging / monitoring to detect the situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780553#comment-16780553 ] Michael Dürig edited comment on OAK-8071 at 2/28/19 2:13 PM: - [~reschke], this should still be blocking the release for the 1.10 and 1.8 branches. Thus I'd rather leave it open until backported. ETA: tomorrow morning (UTC+1). was (Author: mduerig): [~reschke], this should still be blocking the release for the 1.10 and 1.8 branches. This I'd rather leave it open until backported. ETA: tomorrow morning (UTC+1). > Logging to detect commits carrying over from previous GC generation can block > other threads from committing > --- > > Key: OAK-8071 > URL: https://issues.apache.org/jira/browse/OAK-8071 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.12, 1.11.0, 1.8.12, 1.10.2 > > > Add logging / monitoring to detect the situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8088) Add refresh head revision time to background update stats
[ https://issues.apache.org/jira/browse/OAK-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780446#comment-16780446 ] Julian Reschke edited comment on OAK-8088 at 2/28/19 1:39 PM: -- trunk: [r1854466|http://svn.apache.org/r1854466] 1.10: [r1854520|http://svn.apache.org/r1854520] 1.8: [r1854525|http://svn.apache.org/r1854525] was (Author: reschke): trunk: [r1854466|http://svn.apache.org/r1854466] 1.10: [r1854520|http://svn.apache.org/r1854520] > Add refresh head revision time to background update stats > - > > Key: OAK-8088 > URL: https://issues.apache.org/jira/browse/OAK-8088 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_6 > Fix For: 1.12, 1.11.0, 1.8.12, 1.10.2 > > > The background update stats does not have timing information for refreshing > the head revision. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780532#comment-16780532 ] Julian Reschke commented on OAK-8071: - If this is fixed in trunk, the ticket should be set to "resolved". > Logging to detect commits carrying over from previous GC generation can block > other threads from committing > --- > > Key: OAK-8071 > URL: https://issues.apache.org/jira/browse/OAK-8071 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.12, 1.11.0, 1.8.12, 1.10.2 > > > Add logging / monitoring to detect the situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8088) Add refresh head revision time to background update stats
[ https://issues.apache.org/jira/browse/OAK-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8088: Labels: candidate_oak_1_6 (was: candidate_oak_1_8) > Add refresh head revision time to background update stats > - > > Key: OAK-8088 > URL: https://issues.apache.org/jira/browse/OAK-8088 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_6 > Fix For: 1.12, 1.11.0, 1.8.12, 1.10.2 > > > The background update stats does not have timing information for refreshing > the head revision. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8088) Add refresh head revision time to background update stats
[ https://issues.apache.org/jira/browse/OAK-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8088: Fix Version/s: 1.8.12 > Add refresh head revision time to background update stats > - > > Key: OAK-8088 > URL: https://issues.apache.org/jira/browse/OAK-8088 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12, 1.11.0, 1.8.12, 1.10.2 > > > The background update stats does not have timing information for refreshing > the head revision. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8080) RDB*Store: move DB-specific config hints from Javadoc into oak-doc
[ https://issues.apache.org/jira/browse/OAK-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777935#comment-16777935 ] Julian Reschke edited comment on OAK-8080 at 2/28/19 1:29 PM: -- trunk: [r1854403|http://svn.apache.org/r1854403] [r1854401|http://svn.apache.org/r1854401] [r1854385|http://svn.apache.org/r1854385] [r1854380|http://svn.apache.org/r1854380] [r1854377|http://svn.apache.org/r1854377] [r1854373|http://svn.apache.org/r1854373] 1.10: [r1854524|http://svn.apache.org/r1854524] was (Author: reschke): trunk: [r1854403|http://svn.apache.org/r1854403] [r1854401|http://svn.apache.org/r1854401] [r1854385|http://svn.apache.org/r1854385] [r1854380|http://svn.apache.org/r1854380] [r1854377|http://svn.apache.org/r1854377] [r1854373|http://svn.apache.org/r1854373] > RDB*Store: move DB-specific config hints from Javadoc into oak-doc > -- > > Key: OAK-8080 > URL: https://issues.apache.org/jira/browse/OAK-8080 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: doc, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12, 1.11.0, 1.10.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8080) RDB*Store: move DB-specific config hints from Javadoc into oak-doc
[ https://issues.apache.org/jira/browse/OAK-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8080: Labels: candidate_oak_1_8 (was: candidate_oak_1_10) > RDB*Store: move DB-specific config hints from Javadoc into oak-doc > -- > > Key: OAK-8080 > URL: https://issues.apache.org/jira/browse/OAK-8080 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: doc, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12, 1.11.0, 1.10.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8080) RDB*Store: move DB-specific config hints from Javadoc into oak-doc
[ https://issues.apache.org/jira/browse/OAK-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8080: Fix Version/s: 1.10.2 > RDB*Store: move DB-specific config hints from Javadoc into oak-doc > -- > > Key: OAK-8080 > URL: https://issues.apache.org/jira/browse/OAK-8080 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: doc, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0, 1.10.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8093) AccessControlManagerImpl: respect local namespaces when writing back ACEs
[
https://issues.apache.org/jira/browse/OAK-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8093:
Attachment: OAK-8093.patch
> AccessControlManagerImpl: respect local namespaces when writing back ACEs
> -
>
> Key: OAK-8093
> URL: https://issues.apache.org/jira/browse/OAK-8093
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Trivial
> Attachments: OAK-8093.patch
>
>
> [~stillalex], i noticed that the {{AccessControlManager}} doesn't properly
> handle local namespaces when writing back ACEs. This may lead to
> {{CommitFailedException}} or incomplete permission setup.
> Patch for review will follow as well as tests illustrating the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8093) AccessControlManagerImpl: respect local namespaces when writing back ACEs
[
https://issues.apache.org/jira/browse/OAK-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780503#comment-16780503
]
angela commented on OAK-8093:
-
[~stillalex], proposed fix attached.
> AccessControlManagerImpl: respect local namespaces when writing back ACEs
> -
>
> Key: OAK-8093
> URL: https://issues.apache.org/jira/browse/OAK-8093
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Trivial
> Attachments: OAK-8093.patch
>
>
> [~stillalex], i noticed that the {{AccessControlManager}} doesn't properly
> handle local namespaces when writing back ACEs. This may lead to
> {{CommitFailedException}} or incomplete permission setup.
> Patch for review will follow as well as tests illustrating the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8092) The cold standby server cannot handle blob requests for long blob IDs
[
https://issues.apache.org/jira/browse/OAK-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780461#comment-16780461
]
Andrei Dulceanu commented on OAK-8092:
--
In the patch attached I propose to increase the maximum frame length of
{{LineBasedFrameDecoder}} in {{StandbyServer}} to {{Integer.MAX_VALUE}}.
[~frm], wdyt? Is there a more appropriate upper bound for it in the light of
long blob IDs?
> The cold standby server cannot handle blob requests for long blob IDs
> -
>
> Key: OAK-8092
> URL: https://issues.apache.org/jira/browse/OAK-8092
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.6.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: cold-standby
> Fix For: 1.12, 1.8.12, 1.10.2
>
> Attachments: OAK-8092.patch
>
>
> If the standby client issues a request for a binary ID larger than 8192
> bytes, it will fail on the server side due to the current frame limitation,
> set to 8192 bytes:
> {noformat}
> 28.02.2019 00:01:36.034 *WARN* [primary-32]
> org.apache.jackrabbit.oak.segment.standby.server.ExceptionHandler Exception
> caught on the server
> io.netty.handler.codec.TooLongFrameException: frame length (35029) exceeds
> the allowed maximum (8192)
> at
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:146)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:142)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:131)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:75)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1342)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:934)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
>
[jira] [Updated] (OAK-8092) The cold standby server cannot handle blob requests for long blob IDs
[
https://issues.apache.org/jira/browse/OAK-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8092:
-
Attachment: OAK-8092.patch
> The cold standby server cannot handle blob requests for long blob IDs
> -
>
> Key: OAK-8092
> URL: https://issues.apache.org/jira/browse/OAK-8092
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.6.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: cold-standby
> Fix For: 1.12, 1.8.12, 1.10.2
>
> Attachments: OAK-8092.patch
>
>
> If the standby client issues a request for a binary ID larger than 8192
> bytes, it will fail on the server side due to the current frame limitation,
> set to 8192 bytes:
> {noformat}
> 28.02.2019 00:01:36.034 *WARN* [primary-32]
> org.apache.jackrabbit.oak.segment.standby.server.ExceptionHandler Exception
> caught on the server
> io.netty.handler.codec.TooLongFrameException: frame length (35029) exceeds
> the allowed maximum (8192)
> at
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:146)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:142)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:131)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:75)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1342)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:934)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at
>
[jira] [Commented] (OAK-8088) Add refresh head revision time to background update stats
[ https://issues.apache.org/jira/browse/OAK-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780446#comment-16780446 ] Julian Reschke commented on OAK-8088: - trunk: [r1854466|http://svn.apache.org/r1854466] 1.10: [r1854520|http://svn.apache.org/r1854520] > Add refresh head revision time to background update stats > - > > Key: OAK-8088 > URL: https://issues.apache.org/jira/browse/OAK-8088 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12, 1.11.0, 1.10.2 > > > The background update stats does not have timing information for refreshing > the head revision. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8088) Add refresh head revision time to background update stats
[ https://issues.apache.org/jira/browse/OAK-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8088: Labels: candidate_oak_1_8 (was: candidate_oak_1_10) > Add refresh head revision time to background update stats > - > > Key: OAK-8088 > URL: https://issues.apache.org/jira/browse/OAK-8088 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12, 1.11.0, 1.10.2 > > > The background update stats does not have timing information for refreshing > the head revision. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8088) Add refresh head revision time to background update stats
[ https://issues.apache.org/jira/browse/OAK-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8088: Fix Version/s: 1.10.2 > Add refresh head revision time to background update stats > - > > Key: OAK-8088 > URL: https://issues.apache.org/jira/browse/OAK-8088 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0, 1.10.2 > > > The background update stats does not have timing information for refreshing > the head revision. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8063) The cold standby client doesn't correctly handle backward references
[
https://issues.apache.org/jira/browse/OAK-8063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780439#comment-16780439
]
Andrei Dulceanu commented on OAK-8063:
--
In my previous patch I somehow misinterpreted the edge direction between
segments and their references. Therefore, by using a stack for storing the
final transfer order, I actually achieved the opposite: a segment transferred
before all its references. I came back to this and replaced the stack with a
linked list to fix this behaviour. Moreover, I added an explanation and the
same logging we had in the original code.
[~frm], could you please take a look at the second version of the patch?
> The cold standby client doesn't correctly handle backward references
>
>
> Key: OAK-8063
> URL: https://issues.apache.org/jira/browse/OAK-8063
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.6.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: cold-standby
> Fix For: 1.12, 1.8.12, 1.10.2
>
> Attachments: OAK-8063-02.patch, OAK-8063.patch
>
>
> The logic from {{StandbyClientSyncExecution#copySegmentHierarchyFromPrimary}}
> has a flaw when it comes to "backward references". Suppose we have the
> following data segment graph to be transferred from primary: S1, which
> references \{S2, S3} and S3 which references S2. Then, the correct transfer
> order should be S2, S3 and S1.
> Going through the current logic employed by the method, here's what happens:
> {noformat}
> Step 0: batch={S1}
> Step 1: visited={S1}, data={S1}, batch={S2, S3}, queued={S2, S3}
> Step 2: visited={S1, S2}, data={S2, S1}, batch={S3}, queued={S2, S3}
> Step 3: visited={S1, S2, S3}, data={S3, S2, S1}, batch={}, queued={S2,
> S3}.{noformat}
> Therefore, at the end of the loop, the order of the segments to be
> transferred will be S3, S2, S1, which might trigger a
> {{SegmentNotFoundException}} when S3 is further processed, because S2 is
> missing on standby (see OAK-8006).
> /cc [~frm]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8063) The cold standby client doesn't correctly handle backward references
[
https://issues.apache.org/jira/browse/OAK-8063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8063:
-
Attachment: OAK-8063-02.patch
> The cold standby client doesn't correctly handle backward references
>
>
> Key: OAK-8063
> URL: https://issues.apache.org/jira/browse/OAK-8063
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Affects Versions: 1.6.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: cold-standby
> Fix For: 1.12, 1.8.12, 1.10.2
>
> Attachments: OAK-8063-02.patch, OAK-8063.patch
>
>
> The logic from {{StandbyClientSyncExecution#copySegmentHierarchyFromPrimary}}
> has a flaw when it comes to "backward references". Suppose we have the
> following data segment graph to be transferred from primary: S1, which
> references \{S2, S3} and S3 which references S2. Then, the correct transfer
> order should be S2, S3 and S1.
> Going through the current logic employed by the method, here's what happens:
> {noformat}
> Step 0: batch={S1}
> Step 1: visited={S1}, data={S1}, batch={S2, S3}, queued={S2, S3}
> Step 2: visited={S1, S2}, data={S2, S1}, batch={S3}, queued={S2, S3}
> Step 3: visited={S1, S2, S3}, data={S3, S2, S1}, batch={}, queued={S2,
> S3}.{noformat}
> Therefore, at the end of the loop, the order of the segments to be
> transferred will be S3, S2, S1, which might trigger a
> {{SegmentNotFoundException}} when S3 is further processed, because S2 is
> missing on standby (see OAK-8006).
> /cc [~frm]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780390#comment-16780390 ] Michael Dürig commented on OAK-8071: I filed OAK-8094 to follow up on the JMX part. > Logging to detect commits carrying over from previous GC generation can block > other threads from committing > --- > > Key: OAK-8071 > URL: https://issues.apache.org/jira/browse/OAK-8071 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.12, 1.11.0, 1.8.12, 1.10.2 > > > Add logging / monitoring to detect the situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8094) JMX monitoring to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780388#comment-16780388 ] Michael Dürig commented on OAK-8094: Proposed changes: https://github.com/mduerig/jackrabbit-oak/commits/OAK-8071-2 [~ahanikel], [~dulceanu], could you do a final round of review? If no objections I'd suggest to commit this to trunk. > JMX monitoring to detect commits carrying over from previous GC generation > can block other threads from committing > -- > > Key: OAK-8094 > URL: https://issues.apache.org/jira/browse/OAK-8094 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Michael Dürig >Priority: Major > > This is a follow up of OAK-8071 to implement JMX monitoring to detect the > situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OAK-8094) JMX monitoring to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig reassigned OAK-8094: -- Assignee: Michael Dürig > JMX monitoring to detect commits carrying over from previous GC generation > can block other threads from committing > -- > > Key: OAK-8094 > URL: https://issues.apache.org/jira/browse/OAK-8094 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Major > Fix For: 1.12 > > > This is a follow up of OAK-8071 to implement JMX monitoring to detect the > situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8094) JMX monitoring to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-8094: --- Fix Version/s: 1.12 > JMX monitoring to detect commits carrying over from previous GC generation > can block other threads from committing > -- > > Key: OAK-8094 > URL: https://issues.apache.org/jira/browse/OAK-8094 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Michael Dürig >Priority: Major > Fix For: 1.12 > > > This is a follow up of OAK-8071 to implement JMX monitoring to detect the > situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8094) JMX monitoring to detect commits carrying over from previous GC generation can block other threads from committing
Michael Dürig created OAK-8094: -- Summary: JMX monitoring to detect commits carrying over from previous GC generation can block other threads from committing Key: OAK-8094 URL: https://issues.apache.org/jira/browse/OAK-8094 Project: Jackrabbit Oak Issue Type: Improvement Components: segment-tar Reporter: Michael Dürig This is a follow up of OAK-8071 to implement JMX monitoring to detect the situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8093) AccessControlManagerImpl: respect local namespaces when writing back ACEs
angela created OAK-8093:
---
Summary: AccessControlManagerImpl: respect local namespaces when
writing back ACEs
Key: OAK-8093
URL: https://issues.apache.org/jira/browse/OAK-8093
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, security
Reporter: angela
Assignee: angela
[~stillalex], i noticed that the {{AccessControlManager}} doesn't properly
handle local namespaces when writing back ACEs. This may lead to
{{CommitFailedException}} or incomplete permission setup.
Patch for review will follow as well as tests illustrating the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8087) RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8
[ https://issues.apache.org/jira/browse/OAK-8087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779467#comment-16779467 ] Julian Reschke edited comment on OAK-8087 at 2/28/19 10:27 AM: --- trunk: [r1854468|http://svn.apache.org/r1854468] 1.10: [r1854516|http://svn.apache.org/r1854516] was (Author: reschke): trunk: [r1854468|http://svn.apache.org/r1854468] > RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8 > --- > > Key: OAK-8087 > URL: https://issues.apache.org/jira/browse/OAK-8087 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12, 1.11.0, 1.10.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8087) RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8
[ https://issues.apache.org/jira/browse/OAK-8087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8087: Labels: candidate_oak_1_8 (was: candidate_oak_1_10) > RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8 > --- > > Key: OAK-8087 > URL: https://issues.apache.org/jira/browse/OAK-8087 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12, 1.11.0, 1.10.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8087) RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8
[ https://issues.apache.org/jira/browse/OAK-8087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8087: Fix Version/s: 1.10.2 > RDB*Store: update mssql-jdbc driver reference to 7.2.1.jre8 > --- > > Key: OAK-8087 > URL: https://issues.apache.org/jira/browse/OAK-8087 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0, 1.10.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8091) Build failure: artifact does not exist on remote repository
[
https://issues.apache.org/jira/browse/OAK-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780333#comment-16780333
]
Hudson commented on OAK-8091:
-
Build is still failing.
Failed run: [Jackrabbit Oak
#1980|https://builds.apache.org/job/Jackrabbit%20Oak/1980/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1980/console]
> Build failure: artifact does not exist on remote repository
> ---
>
> Key: OAK-8091
> URL: https://issues.apache.org/jira/browse/OAK-8091
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1979 has failed.
> First failed run: [Jackrabbit Oak
> #1979|https://builds.apache.org/job/Jackrabbit%20Oak/1979/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1979/console]
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.felix:maven-bundle-plugin:3.5.1:baseline (baseline) on project
> oak-commons: Artifact org.apache.jackrabbit:oak-commons:bundle:1.10.1:compile
> does not exist on local/remote repositories: Could not find artifact
> org.apache.jackrabbit:oak-commons:jar:1.10.1 in central
> (https://repo.maven.apache.org/maven2)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780330#comment-16780330 ] Michael Dürig commented on OAK-8071: Fixed in trunk at http://svn.apache.org/viewvc?rev=1854515=rev > Logging to detect commits carrying over from previous GC generation can block > other threads from committing > --- > > Key: OAK-8071 > URL: https://issues.apache.org/jira/browse/OAK-8071 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.12, 1.11.0, 1.8.12, 1.10.2 > > > Add logging / monitoring to detect the situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8092) The cold standby server cannot handle blob requests for long blob IDs
[
https://issues.apache.org/jira/browse/OAK-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8092:
-
Description:
If the standby client issues a request for a binary ID larger than 8192 bytes,
it will fail on the server side due to the current frame limitation, set to
8192 bytes:
{noformat}
28.02.2019 00:01:36.034 *WARN* [primary-32]
org.apache.jackrabbit.oak.segment.standby.server.ExceptionHandler Exception
caught on the server
io.netty.handler.codec.TooLongFrameException: frame length (35029) exceeds the
allowed maximum (8192)
at
io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:146)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:142)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:131)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:75)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1342)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:934)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
was:
If the standby client issues a request for a binary ID larger than 8092 bytes,
it will fail on the server side due to the current frame limitation, set to
8092 bytes:
{noformat}
28.02.2019 00:01:36.034 *WARN* [primary-32]
org.apache.jackrabbit.oak.segment.standby.server.ExceptionHandler Exception
caught on the server
io.netty.handler.codec.TooLongFrameException: frame length (35029) exceeds the
allowed maximum (8192)
at
io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:146)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
[jira] [Created] (OAK-8092) The cold standby server cannot handle blob requests for long blob IDs
Andrei Dulceanu created OAK-8092:
Summary: The cold standby server cannot handle blob requests for
long blob IDs
Key: OAK-8092
URL: https://issues.apache.org/jira/browse/OAK-8092
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-tar, tarmk-standby
Affects Versions: 1.6.0
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Fix For: 1.12, 1.8.12, 1.10.2
If the standby client issues a request for a binary ID larger than 8092 bytes,
it will fail on the server side due to the current frame limitation, set to
8092 bytes:
{noformat}
28.02.2019 00:01:36.034 *WARN* [primary-32]
org.apache.jackrabbit.oak.segment.standby.server.ExceptionHandler Exception
caught on the server
io.netty.handler.codec.TooLongFrameException: frame length (35029) exceeds the
allowed maximum (8192)
at
io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:146)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:142)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:131)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:75)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1342)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:934)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
[org.apache.jackrabbit.oak-segment-tar:1.10.1]
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8091) Build failure: artifact does not exist on remote repository
[
https://issues.apache.org/jira/browse/OAK-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-8091:
--
Summary: Build failure: artifact does not exist on remote repository (was:
Build Jackrabbit Oak #1979 failed)
> Build failure: artifact does not exist on remote repository
> ---
>
> Key: OAK-8091
> URL: https://issues.apache.org/jira/browse/OAK-8091
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1979 has failed.
> First failed run: [Jackrabbit Oak
> #1979|https://builds.apache.org/job/Jackrabbit%20Oak/1979/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1979/console]
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.felix:maven-bundle-plugin:3.5.1:baseline (baseline) on project
> oak-commons: Artifact org.apache.jackrabbit:oak-commons:bundle:1.10.1:compile
> does not exist on local/remote repositories: Could not find artifact
> org.apache.jackrabbit:oak-commons:jar:1.10.1 in central
> (https://repo.maven.apache.org/maven2)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8091) Build Jackrabbit Oak #1979 failed
[
https://issues.apache.org/jira/browse/OAK-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-8091:
--
Description:
No description is provided
The build Jackrabbit Oak #1979 has failed.
First failed run: [Jackrabbit Oak
#1979|https://builds.apache.org/job/Jackrabbit%20Oak/1979/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1979/console]
{noformat}
[ERROR] Failed to execute goal
org.apache.felix:maven-bundle-plugin:3.5.1:baseline (baseline) on project
oak-commons: Artifact org.apache.jackrabbit:oak-commons:bundle:1.10.1:compile
does not exist on local/remote repositories: Could not find artifact
org.apache.jackrabbit:oak-commons:jar:1.10.1 in central
(https://repo.maven.apache.org/maven2)
{noformat}
was:
No description is provided
The build Jackrabbit Oak #1979 has failed.
First failed run: [Jackrabbit Oak
#1979|https://builds.apache.org/job/Jackrabbit%20Oak/1979/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1979/console]
> Build Jackrabbit Oak #1979 failed
> -
>
> Key: OAK-8091
> URL: https://issues.apache.org/jira/browse/OAK-8091
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1979 has failed.
> First failed run: [Jackrabbit Oak
> #1979|https://builds.apache.org/job/Jackrabbit%20Oak/1979/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1979/console]
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.felix:maven-bundle-plugin:3.5.1:baseline (baseline) on project
> oak-commons: Artifact org.apache.jackrabbit:oak-commons:bundle:1.10.1:compile
> does not exist on local/remote repositories: Could not find artifact
> org.apache.jackrabbit:oak-commons:jar:1.10.1 in central
> (https://repo.maven.apache.org/maven2)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8091) Build Jackrabbit Oak #1979 failed
[
https://issues.apache.org/jira/browse/OAK-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780267#comment-16780267
]
Marcel Reutegger commented on OAK-8091:
---
Looks like the 1.10.1 release is not yet available on repo.maven.apache.org
> Build Jackrabbit Oak #1979 failed
> -
>
> Key: OAK-8091
> URL: https://issues.apache.org/jira/browse/OAK-8091
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1979 has failed.
> First failed run: [Jackrabbit Oak
> #1979|https://builds.apache.org/job/Jackrabbit%20Oak/1979/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1979/console]
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.felix:maven-bundle-plugin:3.5.1:baseline (baseline) on project
> oak-commons: Artifact org.apache.jackrabbit:oak-commons:bundle:1.10.1:compile
> does not exist on local/remote repositories: Could not find artifact
> org.apache.jackrabbit:oak-commons:jar:1.10.1 in central
> (https://repo.maven.apache.org/maven2)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (OAK-8086) Build Jackrabbit Oak #1974 failed
[ https://issues.apache.org/jira/browse/OAK-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger closed OAK-8086. - > Build Jackrabbit Oak #1974 failed > - > > Key: OAK-8086 > URL: https://issues.apache.org/jira/browse/OAK-8086 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1974 has failed. > First failed run: [Jackrabbit Oak > #1974|https://builds.apache.org/job/Jackrabbit%20Oak/1974/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1974/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8086) Build Jackrabbit Oak #1974 failed
[ https://issues.apache.org/jira/browse/OAK-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-8086. --- Resolution: Duplicate > Build Jackrabbit Oak #1974 failed > - > > Key: OAK-8086 > URL: https://issues.apache.org/jira/browse/OAK-8086 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1974 has failed. > First failed run: [Jackrabbit Oak > #1974|https://builds.apache.org/job/Jackrabbit%20Oak/1974/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1974/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780251#comment-16780251 ] Michael Dürig commented on OAK-8071: Thanks [~ahanikel] for the review. I will thus go forward with the changes from https://github.com/mduerig/jackrabbit-oak/commits/OAK-8071-logging here. I will move the patched proposed on the other branch for improving the JMX monitoring into a new issue of type improvement. > Logging to detect commits carrying over from previous GC generation can block > other threads from committing > --- > > Key: OAK-8071 > URL: https://issues.apache.org/jira/browse/OAK-8071 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.12, 1.11.0, 1.8.12, 1.10.2 > > > Add logging / monitoring to detect the situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8085) Upgrade spotbugs to 3.1.11
[
https://issues.apache.org/jira/browse/OAK-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8085:
Fix Version/s: 1.10.2
> Upgrade spotbugs to 3.1.11
> --
>
> Key: OAK-8085
> URL: https://issues.apache.org/jira/browse/OAK-8085
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10, jdk11
> Fix For: 1.12, 1.11.0, 1.10.2
>
>
> ...due to a Java 11 incompatibility:
> {noformat}
> [java] The following errors occurred during analysis:
> [java] Error scanning java/lang/Throwable for referenced classes
> [java] java.lang.UnsupportedOperationException
> [java] At
> org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
> [java] At
> org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
> [java] At
> edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
> [java] At
> org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
> [java] At
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:519)
> [java] At
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:703)
> [java] At
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:79)
> [java] At
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
> [java] At
> edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:262)
> [java] At
> edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:774)
> [java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:220)
> [java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:401)
> [java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1185)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8085) Upgrade spotbugs to 3.1.11
[
https://issues.apache.org/jira/browse/OAK-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779335#comment-16779335
]
Julian Reschke edited comment on OAK-8085 at 2/28/19 8:09 AM:
--
trunk: [r1854462|http://svn.apache.org/r1854462]
1.10: [r1854508|http://svn.apache.org/r1854508]
was (Author: reschke):
trunk: [r1854462|http://svn.apache.org/r1854462]
> Upgrade spotbugs to 3.1.11
> --
>
> Key: OAK-8085
> URL: https://issues.apache.org/jira/browse/OAK-8085
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_8, jdk11
> Fix For: 1.12, 1.11.0, 1.10.2
>
>
> ...due to a Java 11 incompatibility:
> {noformat}
> [java] The following errors occurred during analysis:
> [java] Error scanning java/lang/Throwable for referenced classes
> [java] java.lang.UnsupportedOperationException
> [java] At
> org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
> [java] At
> org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
> [java] At
> edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
> [java] At
> org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
> [java] At
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:519)
> [java] At
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:703)
> [java] At
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:79)
> [java] At
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
> [java] At
> edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:262)
> [java] At
> edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:774)
> [java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:220)
> [java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:401)
> [java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1185)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8085) Upgrade spotbugs to 3.1.11
[
https://issues.apache.org/jira/browse/OAK-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8085:
Labels: candidate_oak_1_8 jdk11 (was: candidate_oak_1_10 jdk11)
> Upgrade spotbugs to 3.1.11
> --
>
> Key: OAK-8085
> URL: https://issues.apache.org/jira/browse/OAK-8085
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_8, jdk11
> Fix For: 1.12, 1.11.0, 1.10.2
>
>
> ...due to a Java 11 incompatibility:
> {noformat}
> [java] The following errors occurred during analysis:
> [java] Error scanning java/lang/Throwable for referenced classes
> [java] java.lang.UnsupportedOperationException
> [java] At
> org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
> [java] At
> org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
> [java] At
> edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
> [java] At
> org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
> [java] At
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:519)
> [java] At
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:703)
> [java] At
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:79)
> [java] At
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
> [java] At
> edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:262)
> [java] At
> edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:774)
> [java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:220)
> [java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:401)
> [java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1185)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
