[jira] [Commented] (OAK-10116) Performance problem when importing nodes with many binary properties and remote blobstore
[
https://issues.apache.org/jira/browse/OAK-10116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700549#comment-17700549
]
Timothee Maret commented on OAK-10116:
--
Assuming that checking for the blob presence is required, it may be possible to
check by batches and/or check asynchronously.
> Performance problem when importing nodes with many binary properties and
> remote blobstore
> -
>
> Key: OAK-10116
> URL: https://issues.apache.org/jira/browse/OAK-10116
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob-cloud, blob-plugins, jcr
>Affects Versions: 1.48.0
>Reporter: Joerg Hoh
>Priority: Major
>
> We often import binaryless packages (using JR filevault) into our Oak
> instances, which are using a remote blobstore.
> We observe bad performance when we import nodes with binary properties. In
> this case stacktraces often look like this:
> {noformat}
> "Queue Processor for Subscriber agent publishSubscriber" #311 daemon prio=5
> os_prio=0 cpu=298928.76ms elapsed=576.04s tid=0x563f968c6800 nid=0x1644
> runnable [0x7f2a609e3000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(java.base@11.0.15/Native
> Method)
> at
> java.net.SocketInputStream.socketRead(java.base@11.0.15/SocketInputStream.java:115)
> at
> java.net.SocketInputStream.read(java.base@11.0.15/SocketInputStream.java:168)
> at
> java.net.SocketInputStream.read(java.base@11.0.15/SocketInputStream.java:140)
> at
> sun.security.ssl.SSLSocketInputRecord.read(java.base@11.0.15/SSLSocketInputRecord.java:478)
> at
> sun.security.ssl.SSLSocketInputRecord.readHeader(java.base@11.0.15/SSLSocketInputRecord.java:472)
> at
> sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base@11.0.15/SSLSocketInputRecord.java:70)
> at
> sun.security.ssl.SSLSocketImpl.readApplicationRecord(java.base@11.0.15/SSLSocketImpl.java:1328)
> at
> sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base@11.0.15/SSLSocketImpl.java:971)
> at
> java.io.BufferedInputStream.fill(java.base@11.0.15/BufferedInputStream.java:252)
> at
> java.io.BufferedInputStream.read1(java.base@11.0.15/BufferedInputStream.java:292)
> at
> java.io.BufferedInputStream.read(java.base@11.0.15/BufferedInputStream.java:351)
> - locked <0x0007d98d0ca8> (a java.io.BufferedInputStream)
> at
> sun.net.www.http.HttpClient.parseHTTPHeader(java.base@11.0.15/HttpClient.java:746)
> at
> sun.net.www.http.HttpClient.parseHTTP(java.base@11.0.15/HttpClient.java:689)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(java.base@11.0.15/HttpURLConnection.java:1615)
> - locked <0x0007d98cb480> (a
> sun.net.www.protocol.https.DelegateHttpsURLConnection)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(java.base@11.0.15/HttpURLConnection.java:1520)
> - locked <0x0007d98cb480> (a
> sun.net.www.protocol.https.DelegateHttpsURLConnection)
> at
> java.net.HttpURLConnection.getResponseCode(java.base@11.0.15/HttpURLConnection.java:527)
> at
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(java.base@11.0.15/HttpsURLConnectionImpl.java:334)
> at
> com.microsoft.azure.storage.core.ExecutionEngine.executeWithRetry(ExecutionEngine.java:115)
> at
> com.microsoft.azure.storage.blob.CloudBlob.downloadAttributes(CloudBlob.java:1414)
> at
> com.microsoft.azure.storage.blob.CloudBlob.downloadAttributes(CloudBlob.java:1381)
> at
> org.apache.jackrabbit.oak.blob.cloud.azure.blobstorage.AzureBlobStoreBackend.getRecord(AzureBlobStoreBackend.java:408)
> at
> org.apache.jackrabbit.oak.plugins.blob.AbstractSharedCachingDataStore.getRecordIfStored(AbstractSharedCachingDataStore.java:210)
> at
> org.apache.jackrabbit.core.data.AbstractDataStore.getRecordFromReference(AbstractDataStore.java:72)
> at
> org.apache.jackrabbit.oak.plugins.blob.datastore.DataStoreBlobStore.getBlobId(DataStoreBlobStore.java:402)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeStore.getBlob(SegmentNodeStore.java:257)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeStore.getBlob(CompositeNodeStore.java:202)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.getBlob(MutableRoot.java:342)
> at
> org.apache.jackrabbit.oak.plugins.value.jcr.ValueFactoryImpl.createValue(ValueFactoryImpl.java:111)
> at
> org.apache.jackrabbit.vault.util.DocViewProperty.apply(DocViewProperty.java:413)
> at
>
[jira] [Created] (OAK-9193) Allow to build Jcr with a PostValidationHook
Timothee Maret created OAK-9193:
---
Summary: Allow to build Jcr with a PostValidationHook
Key: OAK-9193
URL: https://issues.apache.org/jira/browse/OAK-9193
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Affects Versions: 1.32.0
Reporter: Timothee Maret
Oak store SPI exports a
[PostValidationHook|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/commit/PostValidationHook.java]
that extends CommitHook. According to the Javadoc, post validation hooks are
meant to be executed after validation hooks. The [Jcr
builder|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/Jcr.java]
should allow specifying a
[PostValidationHook|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/commit/PostValidationHook.java]
to be placed after the built in ACL validations.
The following signature would be added to the Jcr class
{code:java}
public Jcr with(@NotNull PostValidationHook postValidationHook)
{code}
The provided hook would be included after the security provider hooks via the
[MutableRoot|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/core/MutableRoot.java#L291].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-5789) Oak does not enforce jcr:namespaceManagement at path level
[
https://issues.apache.org/jira/browse/OAK-5789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15892618#comment-15892618
]
Timothee Maret commented on OAK-5789:
-
Thanks [~anchela]!
> Oak does not enforce jcr:namespaceManagement at path level
> --
>
> Key: OAK-5789
> URL: https://issues.apache.org/jira/browse/OAK-5789
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: doc
>Affects Versions: 1.6.0
>Reporter: Timothee Maret
>Assignee: angela
> Fix For: 1.8
>
>
> With jackrabbit, it used to be possible to define ACEs granting
> {{jcr:namespaceManagement}} at a given path.
> With Oak, it seems the {{jcr:namespaceManagement}} are only defined at the
> Repository level.
> This should be documented in
> http://jackrabbit.apache.org/oak/docs/differences.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-5789) Oak does not enforce jcr:namespaceManagement at path level
Timothee Maret created OAK-5789:
---
Summary: Oak does not enforce jcr:namespaceManagement at path level
Key: OAK-5789
URL: https://issues.apache.org/jira/browse/OAK-5789
Project: Jackrabbit Oak
Issue Type: Documentation
Components: security
Affects Versions: 1.6.0
Reporter: Timothee Maret
With jackrabbit, it used to be possible to define ACEs granting
{{jcr:namespaceManagement}} at a given path.
With Oak, it seems the {{jcr:namespaceManagement}} are only defined at the
Repository level.
This should be documented in
http://jackrabbit.apache.org/oak/docs/differences.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664884#comment-15664884
]
Timothee Maret edited comment on OAK-5106 at 11/14/16 8:52 PM:
---
Attach a svn patch that
* Reuse the NioEventLoopGroup in the standby client
* Fix a file handler leak in tests (the server NioEventLoopGroup was not
released)
was (Author: marett):
Attach a svn patch that
* Reuse the NioEventLoopGroup in the standby client
* Fix a memory leak in tests (the server NioEventLoopGroup was not released)
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5106.patch
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15664894#comment-15664894
]
Timothee Maret commented on OAK-5106:
-
IT tests used to run with ~4'000 files opened at the same time. With the patch,
it is reduced to < 500.
[~frm], [~mduerig] could you have a look at the patch ?
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5106.patch
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5106:
Attachment: OAK-5106.patch
Attach a svn patch that
* Reuse the NioEventLoopGroup in the standby client
* Fix a memory leak in tests (the server NioEventLoopGroup was not released)
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5106.patch
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned OAK-5106:
---
Assignee: Timothee Maret
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5106) Reuse NioEventLoopGroup in standby client
[
https://issues.apache.org/jira/browse/OAK-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5106:
Flags: Patch
> Reuse NioEventLoopGroup in standby client
> -
>
> Key: OAK-5106
> URL: https://issues.apache.org/jira/browse/OAK-5106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.5.13
>Reporter: Timothee Maret
> Fix For: 1.5.14
>
>
> The Standby client code does instantiate a new {{NioEventLoopGroup}} for
> every cycle (5 seconds). The standby tests do instantiate many
> {{NioEventLoopGroup}}.
> Although {{NioEventLoopGroup}} are closed properly, each of them consume
> files and management overhead (seting up/down). An improvement would be to
> reuse the {{NioEventLoopGroup}} in standby client across polling cycles and
> reuse {{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5106) Reuse NioEventLoopGroup in standby client
Timothee Maret created OAK-5106:
---
Summary: Reuse NioEventLoopGroup in standby client
Key: OAK-5106
URL: https://issues.apache.org/jira/browse/OAK-5106
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-tar
Affects Versions: 1.5.13
Reporter: Timothee Maret
Fix For: 1.5.14
The Standby client code does instantiate a new {{NioEventLoopGroup}} for every
cycle (5 seconds). The standby tests do instantiate many {{NioEventLoopGroup}}.
Although {{NioEventLoopGroup}} are closed properly, each of them consume files
and management overhead (seting up/down). An improvement would be to reuse the
{{NioEventLoopGroup}} in standby client across polling cycles and reuse
{{NioEventLoopGroup}} in the test code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5094) NPE when failing to get the remote head
[
https://issues.apache.org/jira/browse/OAK-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5094:
Attachment: OAK-5094.patch
Attaching a patch that handle the case (essentially throw a
IllegalStateException instead of NPE).
[~frm] could you have a look ?
> NPE when failing to get the remote head
> ---
>
> Key: OAK-5094
> URL: https://issues.apache.org/jira/browse/OAK-5094
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5094.patch
>
>
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClient#getHead}}
> may return {{null}} in case it fails the request fails. This case is not
> currently handled and cause
> {code}
> 09.11.2016 18:57:12.183 *ERROR* [sling-default-44-Registered Service.609]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state
> .
> java.lang.NullPointerException: null
> at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
> at java.util.regex.Matcher.reset(Matcher.java:309)
> at java.util.regex.Matcher.(Matcher.java:229)
> at java.util.regex.Pattern.matcher(Pattern.java:1093)
> at
> org.apache.jackrabbit.oak.segment.RecordId.fromString(RecordId.java:48)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.getHead(StandbyClientSyncExecution.java:81)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:64)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:141)
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5094) NPE when failing to get the remote head
[
https://issues.apache.org/jira/browse/OAK-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5094:
Flags: Patch
> NPE when failing to get the remote head
> ---
>
> Key: OAK-5094
> URL: https://issues.apache.org/jira/browse/OAK-5094
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5094.patch
>
>
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClient#getHead}}
> may return {{null}} in case it fails the request fails. This case is not
> currently handled and cause
> {code}
> 09.11.2016 18:57:12.183 *ERROR* [sling-default-44-Registered Service.609]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state
> .
> java.lang.NullPointerException: null
> at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
> at java.util.regex.Matcher.reset(Matcher.java:309)
> at java.util.regex.Matcher.(Matcher.java:229)
> at java.util.regex.Pattern.matcher(Pattern.java:1093)
> at
> org.apache.jackrabbit.oak.segment.RecordId.fromString(RecordId.java:48)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.getHead(StandbyClientSyncExecution.java:81)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:64)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:141)
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5094) NPE when failing to get the remote head
Timothee Maret created OAK-5094:
---
Summary: NPE when failing to get the remote head
Key: OAK-5094
URL: https://issues.apache.org/jira/browse/OAK-5094
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-tar
Affects Versions: 1.5.12
Reporter: Timothee Maret
Assignee: Timothee Maret
Fix For: 1.5.14
{{org.apache.jackrabbit.oak.segment.standby.client.StandbyClient#getHead}} may
return {{null}} in case it fails the request fails. This case is not currently
handled and cause
{code}
09.11.2016 18:57:12.183 *ERROR* [sling-default-44-Registered Service.609]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
synchronizing state
.
java.lang.NullPointerException: null
at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
at java.util.regex.Matcher.reset(Matcher.java:309)
at java.util.regex.Matcher.(Matcher.java:229)
at java.util.regex.Pattern.matcher(Pattern.java:1093)
at
org.apache.jackrabbit.oak.segment.RecordId.fromString(RecordId.java:48)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.getHead(StandbyClientSyncExecution.java:81)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:64)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:141)
at
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5088) o.a.j.o.p.b.d.DataStoreBlobStore#getReference logs WARNING for missing records
[
https://issues.apache.org/jira/browse/OAK-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5088:
Attachment: OAK-5088.patch
Attaching a patch that applies change proposed offline by [~chetanm]
[~chetanm] could you have a look ?
> o.a.j.o.p.b.d.DataStoreBlobStore#getReference logs WARNING for missing
> records
> ---
>
> Key: OAK-5088
> URL: https://issues.apache.org/jira/browse/OAK-5088
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5088.patch
>
>
> The
> {{org.apache.jackrabbit.oak.plugins.blob.datastore.DataStoreBlobStore#getReference}}
> method logs WARNING level in cases the {{encodedBlobId}} is not stored.
> Those cases are expected according to the JavaDoc [0] and thus should not log
> WARNING level messages.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/2acda3156cfad9993310e7aa0492cdc0b65aa5f7/oak-blob/src/main/java/org/apache/jackrabbit/oak/spi/blob/BlobStore.java#L83-L87
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5088) o.a.j.o.p.b.d.DataStoreBlobStore#getReference logs WARNING for missing records
[
https://issues.apache.org/jira/browse/OAK-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5088:
Flags: Patch
> o.a.j.o.p.b.d.DataStoreBlobStore#getReference logs WARNING for missing
> records
> ---
>
> Key: OAK-5088
> URL: https://issues.apache.org/jira/browse/OAK-5088
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
>
> The
> {{org.apache.jackrabbit.oak.plugins.blob.datastore.DataStoreBlobStore#getReference}}
> method logs WARNING level in cases the {{encodedBlobId}} is not stored.
> Those cases are expected according to the JavaDoc [0] and thus should not log
> WARNING level messages.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/2acda3156cfad9993310e7aa0492cdc0b65aa5f7/oak-blob/src/main/java/org/apache/jackrabbit/oak/spi/blob/BlobStore.java#L83-L87
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5088) o.a.j.o.p.b.d.DataStoreBlobStore#getReference logs WARNING for missing records
Timothee Maret created OAK-5088:
---
Summary: o.a.j.o.p.b.d.DataStoreBlobStore#getReference logs
WARNING for missing records
Key: OAK-5088
URL: https://issues.apache.org/jira/browse/OAK-5088
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 1.5.12
Reporter: Timothee Maret
Assignee: Timothee Maret
Fix For: 1.5.14
The
{{org.apache.jackrabbit.oak.plugins.blob.datastore.DataStoreBlobStore#getReference}}
method logs WARNING level in cases the {{encodedBlobId}} is not stored. Those
cases are expected according to the JavaDoc [0] and thus should not log WARNING
level messages.
[0]
https://github.com/apache/jackrabbit-oak/blob/2acda3156cfad9993310e7aa0492cdc0b65aa5f7/oak-blob/src/main/java/org/apache/jackrabbit/oak/spi/blob/BlobStore.java#L83-L87
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5087) Primary instance logs expected SNFEs at ERROR level
[ https://issues.apache.org/jira/browse/OAK-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15647894#comment-15647894 ] Timothee Maret commented on OAK-5087: - [~frm] could you have a look at the patch ? > Primary instance logs expected SNFEs at ERROR level > --- > > Key: OAK-5087 > URL: https://issues.apache.org/jira/browse/OAK-5087 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Affects Versions: 1.5.12 >Reporter: Timothee Maret >Assignee: Timothee Maret > Fix For: 1.5.14 > > Attachments: OAK-5087.patch > > > Since OAK-4965 the primary instances logs a large amount of SNFEs @ ERROR > level. This seems to be due to the fact that some SNFEs are expected on > primary as well (while the HEAD is not flushed to disk). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5087) Primary instance logs expected SNFEs at ERROR level
[ https://issues.apache.org/jira/browse/OAK-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated OAK-5087: Flags: Patch > Primary instance logs expected SNFEs at ERROR level > --- > > Key: OAK-5087 > URL: https://issues.apache.org/jira/browse/OAK-5087 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Affects Versions: 1.5.12 >Reporter: Timothee Maret >Assignee: Timothee Maret > Fix For: 1.5.14 > > Attachments: OAK-5087.patch > > > Since OAK-4965 the primary instances logs a large amount of SNFEs @ ERROR > level. This seems to be due to the fact that some SNFEs are expected on > primary as well (while the HEAD is not flushed to disk). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5087) Primary instance logs expected SNFEs at ERROR level
[ https://issues.apache.org/jira/browse/OAK-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated OAK-5087: Attachment: OAK-5087.patch Attaching a svn compatible patch. > Primary instance logs expected SNFEs at ERROR level > --- > > Key: OAK-5087 > URL: https://issues.apache.org/jira/browse/OAK-5087 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Affects Versions: 1.5.12 >Reporter: Timothee Maret >Assignee: Timothee Maret > Fix For: 1.5.14 > > Attachments: OAK-5087.patch > > > Since OAK-4965 the primary instances logs a large amount of SNFEs @ ERROR > level. This seems to be due to the fact that some SNFEs are expected on > primary as well (while the HEAD is not flushed to disk). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5087) Primary instance logs expected SNFEs at ERROR level
Timothee Maret created OAK-5087: --- Summary: Primary instance logs expected SNFEs at ERROR level Key: OAK-5087 URL: https://issues.apache.org/jira/browse/OAK-5087 Project: Jackrabbit Oak Issue Type: Bug Components: segment-tar Affects Versions: 1.5.12 Reporter: Timothee Maret Assignee: Timothee Maret Fix For: 1.5.14 Since OAK-4965 the primary instances logs a large amount of SNFEs @ ERROR level. This seems to be due to the fact that some SNFEs are expected on primary as well (while the HEAD is not flushed to disk). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-5083) SegmentNotFoundExceptionListener logs Listener ID instead of SegmentId
[
https://issues.apache.org/jira/browse/OAK-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15647260#comment-15647260
]
Timothee Maret commented on OAK-5083:
-
[~mduerig] could you have a look at the patch please ?
> SegmentNotFoundExceptionListener logs Listener ID instead of SegmentId
> --
>
> Key: OAK-5083
> URL: https://issues.apache.org/jira/browse/OAK-5083
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5083.patch
>
>
> The listener introduced in OAK-4965 does log the listener ID instead of the
> Segment ID. For instance
> {code}
> 06:06:07.027 ERROR [nioEventLoopGroup-206-3]
> SegmentNotFoundExceptionListener.java:48 Segment not found:
> org.apache.jackrabbit.oak.segment.SegmentNotFoundExceptionListener$2@639adf08.
> SegmentId age=2913ms,segment-generation=0
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-5083) SegmentNotFoundExceptionListener logs Listener ID instead of SegmentId
[
https://issues.apache.org/jira/browse/OAK-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned OAK-5083:
---
Assignee: Timothee Maret
> SegmentNotFoundExceptionListener logs Listener ID instead of SegmentId
> --
>
> Key: OAK-5083
> URL: https://issues.apache.org/jira/browse/OAK-5083
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5083.patch
>
>
> The listener introduced in OAK-4965 does log the listener ID instead of the
> Segment ID. For instance
> {code}
> 06:06:07.027 ERROR [nioEventLoopGroup-206-3]
> SegmentNotFoundExceptionListener.java:48 Segment not found:
> org.apache.jackrabbit.oak.segment.SegmentNotFoundExceptionListener$2@639adf08.
> SegmentId age=2913ms,segment-generation=0
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5083) SegmentNotFoundExceptionListener logs Listener ID instead of SegmentId
[
https://issues.apache.org/jira/browse/OAK-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5083:
Attachment: OAK-5083.patch
Attaching a patch..
> SegmentNotFoundExceptionListener logs Listener ID instead of SegmentId
> --
>
> Key: OAK-5083
> URL: https://issues.apache.org/jira/browse/OAK-5083
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
> Fix For: 1.5.14
>
> Attachments: OAK-5083.patch
>
>
> The listener introduced in OAK-4965 does log the listener ID instead of the
> Segment ID. For instance
> {code}
> 06:06:07.027 ERROR [nioEventLoopGroup-206-3]
> SegmentNotFoundExceptionListener.java:48 Segment not found:
> org.apache.jackrabbit.oak.segment.SegmentNotFoundExceptionListener$2@639adf08.
> SegmentId age=2913ms,segment-generation=0
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5083) SegmentNotFoundExceptionListener logs Listener ID instead of SegmentId
[
https://issues.apache.org/jira/browse/OAK-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5083:
Flags: Patch
> SegmentNotFoundExceptionListener logs Listener ID instead of SegmentId
> --
>
> Key: OAK-5083
> URL: https://issues.apache.org/jira/browse/OAK-5083
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
> Fix For: 1.5.14
>
>
> The listener introduced in OAK-4965 does log the listener ID instead of the
> Segment ID. For instance
> {code}
> 06:06:07.027 ERROR [nioEventLoopGroup-206-3]
> SegmentNotFoundExceptionListener.java:48 Segment not found:
> org.apache.jackrabbit.oak.segment.SegmentNotFoundExceptionListener$2@639adf08.
> SegmentId age=2913ms,segment-generation=0
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5083) SegmentNotFoundExceptionListener logs Listener ID instead of SegmentId
Timothee Maret created OAK-5083:
---
Summary: SegmentNotFoundExceptionListener logs Listener ID instead
of SegmentId
Key: OAK-5083
URL: https://issues.apache.org/jira/browse/OAK-5083
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-tar
Affects Versions: 1.5.12
Reporter: Timothee Maret
Fix For: 1.5.14
The listener introduced in OAK-4965 does log the listener ID instead of the
Segment ID. For instance
{code}
06:06:07.027 ERROR [nioEventLoopGroup-206-3]
SegmentNotFoundExceptionListener.java:48 Segment not found:
org.apache.jackrabbit.oak.segment.SegmentNotFoundExceptionListener$2@639adf08.
SegmentId age=2913ms,segment-generation=0
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5017) Standby test failures
[
https://issues.apache.org/jira/browse/OAK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15647198#comment-15647198
]
Timothee Maret commented on OAK-5017:
-
[~chetanm] thanks for reopening. I'll look at the
{{StandbyTestIT.testSyncLoop}} issue.
Regarding the {{o.a.j.o.plugins.segment.standby}} tests, I think it'd make
sense to open a separate issue since this issue is about the
{{oak-segment-tar}} module.
> Standby test failures
> -
>
> Key: OAK-5017
> URL: https://issues.apache.org/jira/browse/OAK-5017
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Timothee Maret
> Labels: test-failure
> Fix For: 1.6, 1.5.14
>
>
> I've recently seen a couple of the standby tests fail. E.g. on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {{org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes}}:
> {noformat}
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
[
https://issues.apache.org/jira/browse/OAK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633526#comment-15633526
]
Timothee Maret commented on OAK-5055:
-
Thanks [~mduerig]! I have looked at the patch and tried in my setup, LGTM.
> o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
>
>
> Key: OAK-5055
> URL: https://issues.apache.org/jira/browse/OAK-5055
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.13
>
> Attachments: OAK-5055.patch, OAK-5055.patch, OAK-5055.patch
>
>
> According to the API [0], the method {{RevisionGC#startRevisionGC}} should
> {code}
> @return the status of the operation right after it was initiated
> {code}
> However, it does return {{succeeded}} on every call, see [1].
> I believe this should either compute the actual state, or return
> {{initiated}} or {{running}}.
> Same applies for {{cancelRevisionGC}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
> [1]
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
[
https://issues.apache.org/jira/browse/OAK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1560#comment-1560
]
Timothee Maret commented on OAK-5055:
-
No objection, thanks for looking at this!
> o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
>
>
> Key: OAK-5055
> URL: https://issues.apache.org/jira/browse/OAK-5055
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.13
>
> Attachments: OAK-5055.patch, OAK-5055.patch, OAK-5055.patch
>
>
> According to the API [0], the method {{RevisionGC#startRevisionGC}} should
> {code}
> @return the status of the operation right after it was initiated
> {code}
> However, it does return {{succeeded}} on every call, see [1].
> I believe this should either compute the actual state, or return
> {{initiated}} or {{running}}.
> Same applies for {{cancelRevisionGC}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
> [1]
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
[
https://issues.apache.org/jira/browse/OAK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5055:
Attachment: OAK-5055.patch
Attaching a patch that
* expose the {{initiated(id,message)}} like methods
* return the {{initiated}} status when starting an async action
* return the same gcOp id except when starting the async action fails (because
there already is an action running or because there was none running)
> o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
>
>
> Key: OAK-5055
> URL: https://issues.apache.org/jira/browse/OAK-5055
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.13
>
> Attachments: OAK-5055.patch, OAK-5055.patch, OAK-5055.patch
>
>
> According to the API [0], the method {{RevisionGC#startRevisionGC}} should
> {code}
> @return the status of the operation right after it was initiated
> {code}
> However, it does return {{succeeded}} on every call, see [1].
> I believe this should either compute the actual state, or return
> {{initiated}} or {{running}}.
> Same applies for {{cancelRevisionGC}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
> [1]
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
[
https://issues.apache.org/jira/browse/OAK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633211#comment-15633211
]
Timothee Maret edited comment on OAK-5055 at 11/3/16 3:47 PM:
--
[~mduerig] Looking deeper into the {{RevisionGC}}, it seems there's another
bug. I'll discuss it here since it is coupled to the current issue.
Actually returning {{initiated}}, {{failed}}, etc. is bogus, the operation id
does not match the id of the {{gcOp}} field in the {{RevisionGC}} instance.
This is because the operation methods implicitely increment the idGen counter
(example at [0]). With the current ManagementOperation code, there seems to be
no way to invoke the {{initiated}}, {{failed}}, etc. methods without messing up
the id.
This could be fixed however, either by
1. Exposing the {{initiated(id,message)}} like methods by making them public ;
and changing the {{RevisionGC}} to code to invoke those methods
2. In {{RevisionGC}}, return {{getRevisionGCStatus()}} in any case instead of
{{initiated}}, {{failed}}, etc.
wdyt ?
[0]
https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/management/ManagementOperation.java#L279
was (Author: marett):
[~mduerig] Looking deeper into the {{RevisionGC}}, it seems there's another
bug. I'll discuss it here since it is coupled to the current issue.
Actually returning {{initiated}}, {{failed}}, etc. is bogus, the operation id
does not match the id of the {{gcOp}} field in the {{RevisionGC}} instance.
This is because the operation methods implicitely increment the idGen counter
(example at [0]). With the current ManagementOperation code, there seems to be
no way to invoke the {{initiated}}, {{failed}}, etc. methods without messing up
the id.
This could be fixed however, either by
1. Exposing the {{initiated(id,message}} like methods by making them public ;
and changing the {{RevisionGC}} to code to invoke those methods
2. In {{RevisionGC}}, return {{getRevisionGCStatus()}} in any case instead of
{{initiated}}, {{failed}}, etc.
wdyt ?
[0]
https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/management/ManagementOperation.java#L279
> o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
>
>
> Key: OAK-5055
> URL: https://issues.apache.org/jira/browse/OAK-5055
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.13
>
> Attachments: OAK-5055.patch, OAK-5055.patch
>
>
> According to the API [0], the method {{RevisionGC#startRevisionGC}} should
> {code}
> @return the status of the operation right after it was initiated
> {code}
> However, it does return {{succeeded}} on every call, see [1].
> I believe this should either compute the actual state, or return
> {{initiated}} or {{running}}.
> Same applies for {{cancelRevisionGC}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
> [1]
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
[
https://issues.apache.org/jira/browse/OAK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15633211#comment-15633211
]
Timothee Maret commented on OAK-5055:
-
[~mduerig] Looking deeper into the {{RevisionGC}}, it seems there's another
bug. I'll discuss it here since it is coupled to the current issue.
Actually returning {{initiated}}, {{failed}}, etc. is bogus, the operation id
does not match the id of the {{gcOp}} field in the {{RevisionGC}} instance.
This is because the operation methods implicitely increment the idGen counter
(example at [0]). With the current ManagementOperation code, there seems to be
no way to invoke the {{initiated}}, {{failed}}, etc. methods without messing up
the id.
This could be fixed however, either by
1. Exposing the {{initiated(id,message}} like methods by making them public ;
and changing the {{RevisionGC}} to code to invoke those methods
2. In {{RevisionGC}}, return {{getRevisionGCStatus()}} in any case instead of
{{initiated}}, {{failed}}, etc.
wdyt ?
[0]
https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/management/ManagementOperation.java#L279
> o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
>
>
> Key: OAK-5055
> URL: https://issues.apache.org/jira/browse/OAK-5055
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.13
>
> Attachments: OAK-5055.patch, OAK-5055.patch
>
>
> According to the API [0], the method {{RevisionGC#startRevisionGC}} should
> {code}
> @return the status of the operation right after it was initiated
> {code}
> However, it does return {{succeeded}} on every call, see [1].
> I believe this should either compute the actual state, or return
> {{initiated}} or {{running}}.
> Same applies for {{cancelRevisionGC}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
> [1]
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
[
https://issues.apache.org/jira/browse/OAK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5055:
Attachment: OAK-5055.patch
Attaching a patch returning {{initiated}}.
> o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
>
>
> Key: OAK-5055
> URL: https://issues.apache.org/jira/browse/OAK-5055
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.13
>
> Attachments: OAK-5055.patch, OAK-5055.patch
>
>
> According to the API [0], the method {{RevisionGC#startRevisionGC}} should
> {code}
> @return the status of the operation right after it was initiated
> {code}
> However, it does return {{succeeded}} on every call, see [1].
> I believe this should either compute the actual state, or return
> {{initiated}} or {{running}}.
> Same applies for {{cancelRevisionGC}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
> [1]
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
[
https://issues.apache.org/jira/browse/OAK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15632959#comment-15632959
]
Timothee Maret commented on OAK-5055:
-
[~mduerig] that makes sense. Please see the updated patch
> o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
>
>
> Key: OAK-5055
> URL: https://issues.apache.org/jira/browse/OAK-5055
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.5.13
>
> Attachments: OAK-5055.patch, OAK-5055.patch
>
>
> According to the API [0], the method {{RevisionGC#startRevisionGC}} should
> {code}
> @return the status of the operation right after it was initiated
> {code}
> However, it does return {{succeeded}} on every call, see [1].
> I believe this should either compute the actual state, or return
> {{initiated}} or {{running}}.
> Same applies for {{cancelRevisionGC}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
> [1]
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
[
https://issues.apache.org/jira/browse/OAK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5055:
Attachment: OAK-5055.patch
Attaching a svn compatible patch.
[~mduerig] could you have a look ?
> o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
>
>
> Key: OAK-5055
> URL: https://issues.apache.org/jira/browse/OAK-5055
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: OAK-5055.patch
>
>
> According to the API [0], the method {{RevisionGC#startRevisionGC}} should
> {code}
> @return the status of the operation right after it was initiated
> {code}
> However, it does return {{succeeded}} on every call, see [1].
> I believe this should either compute the actual state, or return
> {{initiated}} or {{running}}.
> Same applies for {{cancelRevisionGC}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
> [1]
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
[
https://issues.apache.org/jira/browse/OAK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5055:
Flags: Patch
> o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
>
>
> Key: OAK-5055
> URL: https://issues.apache.org/jira/browse/OAK-5055
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> According to the API [0], the method {{RevisionGC#startRevisionGC}} should
> {code}
> @return the status of the operation right after it was initiated
> {code}
> However, it does return {{succeeded}} on every call, see [1].
> I believe this should either compute the actual state, or return
> {{initiated}} or {{running}}.
> Same applies for {{cancelRevisionGC}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
> [1]
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
[
https://issues.apache.org/jira/browse/OAK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15632737#comment-15632737
]
Timothee Maret commented on OAK-5055:
-
[~mduerig] wdyt, should we change the implementation ? If so, shall we opt for
{{initiated}} or {{running}} ?
> o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
>
>
> Key: OAK-5055
> URL: https://issues.apache.org/jira/browse/OAK-5055
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> According to the API [0], the method {{RevisionGC#startRevisionGC}} should
> {code}
> @return the status of the operation right after it was initiated
> {code}
> However, it does return {{succeeded}} on every call, see [1].
> I believe this should either compute the actual state, or return
> {{initiated}} or {{running}}.
> Same applies for {{cancelRevisionGC}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
> [1]
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
Timothee Maret created OAK-5055:
---
Summary: o.a.j.o.s.s.RevisionGC returns status that don't comply
with the API
Key: OAK-5055
URL: https://issues.apache.org/jira/browse/OAK-5055
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 1.5.12
Reporter: Timothee Maret
According to the API [0], the method {{RevisionGC#startRevisionGC}} should
{code}
@return the status of the operation right after it was initiated
{code}
However, it does return {{succeeded}} on every call, see [1].
I believe this should either compute the actual state, or return {{initiated}}
or {{running}}.
Same applies for {{cancelRevisionGC}}.
[0]
https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
[1]
https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-5055) o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
[
https://issues.apache.org/jira/browse/OAK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned OAK-5055:
---
Assignee: Timothee Maret
> o.a.j.o.s.s.RevisionGC returns status that don't comply with the API
>
>
> Key: OAK-5055
> URL: https://issues.apache.org/jira/browse/OAK-5055
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.12
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> According to the API [0], the method {{RevisionGC#startRevisionGC}} should
> {code}
> @return the status of the operation right after it was initiated
> {code}
> However, it does return {{succeeded}} on every call, see [1].
> I believe this should either compute the actual state, or return
> {{initiated}} or {{running}}.
> Same applies for {{cancelRevisionGC}}.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/18d69e6f590064585414f12bda724f48f3d5843f/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGCMBean.java#L34-L40
> [1]
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L105
> https://github.com/apache/jackrabbit-oak/blob/e873825b92faf14b7ef52130c36e6466edcef6b0/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/RevisionGC.java#L123
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15616810#comment-15616810
]
Timothee Maret edited comment on OAK-4969 at 10/31/16 11:24 AM:
[~frm] thanks for your insight. I found a clean way to fix this. Actually the
{{StandbyDiff}} allows to intercept the exception at the required node level
and attempt loading its binary properties.
This issue affects the previous standby implementation ({{oak-tarmk-standby}}).
I have attached two patches, one for each standby implementation, which contain
1. a test that reproduce the issue
2. the fix for the trunk
[~frm], [~alexparvulescu] Could you have a look at the patches
1. {{OAK-4969.patch}} (fix for {{oak-segment-tar}}
2. {{OAK-4969-oak-tarmk-standby.patch}} (fix for {{oak-tarmk-standby}})
?
was (Author: marett):
[~frm] thanks for your insight. I found a clean way to fix this. Actually the
{{StandbyDiff}} allows to intercept the exception at the required node level
and attempt loading its binary properties.
This issue affects the previous standby implementation ({{oak-tarmk-standby}}).
I have attached two patches, one for each standby implementation, which contain
1. a test that reproduce the issue
2. the fix for the trunk
[~frm] Could you have a look at the patch {{OAK-4969.patch}} (fix for
{{oak-segment-tar}} ?
[~alexparvulescu] Could you have a look at the patch
{{OAK-4969-oak-tarmk-standby.patch}} (fix for {{oak-tarmk-standby}}) ?
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.2, 1.4, 1.6, 1.5.13
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
>
[jira] [Commented] (OAK-5017) Standby test failures
[
https://issues.apache.org/jira/browse/OAK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15621896#comment-15621896
]
Timothee Maret commented on OAK-5017:
-
[~mduerig] OAK-5034 has been fixed. Could you close this issue (I don't have
this ability) ?.
> Standby test failures
> -
>
> Key: OAK-5017
> URL: https://issues.apache.org/jira/browse/OAK-5017
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Timothee Maret
> Labels: test-failure
> Fix For: 1.5.13
>
>
> I've recently seen a couple of the standby tests fail. E.g. on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {{org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes}}:
> {noformat}
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4969:
Fix Version/s: 1.2
1.4
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.2, 1.4, 1.6, 1.5.13
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
> at
>
[jira] [Comment Edited] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15616810#comment-15616810
]
Timothee Maret edited comment on OAK-4969 at 10/30/16 1:43 PM:
---
[~frm] thanks for your insight. I found a clean way to fix this. Actually the
{{StandbyDiff}} allows to intercept the exception at the required node level
and attempt loading its binary properties.
This issue affects the previous standby implementation ({{oak-tarmk-standby}}).
I have attached two patches, one for each standby implementation, which contain
1. a test that reproduce the issue
2. the fix for the trunk
[~frm] Could you have a look at the patch {{OAK-4969.patch}} (fix for
{{oak-segment-tar}} ?
[~alexparvulescu] Could you have a look at the patch
{{OAK-4969-oak-tarmk-standby.patch}} (fix for {{oak-tarmk-standby}}) ?
was (Author: marett):
[~frm] thanks for your insight. I found a clean way to fix this. Actually the
{{StandbyDiff}} allows to intercept the exception at the required node level
and attempt loading its binary properties.
I have attached a patch that contains
1. a test that reproduce the issue
2. the fix for the trunk
Could you have a look at the patch ?
This issue affects the previous standby implementation ({{oak-tarmk-standby}}).
Should I open a separate issue for tracking the fix there (AFAIK, it is not
strictly speaking a backport) ?
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
>
[jira] [Updated] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4969:
Attachment: OAK-4969-oak-tarmk-standby.patch
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4969-oak-tarmk-standby.patch, OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
> at
>
[jira] [Updated] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4969:
Component/s: segmentmk
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:391)
> at
>
[jira] [Comment Edited] (OAK-5017) Standby test failures
[
https://issues.apache.org/jira/browse/OAK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15617708#comment-15617708
]
Timothee Maret edited comment on OAK-5017 at 10/29/16 8:20 AM:
---
[~mduerig] the IT tests fails from time to time due to OAK-5034.
Without OAK-5034 patch, IT may pass or fail depending on timing between the tar
writer and the executions of assertions.
was (Author: marett):
[~mduerig] the IT tests fails from time to time due to OAK-5034.
> Standby test failures
> -
>
> Key: OAK-5017
> URL: https://issues.apache.org/jira/browse/OAK-5017
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Timothee Maret
> Labels: test-failure
> Fix For: 1.5.13
>
>
> I've recently seen a couple of the standby tests fail. E.g. on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {{org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes}}:
> {noformat}
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5017) Standby test failures
[
https://issues.apache.org/jira/browse/OAK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15617708#comment-15617708
]
Timothee Maret commented on OAK-5017:
-
[~mduerig] the IT tests fails from time to time due to OAK-5034.
> Standby test failures
> -
>
> Key: OAK-5017
> URL: https://issues.apache.org/jira/browse/OAK-5017
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Timothee Maret
> Labels: test-failure
> Fix For: 1.5.13
>
>
> I've recently seen a couple of the standby tests fail. E.g. on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {{org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes}}:
> {noformat}
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5034) FileStoreUtil#readSegmentWithRetry max retry delay is too short to be functional
[
https://issues.apache.org/jira/browse/OAK-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5034:
Attachment: OAK-5034.patch
Attaching a patch to set the max retry period to 20 seconds (same as
{{oak-tarmk-standby}}).
[~frm] could you have a look at the patch ?
> FileStoreUtil#readSegmentWithRetry max retry delay is too short to be
> functional
>
>
> Key: OAK-5034
> URL: https://issues.apache.org/jira/browse/OAK-5034
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: OAK-5034.patch
>
>
> The commit {{1765838}} introduced the {{FileStoreUtil#readSegmentWithRetry}}
> util and reduced the period between two tries (from 2sec to 0.125s) while the
> total number of tries did not change.
> This does not give enough time for the server to find references and
> segments, thus causing exceptions such as
> {code}
> 29.10.2016 05:07:37.242 *ERROR* [sling-default-2-Registered Service.605]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.IllegalStateException: Unable to read references of segment
> 5168c878-3a3f-49d0-aea9-b8b57d5d867f from primary
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.readReferences(StandbyClientSyncExecution.java:196)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.copySegmentHierarchyFromPrimary(StandbyClientSyncExecution.java:130)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.compareAgainstBaseState(StandbyClientSyncExecution.java:94)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:74)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:143)
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> and causing the client to throw exceptions, ultimately causing IT tests to
> fail.
> IIUC, the minimum period to retry should be bigger than a TarMK flush cycle
> (5 sec).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5034) FileStoreUtil#readSegmentWithRetry max retry delay is too short to be functional
[
https://issues.apache.org/jira/browse/OAK-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5034:
Flags: Patch
> FileStoreUtil#readSegmentWithRetry max retry delay is too short to be
> functional
>
>
> Key: OAK-5034
> URL: https://issues.apache.org/jira/browse/OAK-5034
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> The commit {{1765838}} introduced the {{FileStoreUtil#readSegmentWithRetry}}
> util and reduced the period between two tries (from 2sec to 0.125s) while the
> total number of tries did not change.
> This does not give enough time for the server to find references and
> segments, thus causing exceptions such as
> {code}
> 29.10.2016 05:07:37.242 *ERROR* [sling-default-2-Registered Service.605]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.IllegalStateException: Unable to read references of segment
> 5168c878-3a3f-49d0-aea9-b8b57d5d867f from primary
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.readReferences(StandbyClientSyncExecution.java:196)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.copySegmentHierarchyFromPrimary(StandbyClientSyncExecution.java:130)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.compareAgainstBaseState(StandbyClientSyncExecution.java:94)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:74)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:143)
> at
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> and causing the client to throw exceptions, ultimately causing IT tests to
> fail.
> IIUC, the minimum period to retry should be bigger than a TarMK flush cycle
> (5 sec).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5034) FileStoreUtil#readSegmentWithRetry max retry delay is too short to be functional
[
https://issues.apache.org/jira/browse/OAK-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5034:
Description:
The commit {{1765838}} introduced the {{FileStoreUtil#readSegmentWithRetry}}
util and reduced the period between two tries (from 2sec to 0.125s) while the
total number of tries did not change.
This does not give enough time for the server to find references and segments,
thus causing exceptions such as
{code}
29.10.2016 05:07:37.242 *ERROR* [sling-default-2-Registered Service.605]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
synchronizing state.
java.lang.IllegalStateException: Unable to read references of segment
5168c878-3a3f-49d0-aea9-b8b57d5d867f from primary
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.readReferences(StandbyClientSyncExecution.java:196)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.copySegmentHierarchyFromPrimary(StandbyClientSyncExecution.java:130)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.compareAgainstBaseState(StandbyClientSyncExecution.java:94)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:74)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:143)
at
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
and causing the client to throw exceptions, ultimately causing IT tests to fail.
IIUC, the minimum period to retry should be bigger than a TarMK flush cycle (5
sec).
was:
The commit {{1765838}} introduced the {{FileStoreUtil#readSegmentWithRetry}}
util and reduced the period between two tries (from 2sec to 0.125s) while the
total number of tries did not change.
This does not give enough time for the server to find references and segments,
thus causing exceptions such as
{code}
29.10.2016 05:07:37.242 *ERROR* [sling-default-2-Registered Service.605]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
synchronizing state.
java.lang.IllegalStateException: Unable to read references of segment
5168c878-3a3f-49d0-aea9-b8b57d5d867f from primary
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.readReferences(StandbyClientSyncExecution.java:196)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.copySegmentHierarchyFromPrimary(StandbyClientSyncExecution.java:130)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.compareAgainstBaseState(StandbyClientSyncExecution.java:94)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:74)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:143)
at
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
and causing the client to throw exceptions, ultimately causing IT tests to fail.
> FileStoreUtil#readSegmentWithRetry max retry delay is too short to be
> functional
>
>
> Key: OAK-5034
> URL: https://issues.apache.org/jira/browse/OAK-5034
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> The commit {{1765838}} introduced the {{FileStoreUtil#readSegmentWithRetry}}
> util and reduced the period between two tries (from 2sec to 0.125s) while the
> total number of tries did not change.
> This does not give enough time for the server to find references and
> segments, thus causing exceptions such as
> {code}
> 29.10.2016 05:07:37.242 *ERROR* [sling-default-2-Registered Service.605]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.IllegalStateException: Unable to read references of segment
> 5168c878-3a3f-49d0-aea9-b8b57d5d867f from primary
[jira] [Created] (OAK-5034) FileStoreUtil#readSegmentWithRetry max retry delay is too short to be functional
Timothee Maret created OAK-5034:
---
Summary: FileStoreUtil#readSegmentWithRetry max retry delay is too
short to be functional
Key: OAK-5034
URL: https://issues.apache.org/jira/browse/OAK-5034
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-tar
Affects Versions: Segment Tar 0.0.16
Reporter: Timothee Maret
Assignee: Timothee Maret
The commit {{1765838}} introduced the {{FileStoreUtil#readSegmentWithRetry}}
util and reduced the period between two tries (from 2sec to 0.125s) while the
total number of tries did not change.
This does not give enough time for the server to find references and segments,
thus causing exceptions such as
{code}
29.10.2016 05:07:37.242 *ERROR* [sling-default-2-Registered Service.605]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
synchronizing state.
java.lang.IllegalStateException: Unable to read references of segment
5168c878-3a3f-49d0-aea9-b8b57d5d867f from primary
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.readReferences(StandbyClientSyncExecution.java:196)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.copySegmentHierarchyFromPrimary(StandbyClientSyncExecution.java:130)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.compareAgainstBaseState(StandbyClientSyncExecution.java:94)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.execute(StandbyClientSyncExecution.java:74)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync.run(StandbyClientSync.java:143)
at
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
and causing the client to throw exceptions, ultimately causing IT tests to fail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15616810#comment-15616810
]
Timothee Maret edited comment on OAK-4969 at 10/28/16 11:15 PM:
[~frm] thanks for your insight. I found a clean way to fix this. Actually the
{{StandbyDiff}} allows to intercept the exception at the required node level
and attempt loading its binary properties.
I have attached a patch that contains
1. a test that reproduce the issue
2. the fix for the trunk
Could you have a look at the patch ?
This issue affects the previous standby implementation ({{oak-tarmk-standby}}).
Should I open a separate issue for tracking the fix there (AFAIK, it is not
strictly speaking a backport) ?
was (Author: marett):
[~frm] thanks for your insight. I found a clean way to fix this. Actually the
{{StandbyDiff}} allows to intercept the exception and attempt loading its
binary properties.
I have attached a patch that contains
1. a test that reproduce the issue
2. the fix for the trunk
Could you have a look at the patch ?
This issue affects the previous standby implementation ({{oak-tarmk-standby}}).
Should I open a separate issue for tracking the fix there (AFAIK, it is not
strictly speaking a backport) ?
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
>
[jira] [Updated] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4969:
Description:
1. In a setup composed of two instances (primary, standby) configured with a
custom blob store (File blob store).
2. On the primary instance, set/update a BINARY property of an existing
resource with > 2MB binary.
3. Observe that the standby instance does not fetch the binary and instead,
enters a loop detecting the missing binary upon comparing node states.
For example, the following stack trace would be printed every 5 seconds on the
standby (the polling time is 5sec).
{code}
19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
head' response
19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
synchronizing state.
java.lang.RuntimeException: Error occurred while obtaining InputStream for
blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
at
org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
at
org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
at
org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
at
org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
at com.google.common.base.Objects.equal(Objects.java:55)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
at
org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
at
org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
at
org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:391)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
at
[jira] [Updated] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4969:
Flags: Patch
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:391)
> at
>
[jira] [Updated] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4969:
Attachment: OAK-4969.patch
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4969.patch
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:391)
> at
>
[jira] [Commented] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15616810#comment-15616810
]
Timothee Maret commented on OAK-4969:
-
[~frm] thanks for your insight. I found a clean way to fix this. Actually the
{{StandbyDiff}} allows to intercept the exception and attempt loading its
binary properties.
I have attached a patch that contains
1. a test that reproduce the issue
2. the fix for the trunk
Could you have a look at the patch ?
This issue affects the previous standby implementation ({{oak-tarmk-standby}}).
Should I open a separate issue for tracking the fix there (AFAIK, it is not
strictly speaking a backport) ?
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.6, 1.5.13
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
>
[jira] [Commented] (OAK-5031) Log configuration deprecation messages at WARN level
[
https://issues.apache.org/jira/browse/OAK-5031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15614687#comment-15614687
]
Timothee Maret commented on OAK-5031:
-
[~frm] could you look at the patch ?
> Log configuration deprecation messages at WARN level
>
>
> Key: OAK-5031
> URL: https://issues.apache.org/jira/browse/OAK-5031
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.6
>
> Attachments: OAK-5031.patch
>
>
> The {{StandbyStoreServiceDeprecationError}} and
> {{SegmentNodeStoreServiceDeprecationError}} detect the presence of deprecated
> configurations and log at {{ERROR}} level a warning message.
> The level should be revised to {{WARN}} since having a deprecated
> configuration does not break the instance (it's not an error).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5031) Log configuration deprecation messages at WARN level
[
https://issues.apache.org/jira/browse/OAK-5031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5031:
Attachment: OAK-5031.patch
Attaching a svn compatible patch otherwise available at
https://github.com/tmaret/jackrabbit-oak/commit/9b47749402352058f13f0f61752b18828efd2f9d.diff
> Log configuration deprecation messages at WARN level
>
>
> Key: OAK-5031
> URL: https://issues.apache.org/jira/browse/OAK-5031
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.6
>
> Attachments: OAK-5031.patch
>
>
> The {{StandbyStoreServiceDeprecationError}} and
> {{SegmentNodeStoreServiceDeprecationError}} detect the presence of deprecated
> configurations and log at {{ERROR}} level a warning message.
> The level should be revised to {{WARN}} since having a deprecated
> configuration does not break the instance (it's not an error).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5031) Log configuration deprecation messages at WARN level
[
https://issues.apache.org/jira/browse/OAK-5031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5031:
Flags: Patch
> Log configuration deprecation messages at WARN level
>
>
> Key: OAK-5031
> URL: https://issues.apache.org/jira/browse/OAK-5031
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.6
>
> Attachments: OAK-5031.patch
>
>
> The {{StandbyStoreServiceDeprecationError}} and
> {{SegmentNodeStoreServiceDeprecationError}} detect the presence of deprecated
> configurations and log at {{ERROR}} level a warning message.
> The level should be revised to {{WARN}} since having a deprecated
> configuration does not break the instance (it's not an error).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5031) Log configuration deprecation messages at WARN level
[
https://issues.apache.org/jira/browse/OAK-5031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5031:
Summary: Log configuration deprecation messages at WARN level (was: Log
configuration deprecation error messages at WARN level)
> Log configuration deprecation messages at WARN level
>
>
> Key: OAK-5031
> URL: https://issues.apache.org/jira/browse/OAK-5031
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: 1.6
>
>
> The {{StandbyStoreServiceDeprecationError}} and
> {{SegmentNodeStoreServiceDeprecationError}} detect the presence of deprecated
> configurations and log at {{ERROR}} level a warning message.
> The level should be revised to {{WARN}} since having a deprecated
> configuration does not break the instance (it's not an error).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5031) Log configuration deprecation error messages at WARN level
Timothee Maret created OAK-5031:
---
Summary: Log configuration deprecation error messages at WARN level
Key: OAK-5031
URL: https://issues.apache.org/jira/browse/OAK-5031
Project: Jackrabbit Oak
Issue Type: Task
Components: segment-tar
Affects Versions: Segment Tar 0.0.16
Reporter: Timothee Maret
Assignee: Timothee Maret
Fix For: 1.6
The {{StandbyStoreServiceDeprecationError}} and
{{SegmentNodeStoreServiceDeprecationError}} detect the presence of deprecated
configurations and log at {{ERROR}} level a warning message.
The level should be revised to {{WARN}} since having a deprecated configuration
does not break the instance (it's not an error).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-5017) Standby test failures
[
https://issues.apache.org/jira/browse/OAK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned OAK-5017:
---
Assignee: Timothee Maret
> Standby test failures
> -
>
> Key: OAK-5017
> URL: https://issues.apache.org/jira/browse/OAK-5017
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Timothee Maret
> Labels: test-failure
> Fix For: 1.5.13
>
>
> I've recently seen a couple of the standby tests fail. E.g. on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {{org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes}}:
> {noformat}
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5029) Use head GC generation number to trigger cleanup on standby instance
[
https://issues.apache.org/jira/browse/OAK-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15612268#comment-15612268
]
Timothee Maret commented on OAK-5029:
-
[~frm] could you have a look at the patch ?
> Use head GC generation number to trigger cleanup on standby instance
> -
>
> Key: OAK-5029
> URL: https://issues.apache.org/jira/browse/OAK-5029
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: OAK-5029.patch
>
>
> With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
> instance could be determined by the GC generation number of the head which is
> bound to increase every time a cleanup is ran.
> {code}
> fileStore.getHead().getRecordId().getSegment().getGcGeneration();
> {code}
> The current trigger mechanism consists of detecting a 25% size increase over
> a client cycle (typ. 5 sec).
> This would be dropped in favor of the new detection mechanism.
> The auto-compaction mode would remain configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5029) Use head GC generation number to trigger cleanup on standby instance
[
https://issues.apache.org/jira/browse/OAK-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5029:
Attachment: OAK-5029.patch
Attaching a svn compatible patch, otherwise available at
https://github.com/tmaret/jackrabbit-oak/commit/aa421e549b5b150d56ebd32a6534fe2a432e2fa1
The patch does
1. Change the mechanism to trigger cleanup on standby instance, use the head
segment gc generation number
2. Update the {{standby.autoclean}} OSGI description to reflect the change
> Use head GC generation number to trigger cleanup on standby instance
> -
>
> Key: OAK-5029
> URL: https://issues.apache.org/jira/browse/OAK-5029
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: OAK-5029.patch
>
>
> With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
> instance could be determined by the GC generation number of the head which is
> bound to increase every time a cleanup is ran.
> {code}
> fileStore.getHead().getRecordId().getSegment().getGcGeneration();
> {code}
> The current trigger mechanism consists of detecting a 25% size increase over
> a client cycle (typ. 5 sec).
> This would be dropped in favor of the new detection mechanism.
> The auto-compaction mode would remain configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5029) Use head GC generation number to trigger cleanup on standby instance
[
https://issues.apache.org/jira/browse/OAK-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5029:
Flags: Patch
> Use head GC generation number to trigger cleanup on standby instance
> -
>
> Key: OAK-5029
> URL: https://issues.apache.org/jira/browse/OAK-5029
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: OAK-5029.patch
>
>
> With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
> instance could be determined by the GC generation number of the head which is
> bound to increase every time a cleanup is ran.
> {code}
> fileStore.getHead().getRecordId().getSegment().getGcGeneration();
> {code}
> The current trigger mechanism consists of detecting a 25% size increase over
> a client cycle (typ. 5 sec).
> This would be dropped in favor of the new detection mechanism.
> The auto-compaction mode would remain configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5029) Use head GC generation number to trigger cleanup on standby instance
[
https://issues.apache.org/jira/browse/OAK-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5029:
Description:
With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
instance could be determined by the GC generation number of the head which is
bound to increase every time a cleanup is ran.
{code}
fileStore.getHead().getRecordId().getSegment().getGcGeneration();
{code}
The current trigger mechanism consists of detecting a 25% size increase over a
client cycle (typ. 5 sec).
This would be dropped in favor of the new detection mechanism.
The auto-compaction mode would remain configurable.
was:
With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
instance could be determined by the GC generation number of the head which is
bound to increase every time a cleanup is ran.
{code}
fileStore.getHead().getRecordId().getSegment().getGcGeneration();
{code}
> Use head GC generation number to trigger cleanup on standby instance
> -
>
> Key: OAK-5029
> URL: https://issues.apache.org/jira/browse/OAK-5029
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
> instance could be determined by the GC generation number of the head which is
> bound to increase every time a cleanup is ran.
> {code}
> fileStore.getHead().getRecordId().getSegment().getGcGeneration();
> {code}
> The current trigger mechanism consists of detecting a 25% size increase over
> a client cycle (typ. 5 sec).
> This would be dropped in favor of the new detection mechanism.
> The auto-compaction mode would remain configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5029) Use head GC generation number to trigger cleanup on standby instance
Timothee Maret created OAK-5029:
---
Summary: Use head GC generation number to trigger cleanup on
standby instance
Key: OAK-5029
URL: https://issues.apache.org/jira/browse/OAK-5029
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-tar
Affects Versions: Segment Tar 0.0.16
Reporter: Timothee Maret
Assignee: Timothee Maret
With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
instance could be determined by the GC generation number of the head which is
bound to increase every time a cleanup is ran.
{code}
fileStore.getHead().getRecordId().getSegment().getGcGeneration();
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602221#comment-15602221
]
Timothee Maret commented on OAK-4969:
-
What seems to happen here, is that when the client (stdby instance) compares
the remote and local base states (via {{compareAgainstBaseState}}), it reaches
the point where it needs to compare the local property blob against the remote
property blob. Since the remote property blob is not in the local blob store,
then a NPE is thrown and the comparison fails.
This NPE is never catch and therefor the HTTP request to fetch the missing blob
is never issued.
Indeed, fetching the remote blob is triggered in the
{{o.a.j.o.s.s.c.StandbyDiff}} _after_ the diff has been detected (which in this
case is impossible).
This behaviour occurs on oak-segment-tar and previous segment mk.
[~alexparvulescu], [~frm] does coldstandby support separate blob stores ?
If so, does this appears like a regression. I think it could be solved with
different approaches
1. Have the equal method for SegmentBlob handle the missing blob case (returns
{{false}} instead of throwing exception ; or
2. Have the
{{o.a.j.o.s.s.c.StandbyClientSyncExecution#compareAgainstBaseState}} handle the
missing blob exception and fetch them.
Wdyt ? How did it work before ?
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.18
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
>
[jira] [Assigned] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned OAK-4969:
---
Assignee: Timothee Maret
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:391)
> at
>
[jira] [Issue Comment Deleted] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4969:
Comment: was deleted
(was: Looking at the oak-segment-tar code, the client (standby) should fetch
blobs by sending {{o.a.j.o.s.s.c.GetBlobRequest}} messages to the primary
instance.
The code that is support to fetch blobs is in the code base
({{StandbyDiff#binaryCheck(Blob, java.lang.String)}} to
{{StandbyClient#getBlob}}), however it is never called.
)
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
> at
>
[jira] [Commented] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15592028#comment-15592028
]
Timothee Maret commented on OAK-4969:
-
Looking at the oak-segment-tar code, the client (standby) should fetch blobs by
sending {{o.a.j.o.s.s.c.GetBlobRequest}} messages to the primary instance.
The code that is support to fetch blobs is in the code base
({{StandbyDiff#binaryCheck(Blob, java.lang.String)}} to
{{StandbyClient#getBlob}}), however it is never called.
> ColdStandby does not fetch missing blobs
>
>
> Key: OAK-4969
> URL: https://issues.apache.org/jira/browse/OAK-4969
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.10
>Reporter: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
>
> 1. In a setup composed of two instances (primary, standby) configured with a
> custom blob store (File blob store).
> 2. On the primary instance, set/update a BINARY property of an existing
> resource with > 2MB binary.
> 3. Observe that the standby instance does not fetch the binary and instead,
> enters a loop detecting the missing binary upon comparing node states.
> For example, the following stack trace would be printed every 5 seconds on
> the standby (the polling time is 5sec).
> {code}
> 19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
> org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
> head' response
> 19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
> 19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
> 19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
> org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
> synchronizing state.
> java.lang.RuntimeException: Error occurred while obtaining InputStream for
> blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
> at
> org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
> at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
> at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
> at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
> at com.google.common.base.Objects.equal(Objects.java:55)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
> at
> org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
> at
>
[jira] [Updated] (OAK-4969) ColdStandby does not fetch missing blobs
[
https://issues.apache.org/jira/browse/OAK-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4969:
Description:
1. In a setup composed of two instances (primary, standby) configured with a
custom blob store (File blob store).
2. On the primary instance, set/update a BINARY property of an existing
resource with > 2MB binary.
3. Observe that the standby instance does not fetch the binary and instead,
enters a loop detecting the missing binary upon comparing node states.
For example, the following stack trace would be printed every 5 seconds on the
standby (the polling time is 5sec).
{code}
19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
head' response
19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
synchronizing state.
java.lang.RuntimeException: Error occurred while obtaining InputStream for
blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
at
org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
at
org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
at
org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
at
org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
at com.google.common.base.Objects.equal(Objects.java:55)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
at
org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
at
org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
at
org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:391)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
at
[jira] [Created] (OAK-4969) ColdStandby does not fetch missing blobs
Timothee Maret created OAK-4969:
---
Summary: ColdStandby does not fetch missing blobs
Key: OAK-4969
URL: https://issues.apache.org/jira/browse/OAK-4969
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-tar
Affects Versions: Segment Tar 0.0.10
Reporter: Timothee Maret
Fix For: Segment Tar 0.0.16
1. In a setup composed of two instances (primary, standdy) configured with a
custom blob store (File blob store).
2. On the primary instance, set/update a BINARY property of an existing
resource with > 2MB binary.
3. Observe that the standby instance does not fetch the binary and instead,
enters a loop detecting the missing binary upon comparing node states.
For example, the following stack trace would be printed every 5 seconds on the
standby (the polling time is 5sec).
{code}
19.10.2016 16:22:38.035 *DEBUG* [nioEventLoopGroup-1005-1]
org.apache.jackrabbit.oak.segment.standby.codec.ResponseDecoder Decoding 'get
head' response
19.10.2016 16:22:38.038 *DEBUG* [sling-default-81-Registered Service.607]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Channel closed
19.10.2016 16:22:40.241 *DEBUG* [sling-default-81-Registered Service.607]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClient Group shut down
19.10.2016 16:22:40.242 *ERROR* [sling-default-81-Registered Service.607]
org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSync Failed
synchronizing state.
java.lang.RuntimeException: Error occurred while obtaining InputStream for
blobId [4dfc748c91d518c9221031ec6115fd7ac04fe27b#10]
at
org.apache.jackrabbit.oak.plugins.blob.BlobStoreBlob.getNewStream(BlobStoreBlob.java:49)
at
org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:252)
at
org.apache.jackrabbit.oak.segment.SegmentBlob.getNewStream(SegmentBlob.java:87)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:45)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractBlob$1.getInput(AbstractBlob.java:42)
at com.google.common.io.ByteStreams$3.openStream(ByteStreams.java:907)
at com.google.common.io.ByteSource.contentEquals(ByteSource.java:301)
at com.google.common.io.ByteStreams.equal(ByteStreams.java:661)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractBlob.equal(AbstractBlob.java:68)
at
org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:193)
at com.google.common.base.Objects.equal(Objects.java:55)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:53)
at
org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:622)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:516)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:415)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:457)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
at
org.apache.jackrabbit.oak.segment.MapRecord$2.childNodeChanged(MapRecord.java:401)
at
org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:391)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:609)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.process(StandbyDiff.java:216)
at
org.apache.jackrabbit.oak.segment.standby.client.StandbyDiff.childNodeChanged(StandbyDiff.java:186)
at
[jira] [Updated] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4883:
Attachment: OAK-4883.patch
Attaching updated patch
cc [~frm]
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch, OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568540#comment-15568540
]
Timothee Maret commented on OAK-4883:
-
Good catch, you are correct. I'll update the patch against the latest trunk,
thanks!
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568482#comment-15568482
]
Timothee Maret commented on OAK-4883:
-
[~frm] I assume you mean that line [0]. If so, it behaves the same as before
the patch in OAK-4089. A node store instance is build however it is registered
only if the instance is *not* a primary [1].
The patch keeps the goal of OAK-4089, by not registering the observation
subsystem as mentioned in [2].
AFAIU, a node store instance is required in order to build the {{BlobGCMBean}}.
I may be wrong about that or maybe there's a way to get the required
information to build the {{BlobGCMBean}}. If so I'd be happy to update the
patch.
[0]
https://github.com/tmaret/jackrabbit-oak/blob/OAK-4883/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStoreService.java#L339
[1]
https://github.com/tmaret/jackrabbit-oak/blob/OAK-4883/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStoreService.java#L340
[2]
https://github.com/apache/jackrabbit-oak/blob/2b6c2f5340f3b6485dda5c493f6343d232c883e9/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentNodeStoreService.java#L595
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
[
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568265#comment-15568265
]
Timothee Maret commented on OAK-4926:
-
Thanks [~frm] for looking at this and for the suggestion. Please find a
simplified patch attached.
> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch, OAK-4926.patch
>
>
> Currently the method
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
> does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level
> statement. The SNFE is needed but not the log statement in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
[
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4926:
Attachment: OAK-4926.patch
> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch, OAK-4926.patch
>
>
> Currently the method
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
> does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level
> statement. The SNFE is needed but not the log statement in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
[
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4926:
Summary: o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect
missing segment (was: o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should
except missing segment)
> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch
>
>
> Currently the method
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
> does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level
> statement. The SNFE is needed but not the log statement in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned OAK-4883:
---
Assignee: Timothee Maret
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
[
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned OAK-4926:
---
Assignee: Timothee Maret
> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch
>
>
> Currently the method
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
> does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level
> statement. The SNFE is needed but not the log statement in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
[
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565910#comment-15565910
]
Timothee Maret commented on OAK-4926:
-
[~frm] could you look at the patch please ?
> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch
>
>
> Currently the method
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
> does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level
> statement. The SNFE is needed but not the log statement in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
[
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4926:
Attachment: OAK-4926.patch
Attaching a svn compatible patch, otherwise available at
https://github.com/tmaret/jackrabbit-oak/commit/2a6f4b47074966a895692ef7de764f9902c7adfb.patch
> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch
>
>
> Currently the method
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
> does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level
> statement. The SNFE is needed but not the log statement in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
[
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4926:
Flags: Patch
> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch
>
>
> Currently the method
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
> does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level
> statement. The SNFE is needed but not the log statement in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
Timothee Maret created OAK-4926:
---
Summary: o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should
except missing segment
Key: OAK-4926
URL: https://issues.apache.org/jira/browse/OAK-4926
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-tar
Affects Versions: Segment Tar 0.0.14
Reporter: Timothee Maret
Fix For: Segment Tar 0.0.16
Currently the method
{{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
does invoke
{code}
referencedId.getSegment();
{code}
in order to read the referenced segment. In case of missing segment, the
{{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level
statement. The SNFE is needed but not the log statement in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4917) DefaultStandbyReferencesReader does not re-attempt to read segment upon failure
[
https://issues.apache.org/jira/browse/OAK-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4917:
Flags: Patch
> DefaultStandbyReferencesReader does not re-attempt to read segment upon
> failure
>
>
> Key: OAK-4917
> URL: https://issues.apache.org/jira/browse/OAK-4917
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4917.patch
>
>
> This following logs occurred while running integration testing.
> {code}
> 07.10.2016 16:50:30.882 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.codec.GetHeadResponseEncoder
> Sending head 9d91bcd2-c4e0-4411-a0e0-d358fff02afc.0020 to client
> qastandby1
> 07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.codec.RequestDecoder Parsed 'get
> references' message
> 07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler
> Reading references of segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc for client
> qastandby1
> 07.10.2016 16:50:30.886 *WARN* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader
> Unable to read segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc
> org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment
> 9d91bcd2-c4e0-4411-a0e0-d358fff02afc not found
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1364)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1304)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.load(CacheLIRS.java:1013)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.get(CacheLIRS.java:974)
> at org.apache.jackrabbit.oak.cache.CacheLIRS.get(CacheLIRS.java:285)
> at
> org.apache.jackrabbit.oak.segment.SegmentCache.getSegment(SegmentCache.java:92)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:1304)
> at
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readSegment(DefaultStandbyReferencesReader.java:66)
> at
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readReferences(DefaultStandbyReferencesReader.java:49)
> at
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:41)
> at
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:27)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
>
[jira] [Commented] (OAK-4917) DefaultStandbyReferencesReader does not re-attempt to read segment upon failure
[
https://issues.apache.org/jira/browse/OAK-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15562611#comment-15562611
]
Timothee Maret commented on OAK-4917:
-
[~alexparvulescu], [~frm], [~mduerig] could you review the patch ?
> DefaultStandbyReferencesReader does not re-attempt to read segment upon
> failure
>
>
> Key: OAK-4917
> URL: https://issues.apache.org/jira/browse/OAK-4917
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4917.patch
>
>
> This following logs occurred while running integration testing.
> {code}
> 07.10.2016 16:50:30.882 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.codec.GetHeadResponseEncoder
> Sending head 9d91bcd2-c4e0-4411-a0e0-d358fff02afc.0020 to client
> qastandby1
> 07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.codec.RequestDecoder Parsed 'get
> references' message
> 07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler
> Reading references of segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc for client
> qastandby1
> 07.10.2016 16:50:30.886 *WARN* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader
> Unable to read segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc
> org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment
> 9d91bcd2-c4e0-4411-a0e0-d358fff02afc not found
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1364)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1304)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.load(CacheLIRS.java:1013)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.get(CacheLIRS.java:974)
> at org.apache.jackrabbit.oak.cache.CacheLIRS.get(CacheLIRS.java:285)
> at
> org.apache.jackrabbit.oak.segment.SegmentCache.getSegment(SegmentCache.java:92)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:1304)
> at
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readSegment(DefaultStandbyReferencesReader.java:66)
> at
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readReferences(DefaultStandbyReferencesReader.java:49)
> at
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:41)
> at
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:27)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
>
[jira] [Updated] (OAK-4917) DefaultStandbyReferencesReader does not re-attempt to read segment upon failure
[
https://issues.apache.org/jira/browse/OAK-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4917:
Attachment: OAK-4917.patch
Attaching a svn compatible patch otherwise available at
https://github.com/tmaret/jackrabbit-oak/commit/bbe213e5fad7e32aca09aa6a225db6246ea80f10.patch
> DefaultStandbyReferencesReader does not re-attempt to read segment upon
> failure
>
>
> Key: OAK-4917
> URL: https://issues.apache.org/jira/browse/OAK-4917
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4917.patch
>
>
> This following logs occurred while running integration testing.
> {code}
> 07.10.2016 16:50:30.882 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.codec.GetHeadResponseEncoder
> Sending head 9d91bcd2-c4e0-4411-a0e0-d358fff02afc.0020 to client
> qastandby1
> 07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.codec.RequestDecoder Parsed 'get
> references' message
> 07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler
> Reading references of segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc for client
> qastandby1
> 07.10.2016 16:50:30.886 *WARN* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader
> Unable to read segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc
> org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment
> 9d91bcd2-c4e0-4411-a0e0-d358fff02afc not found
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1364)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1304)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.load(CacheLIRS.java:1013)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.get(CacheLIRS.java:974)
> at org.apache.jackrabbit.oak.cache.CacheLIRS.get(CacheLIRS.java:285)
> at
> org.apache.jackrabbit.oak.segment.SegmentCache.getSegment(SegmentCache.java:92)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:1304)
> at
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readSegment(DefaultStandbyReferencesReader.java:66)
> at
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readReferences(DefaultStandbyReferencesReader.java:49)
> at
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:41)
> at
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:27)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
>
[jira] [Assigned] (OAK-4917) DefaultStandbyReferencesReader does not re-attempt to read segment upon failure
[
https://issues.apache.org/jira/browse/OAK-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned OAK-4917:
---
Assignee: Timothee Maret
> DefaultStandbyReferencesReader does not re-attempt to read segment upon
> failure
>
>
> Key: OAK-4917
> URL: https://issues.apache.org/jira/browse/OAK-4917
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
>
> This following logs occurred while running integration testing.
> {code}
> 07.10.2016 16:50:30.882 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.codec.GetHeadResponseEncoder
> Sending head 9d91bcd2-c4e0-4411-a0e0-d358fff02afc.0020 to client
> qastandby1
> 07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.codec.RequestDecoder Parsed 'get
> references' message
> 07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler
> Reading references of segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc for client
> qastandby1
> 07.10.2016 16:50:30.886 *WARN* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader
> Unable to read segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc
> org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment
> 9d91bcd2-c4e0-4411-a0e0-d358fff02afc not found
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1364)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1304)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.load(CacheLIRS.java:1013)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.get(CacheLIRS.java:974)
> at org.apache.jackrabbit.oak.cache.CacheLIRS.get(CacheLIRS.java:285)
> at
> org.apache.jackrabbit.oak.segment.SegmentCache.getSegment(SegmentCache.java:92)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:1304)
> at
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readSegment(DefaultStandbyReferencesReader.java:66)
> at
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readReferences(DefaultStandbyReferencesReader.java:49)
> at
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:41)
> at
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:27)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
>
[jira] [Commented] (OAK-4917) DefaultStandbyReferencesReader does not re-attempt to read segment upon failure
[
https://issues.apache.org/jira/browse/OAK-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15562576#comment-15562576
]
Timothee Maret commented on OAK-4917:
-
Discussing this with [~alexparvulescu], it seems this is expected and in fact
the cold stdby code deal with it by re-trying to load in a loop with a delay.
This looping behaviour is already implemented in the
{{DefaultStandbySegmentReader}} [0]. However the
{{DefaultStandbyReferencesReader}} does not contains the loop, causing the
issue.
[0]
https://github.com/apache/jackrabbit-oak/blob/066edc9eb5ef500339de0ebf7859e7ee9dd3ab4b/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/standby/server/DefaultStandbySegmentReader.java
> DefaultStandbyReferencesReader does not re-attempt to read segment upon
> failure
>
>
> Key: OAK-4917
> URL: https://issues.apache.org/jira/browse/OAK-4917
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
>
> This following logs occurred while running integration testing.
> {code}
> 07.10.2016 16:50:30.882 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.codec.GetHeadResponseEncoder
> Sending head 9d91bcd2-c4e0-4411-a0e0-d358fff02afc.0020 to client
> qastandby1
> 07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.codec.RequestDecoder Parsed 'get
> references' message
> 07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler
> Reading references of segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc for client
> qastandby1
> 07.10.2016 16:50:30.886 *WARN* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader
> Unable to read segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc
> org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment
> 9d91bcd2-c4e0-4411-a0e0-d358fff02afc not found
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1364)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1304)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.load(CacheLIRS.java:1013)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.get(CacheLIRS.java:974)
> at org.apache.jackrabbit.oak.cache.CacheLIRS.get(CacheLIRS.java:285)
> at
> org.apache.jackrabbit.oak.segment.SegmentCache.getSegment(SegmentCache.java:92)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:1304)
> at
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readSegment(DefaultStandbyReferencesReader.java:66)
> at
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readReferences(DefaultStandbyReferencesReader.java:49)
> at
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:41)
> at
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:27)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
>
[jira] [Commented] (OAK-4917) DefaultStandbyReferencesReader does not re-attempt to read segment upon failure
[
https://issues.apache.org/jira/browse/OAK-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15562564#comment-15562564
]
Timothee Maret commented on OAK-4917:
-
Looking a bit further, both readers ({{DefaultStandbyHeadReader}} and
{{DefaultStandbyReferencesReader}}) do go through the
{{org.apache.jackrabbit.oak.segment.file.FileStore}} in order to fetch data.
However, both methods seem to use different caches.
The root cause of this issue seems to be those two cache not being in sync.
{{org.apache.jackrabbit.oak.segment.file.FileStore#getHead}} does use the
CachingSegmentReader segment Reader.
{{org.apache.jackrabbit.oak.segment.file.FileStore#readSegment}} does use the
SegmentCache segment cache in the FileStore.
> DefaultStandbyReferencesReader does not re-attempt to read segment upon
> failure
>
>
> Key: OAK-4917
> URL: https://issues.apache.org/jira/browse/OAK-4917
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
>
> This following logs occurred while running integration testing.
> {code}
> 07.10.2016 16:50:30.882 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.codec.GetHeadResponseEncoder
> Sending head 9d91bcd2-c4e0-4411-a0e0-d358fff02afc.0020 to client
> qastandby1
> 07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.codec.RequestDecoder Parsed 'get
> references' message
> 07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler
> Reading references of segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc for client
> qastandby1
> 07.10.2016 16:50:30.886 *WARN* [nioEventLoopGroup-3-2]
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader
> Unable to read segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc
> org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment
> 9d91bcd2-c4e0-4411-a0e0-d358fff02afc not found
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1364)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1304)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.load(CacheLIRS.java:1013)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.get(CacheLIRS.java:974)
> at org.apache.jackrabbit.oak.cache.CacheLIRS.get(CacheLIRS.java:285)
> at
> org.apache.jackrabbit.oak.segment.SegmentCache.getSegment(SegmentCache.java:92)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:1304)
> at
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readSegment(DefaultStandbyReferencesReader.java:66)
> at
> org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readReferences(DefaultStandbyReferencesReader.java:49)
> at
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:41)
> at
> org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:27)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
> at
>
[jira] [Updated] (OAK-4917) DefaultStandbyReferencesReader does not re-attempt to read segment upon failure
[
https://issues.apache.org/jira/browse/OAK-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4917:
Description:
This following logs occurred while running integration testing.
{code}
07.10.2016 16:50:30.882 *DEBUG* [nioEventLoopGroup-3-2]
org.apache.jackrabbit.oak.segment.standby.codec.GetHeadResponseEncoder Sending
head 9d91bcd2-c4e0-4411-a0e0-d358fff02afc.0020 to client qastandby1
07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
org.apache.jackrabbit.oak.segment.standby.codec.RequestDecoder Parsed 'get
references' message
07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler
Reading references of segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc for client
qastandby1
07.10.2016 16:50:30.886 *WARN* [nioEventLoopGroup-3-2]
org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader
Unable to read segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc
org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment
9d91bcd2-c4e0-4411-a0e0-d358fff02afc not found
at
org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1364)
at
org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1304)
at
org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.load(CacheLIRS.java:1013)
at
org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.get(CacheLIRS.java:974)
at org.apache.jackrabbit.oak.cache.CacheLIRS.get(CacheLIRS.java:285)
at
org.apache.jackrabbit.oak.segment.SegmentCache.getSegment(SegmentCache.java:92)
at
org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:1304)
at
org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readSegment(DefaultStandbyReferencesReader.java:66)
at
org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readReferences(DefaultStandbyReferencesReader.java:49)
at
org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:41)
at
org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:27)
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
at
org.apache.jackrabbit.oak.segment.standby.server.RequestObserverHandler.channelRead(RequestObserverHandler.java:53)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
at
io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
at
org.apache.jackrabbit.oak.segment.standby.server.StateHandler.channelRead(StateHandler.java:62)
at
[jira] [Updated] (OAK-4917) DefaultStandbyReferencesReader does not re-attempt to read segment upon failure
[
https://issues.apache.org/jira/browse/OAK-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4917:
Description:
This following logs occurred while running integration testing.
{code}07.10.2016 16:50:30.882 *DEBUG* [nioEventLoopGroup-3-2]
org.apache.jackrabbit.oak.segment.standby.codec.GetHeadResponseEncoder Sending
head 9d91bcd2-c4e0-4411-a0e0-d358fff02afc.0020 to client qastandby1
07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
org.apache.jackrabbit.oak.segment.standby.codec.RequestDecoder Parsed 'get
references' message
07.10.2016 16:50:30.885 *DEBUG* [nioEventLoopGroup-3-2]
org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler
Reading references of segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc for client
qastandby1
07.10.2016 16:50:30.886 *WARN* [nioEventLoopGroup-3-2]
org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader
Unable to read segment 9d91bcd2-c4e0-4411-a0e0-d358fff02afc
org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment
9d91bcd2-c4e0-4411-a0e0-d358fff02afc not found
at
org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1364)
at
org.apache.jackrabbit.oak.segment.file.FileStore$18.call(FileStore.java:1304)
at
org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.load(CacheLIRS.java:1013)
at
org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.get(CacheLIRS.java:974)
at org.apache.jackrabbit.oak.cache.CacheLIRS.get(CacheLIRS.java:285)
at
org.apache.jackrabbit.oak.segment.SegmentCache.getSegment(SegmentCache.java:92)
at
org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:1304)
at
org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readSegment(DefaultStandbyReferencesReader.java:66)
at
org.apache.jackrabbit.oak.segment.standby.server.DefaultStandbyReferencesReader.readReferences(DefaultStandbyReferencesReader.java:49)
at
org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:41)
at
org.apache.jackrabbit.oak.segment.standby.server.GetReferencesRequestHandler.channelRead0(GetReferencesRequestHandler.java:27)
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
at
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:108)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
at
org.apache.jackrabbit.oak.segment.standby.server.RequestObserverHandler.channelRead(RequestObserverHandler.java:53)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
at
io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
at
org.apache.jackrabbit.oak.segment.standby.server.StateHandler.channelRead(StateHandler.java:62)
at
[jira] [Created] (OAK-4917) DefaultStandbyReferencesReader does not re-attempt to read segment upon failure
Timothee Maret created OAK-4917: --- Summary: DefaultStandbyReferencesReader does not re-attempt to read segment upon failure Key: OAK-4917 URL: https://issues.apache.org/jira/browse/OAK-4917 Project: Jackrabbit Oak Issue Type: Bug Components: segment-tar Affects Versions: Segment Tar 0.0.14 Reporter: Timothee Maret Fix For: Segment Tar 0.0.16 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4883:
Assignee: (was: Timothee Maret)
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15551967#comment-15551967
]
Timothee Maret edited comment on OAK-4883 at 10/6/16 1:51 PM:
--
Attaching a svn compatible patch otherwise available at
https://github.com/tmaret/jackrabbit-oak/commit/5e5370b81c8409af489ec4dee9064082a350dc48.patch
The patch builds a SegmentNodeStore independently of the configuration, however
it only register its service for non standby instances.
Moreover, it keeps the OAK-4089 improvement by only building a
{{ChangeDispatcher}} for non standby instances (as suggested in OAK-4089).
The patch only contains the fix for the new segment-tar.
The patch uses this {{null}} ref in {{SegmentNodeStore}}. We could improve that
by building a custom {{ChangeDispatcher}} (e.g. {{NoopChangeDispatcher}}) and
allow to pass the {{ChangeDispatcher}} via the builder. However, currently
there's no easy way to build a custom ChangeDispatcher without passing a
NodeState (which is what we want to avoid).
was (Author: marett):
Attaching a svn compatible patch otherwise available at
https://github.com/tmaret/jackrabbit-oak/commit/5e5370b81c8409af489ec4dee9064082a350dc48.patch
The patch builds a SegmentNodeStore independently of the configuration, however
it only register its service for non standby instances.
Moreover, it keeps the OAK-4089 improvement by only building a
{{ChangeDispatcher}} for non standby instances (as suggested in OAK-4089).
The patch only contains the fix for the new segment-tar.
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15551968#comment-15551968
]
Timothee Maret commented on OAK-4883:
-
[~alexparvulescu], [~frm] could you please review.
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4883:
Flags: Patch
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-4883:
Attachment: OAK-4883.patch
Attaching a svn compatible patch otherwise available at
https://github.com/tmaret/jackrabbit-oak/commit/5e5370b81c8409af489ec4dee9064082a350dc48.patch
The patch builds a SegmentNodeStore independently of the configuration, however
it only register its service for non standby instances.
Moreover, it keeps the OAK-4089 improvement by only building a
{{ChangeDispatcher}} for non standby instances (as suggested in OAK-4089).
The patch only contains the fix for the new segment-tar.
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15548300#comment-15548300
]
Timothee Maret commented on OAK-4883:
-
Thanks [~alexparvulescu] for clarifying.
With the current code (segment-tar) a standby instance will not instantiate a
{{SegmentNodeStore}} due to the check at [0]. AFAIU, this was introduced in
OAK-4089 (before the code that issue, the code was registering a
{{SegmentNodeStore}}).
A {{SegmentNodeStore}} seems to be required in order to register a
{{BlobGCMBean}}.
Indeed the {{BlobGCMBean}} needs a {{MarkSweepGarbageCollector}} which needs a
{{repoId}} which is obtained via a {{SegmentNodeStore}}.
AFAIU, we'd need to register a {{SegmentNodeStore}} while keeping the fix for
OAK-4089.
[~frm] in OAK-4089 you wrote:
bq. It would be more appropriate not to instantiate the observation subsystem
at all in the context of the standby store, thus preventing spurious references
to SegmentId instances to float in memory.
With "observation subsystem", were you referring to the {{observerTracker}} in
[1] ?
If so, how about building a {{SegmentNodeStore}} in any case, but only avoid
registering {{observerTracker}} for standby instances ?
[0]
https://github.com/apache/jackrabbit-oak/blob/2b6c2f5340f3b6485dda5c493f6343d232c883e9/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentNodeStoreService.java#L374
[1]
https://github.com/apache/jackrabbit-oak/blob/2b6c2f5340f3b6485dda5c493f6343d232c883e9/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentNodeStoreService.java#L595
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance
[
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15546504#comment-15546504
]
Timothee Maret commented on OAK-4883:
-
[~alexparvulescu], [~frm] debugging the code with a default primary instance
(File nodestore, no custom blob store), it appears the reason there's no
{{BlobGCMBean}} is due to the fact that
{code}
store.getBlobStore()
{code}
returns {{null}} and therefor, the check at [0] can't be satisfied which cause
the {{BlobGCMBean}} not to be registered. This occurs with a standby instance
as well. Looking at the code and the change at [1], it seems to me that the
logic for the primary case has not changed and that the only way to have a
BlobGCMBean registered is to have a custom blob store configured.
Before digging further, could you help me understand whether it is expected
that the {{store.getBlobStore()}} may return null in some setups
[0]
https://github.com/apache/jackrabbit-oak/blob/2b6c2f5340f3b6485dda5c493f6343d232c883e9/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentNodeStoreService.java#L646
[1]
https://github.com/tmaret/jackrabbit-oak/commit/982bc43374a4564726b8b77454c3803b691bac24
> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
> Labels: gc
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby
> instance, this affects non-shared datastore setups (on a shared datastore
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with
> OAK-4093).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
