[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&focusedCommentId=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 > org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.createNode(DocViewSAX
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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 > org.apache.jackrabbit.oak.segment.standby.
[jira] [Commented] (OAK-5017) Standby test failures
[ https://issues.apache.org/jira/browse/OAK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.
[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&focusedCommentId=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 > org.apache.jackrabbit.oa
[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 > org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:39
[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 > org.apache.jackrabbit.oak.segment.Segme
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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 > org.a
[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 org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.compareAgainstBaseState(StandbyClientS
[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 > org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAg
[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 > org.apache.jackrabbit.oak.segment.SegmentNodeS
[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&focusedCommentId=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 > org.apache
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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) >
[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 > org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState
[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 > org.apache.jackrabbit.oak.segment.MapRec
[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&focusedCommentId=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 > org.apache.jackr
[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 org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution.compareAgainstBaseState(StandbyClientS
[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 org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:485)
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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 > org.apache.jackrabbit.oak.segment.standby.server.RequestObserverHandler.
[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&focusedCommentId=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 > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandl
[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 > io.netty.channel.Abstr
[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 > org.apache.jackrabbit.oak.segment.standby.server.RequestObserverHandler.channelRead(RequestOb
[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&focusedCommentId=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 > io.netty.channel.SimpleChannel
[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&focusedCommentId=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 > io.netty.chan
[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 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:36
[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 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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)