[jira] [Commented] (OAK-8989) Build Jackrabbit Oak #2686 failed
[ https://issues.apache.org/jira/browse/OAK-8989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072075#comment-17072075 ] Hudson commented on OAK-8989: - Build is still failing. Failed run: [Jackrabbit Oak #2687|https://builds.apache.org/job/Jackrabbit%20Oak/2687/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2687/console] > Build Jackrabbit Oak #2686 failed > - > > Key: OAK-8989 > URL: https://issues.apache.org/jira/browse/OAK-8989 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2686 has failed. > First failed run: [Jackrabbit Oak > #2686|https://builds.apache.org/job/Jackrabbit%20Oak/2686/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2686/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8989) Build Jackrabbit Oak #2686 failed
Hudson created OAK-8989: --- Summary: Build Jackrabbit Oak #2686 failed Key: OAK-8989 URL: https://issues.apache.org/jira/browse/OAK-8989 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #2686 has failed. First failed run: [Jackrabbit Oak #2686|https://builds.apache.org/job/Jackrabbit%20Oak/2686/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2686/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8978) Cache facet results
[ https://issues.apache.org/jira/browse/OAK-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071874#comment-17071874 ] Mohit Kataria edited comment on OAK-8978 at 3/31/20, 4:29 PM: -- trunk commit revision: [http://svn.apache.org/viewvc?view=revision=1875940] [http://svn.apache.org/viewvc?view=revision=1875948] 1.22 commit revision: [http://svn.apache.org/viewvc?view=revision=1875945] [http://svn.apache.org/viewvc?view=revision=1875950] CC: [~thomasm] was (Author: mkataria): trunk commit revision: [http://svn.apache.org/viewvc?view=revision=1875940] 1.22 commit revision: [http://svn.apache.org/viewvc?view=revision=1875945] CC: [~thomasm] > Cache facet results > --- > > Key: OAK-8978 > URL: https://issues.apache.org/jira/browse/OAK-8978 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.22.3, 1.28.0 > > Attachments: OAK-8978-2.patch > > > In OAK-8898, the "AlreadyClosedException" was fixed when reading facet > results. > If the facets are read repeatedly (for each row), then the reader is now > opened and closed each time. This can slow down the application. > It should be possible to cache the facet result in DelayedLuceneFacetProvider -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8978) Cache facet results
[ https://issues.apache.org/jira/browse/OAK-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071874#comment-17071874 ] Mohit Kataria commented on OAK-8978: trunk commit revision: [http://svn.apache.org/viewvc?view=revision=1875940] 1.22 commit revision: [http://svn.apache.org/viewvc?view=revision=1875945] CC: [~thomasm] > Cache facet results > --- > > Key: OAK-8978 > URL: https://issues.apache.org/jira/browse/OAK-8978 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Attachments: OAK-8978-2.patch > > > In OAK-8898, the "AlreadyClosedException" was fixed when reading facet > results. > If the facets are read repeatedly (for each row), then the reader is now > opened and closed each time. This can slow down the application. > It should be possible to cache the facet result in DelayedLuceneFacetProvider -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8978) Cache facet results
[ https://issues.apache.org/jira/browse/OAK-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Kataria resolved OAK-8978. Fix Version/s: 1.28.0 1.22.3 Resolution: Fixed > Cache facet results > --- > > Key: OAK-8978 > URL: https://issues.apache.org/jira/browse/OAK-8978 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.22.3, 1.28.0 > > Attachments: OAK-8978-2.patch > > > In OAK-8898, the "AlreadyClosedException" was fixed when reading facet > results. > If the facets are read repeatedly (for each row), then the reader is now > opened and closed each time. This can slow down the application. > It should be possible to cache the facet result in DelayedLuceneFacetProvider -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8769: Attachment: (was: OAK-8769-2.patch) > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-dep-updates.diff, OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8769: Attachment: OAK-8769-2.patch > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-dep-updates.diff, > OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8984) A big number of NOOP changes can result in a StackOverflow
[ https://issues.apache.org/jira/browse/OAK-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-8984. --- Fix Version/s: 1.28.0 Resolution: Fixed Thanks for reporting and the collaboration on the patch. I slightly changed it and put the restriction of the stack size into the JVM options for the entire test run. In trunk: http://svn.apache.org/r1875929 > A big number of NOOP changes can result in a StackOverflow > -- > > Key: OAK-8984 > URL: https://issues.apache.org/jira/browse/OAK-8984 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: José Andrés Cordero Benítez >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.28.0 > > Attachments: infinite-recursion-OAK-8984.patch > > > We have a case where a sync job sometimes produce a StackOverflow when a big > number of NOOP changes are executed. The problem could be related with the > wrapping of a new ModifiedDocumentNodeState object in every call. > If the number of changes don't reach the UpdateLimit value, if will continue > creating objects until it throws a StackOverflow error. > The problem only happens in very specific conditions, but with help of > [~mreutegg] we were able to reproduce in a test that artificially recreates > the situation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8984) A big number of NOOP changes can result in a StackOverflow
[ https://issues.apache.org/jira/browse/OAK-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-8984: -- Priority: Minor (was: Major) > A big number of NOOP changes can result in a StackOverflow > -- > > Key: OAK-8984 > URL: https://issues.apache.org/jira/browse/OAK-8984 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: José Andrés Cordero Benítez >Assignee: Marcel Reutegger >Priority: Minor > Attachments: infinite-recursion-OAK-8984.patch > > > We have a case where a sync job sometimes produce a StackOverflow when a big > number of NOOP changes are executed. The problem could be related with the > wrapping of a new ModifiedDocumentNodeState object in every call. > If the number of changes don't reach the UpdateLimit value, if will continue > creating objects until it throws a StackOverflow error. > The problem only happens in very specific conditions, but with help of > [~mreutegg] we were able to reproduce in a test that artificially recreates > the situation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OAK-8984) A big number of NOOP changes can result in a StackOverflow
[ https://issues.apache.org/jira/browse/OAK-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned OAK-8984: - Assignee: Marcel Reutegger > A big number of NOOP changes can result in a StackOverflow > -- > > Key: OAK-8984 > URL: https://issues.apache.org/jira/browse/OAK-8984 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: José Andrés Cordero Benítez >Assignee: Marcel Reutegger >Priority: Major > Attachments: infinite-recursion-OAK-8984.patch > > > We have a case where a sync job sometimes produce a StackOverflow when a big > number of NOOP changes are executed. The problem could be related with the > wrapping of a new ModifiedDocumentNodeState object in every call. > If the number of changes don't reach the UpdateLimit value, if will continue > creating objects until it throws a StackOverflow error. > The problem only happens in very specific conditions, but with help of > [~mreutegg] we were able to reproduce in a test that artificially recreates > the situation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8986) Segment flush thread can remanin in TIMED_WAITING state even when segment queue is empty
[
https://issues.apache.org/jira/browse/OAK-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miroslav Smiljanic updated OAK-8986:
Attachment: test_and_proposed_patch.patch
> Segment flush thread can remanin in TIMED_WAITING state even when segment
> queue is empty
>
>
> Key: OAK-8986
> URL: https://issues.apache.org/jira/browse/OAK-8986
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Affects Versions: 1.24.0, 1.26.0
>Reporter: Miroslav Smiljanic
>Priority: Major
> Attachments: proposed_patch.patch, test.patch,
> test_and_proposed_patch.patch
>
>
> If thread is in interrupted state, during execution of [SegmentWriteQueue.
> addToQueue
> |https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.26.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/queue/SegmentWriteQueue.java#L166]
> InterruptedException will be thrown and wrapped in IOException.
> Right befire calling queue.offer, element is added to segmentsByUUID map, and
> never removed.
> Normally that happens in thread that reads from
> [queue|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.26.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/queue/SegmentWriteQueue.java#L100],
> and that invokes [consume(SegmentWriteAction
> segment).|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.26.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/queue/SegmentWriteQueue.java#L117]
> Since item is not removed form the segmentsByUUID map,
> [flusher|http://[https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.26.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/queue/SegmentWriteQueue.java#L183]]
> thread will remain in TIMED_WAITING state.
> TarMK flush thread holds exclusivelly monitor needed by number of other
> threads, causing repository to be blocked.
> {noformat}
> "TarMK flush [/opt/aem/launcher/repository/segmentstore-composite-global]"
> #82 daemon prio=5 os_prio=0 cpu=83628.24ms elapsed=291420.48s
> tid=0x7fce902f3000 nid=0x1c2b in Object.wait() [0x7fce00aa5000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(java.base@11.0.3/Native Method)
> - waiting on
> at
> org.apache.jackrabbit.oak.segment.azure.queue.SegmentWriteQueue.flush(SegmentWriteQueue.java:183)
> - waiting to re-lock in wait() <0x0006b4911830> (a
> java.util.concurrent.ConcurrentHashMap)
> at
> org.apache.jackrabbit.oak.segment.azure.AzureSegmentArchiveWriter.flush(AzureSegmentArchiveWriter.java:187)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarWriter.flush(TarWriter.java:186)
> - locked <0x0006b4911960> (a java.lang.Object)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarFiles.flush(TarFiles.java:535)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.lambda$tryFlush$9(FileStore.java:359)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$$Lambda$232/0x00080067ac40.flush(Unknown
> Source)
> at
> org.apache.jackrabbit.oak.segment.file.TarRevisions.doFlush(TarRevisions.java:236)
> at
> org.apache.jackrabbit.oak.segment.file.TarRevisions.tryFlush(TarRevisions.java:216)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.tryFlush(FileStore.java:357)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.lambda$new$5(FileStore.java:212)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$$Lambda$203/0x00080064b440.run(Unknown
> Source)
> at
> org.apache.jackrabbit.oak.segment.file.SafeRunnable.run(SafeRunnable.java:67)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.3/Executors.java:515)
> at
> java.util.concurrent.FutureTask.runAndReset(java.base@11.0.3/FutureTask.java:305)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base@11.0.3/ScheduledThreadPoolExecutor.java:305)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.3/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.3/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.3/Thread.java:834)
> {noformat}
> Here is the test case that demonstrates the problem.
> [^test.patch]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8986) Segment flush thread can remanin in TIMED_WAITING state even when segment queue is empty
[
https://issues.apache.org/jira/browse/OAK-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071679#comment-17071679
]
Miroslav Smiljanic commented on OAK-8986:
-
Thanks for feedback [~tomek.rekawek].
Here is test and fix in the same file. I removed System.out.println() from
test, and added check that InterruptedException has been thrown.
[^test_and_proposed_patch.patch]
> Segment flush thread can remanin in TIMED_WAITING state even when segment
> queue is empty
>
>
> Key: OAK-8986
> URL: https://issues.apache.org/jira/browse/OAK-8986
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Affects Versions: 1.24.0, 1.26.0
>Reporter: Miroslav Smiljanic
>Priority: Major
> Attachments: proposed_patch.patch, test.patch
>
>
> If thread is in interrupted state, during execution of [SegmentWriteQueue.
> addToQueue
> |https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.26.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/queue/SegmentWriteQueue.java#L166]
> InterruptedException will be thrown and wrapped in IOException.
> Right befire calling queue.offer, element is added to segmentsByUUID map, and
> never removed.
> Normally that happens in thread that reads from
> [queue|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.26.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/queue/SegmentWriteQueue.java#L100],
> and that invokes [consume(SegmentWriteAction
> segment).|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.26.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/queue/SegmentWriteQueue.java#L117]
> Since item is not removed form the segmentsByUUID map,
> [flusher|http://[https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.26.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/queue/SegmentWriteQueue.java#L183]]
> thread will remain in TIMED_WAITING state.
> TarMK flush thread holds exclusivelly monitor needed by number of other
> threads, causing repository to be blocked.
> {noformat}
> "TarMK flush [/opt/aem/launcher/repository/segmentstore-composite-global]"
> #82 daemon prio=5 os_prio=0 cpu=83628.24ms elapsed=291420.48s
> tid=0x7fce902f3000 nid=0x1c2b in Object.wait() [0x7fce00aa5000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(java.base@11.0.3/Native Method)
> - waiting on
> at
> org.apache.jackrabbit.oak.segment.azure.queue.SegmentWriteQueue.flush(SegmentWriteQueue.java:183)
> - waiting to re-lock in wait() <0x0006b4911830> (a
> java.util.concurrent.ConcurrentHashMap)
> at
> org.apache.jackrabbit.oak.segment.azure.AzureSegmentArchiveWriter.flush(AzureSegmentArchiveWriter.java:187)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarWriter.flush(TarWriter.java:186)
> - locked <0x0006b4911960> (a java.lang.Object)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarFiles.flush(TarFiles.java:535)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.lambda$tryFlush$9(FileStore.java:359)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$$Lambda$232/0x00080067ac40.flush(Unknown
> Source)
> at
> org.apache.jackrabbit.oak.segment.file.TarRevisions.doFlush(TarRevisions.java:236)
> at
> org.apache.jackrabbit.oak.segment.file.TarRevisions.tryFlush(TarRevisions.java:216)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.tryFlush(FileStore.java:357)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.lambda$new$5(FileStore.java:212)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$$Lambda$203/0x00080064b440.run(Unknown
> Source)
> at
> org.apache.jackrabbit.oak.segment.file.SafeRunnable.run(SafeRunnable.java:67)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.3/Executors.java:515)
> at
> java.util.concurrent.FutureTask.runAndReset(java.base@11.0.3/FutureTask.java:305)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base@11.0.3/ScheduledThreadPoolExecutor.java:305)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.3/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.3/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.3/Thread.java:834)
> {noformat}
> Here is the test case that demonstrates the problem.
> [^test.patch]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8988) TarPersistence.lockRepostiory can indefinitely wait if another external process already running
Amit Jain created OAK-8988: -- Summary: TarPersistence.lockRepostiory can indefinitely wait if another external process already running Key: OAK-8988 URL: https://issues.apache.org/jira/browse/OAK-8988 Project: Jackrabbit Oak Issue Type: Bug Components: segment-tar Reporter: Amit Jain TarPersistence.lockRepostiory() [1] waits indefinitely when another segment tar process is already running and has acquired the lock already. The method should timeout if it fails to obtain a lock in a reasonable time (can be an internal value) or have alternative means ascertaining that another process already running e.g. by using mkdir(). 1 - [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/file/tar/TarPersistence.java#L92-L103|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/file/tar/TarPersistence.java#L92-L103] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8984) A big number of NOOP changes can result in a StackOverflow
[ https://issues.apache.org/jira/browse/OAK-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071594#comment-17071594 ] José Andrés Cordero Benítez commented on OAK-8984: -- I have added a possible fix for this issue. The test should be run using the JVM argument -Xss256k to reproduce the issue. After applying the fix, the StackOverflow exception should not appear anymore. The fix tries to avoid unneeded wraps of newModifiedDocumentNodeState when there are not enough changes to persist. > A big number of NOOP changes can result in a StackOverflow > -- > > Key: OAK-8984 > URL: https://issues.apache.org/jira/browse/OAK-8984 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: José Andrés Cordero Benítez >Priority: Major > Attachments: infinite-recursion-OAK-8984.patch > > > We have a case where a sync job sometimes produce a StackOverflow when a big > number of NOOP changes are executed. The problem could be related with the > wrapping of a new ModifiedDocumentNodeState object in every call. > If the number of changes don't reach the UpdateLimit value, if will continue > creating objects until it throws a StackOverflow error. > The problem only happens in very specific conditions, but with help of > [~mreutegg] we were able to reproduce in a test that artificially recreates > the situation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8984) A big number of NOOP changes can result in a StackOverflow
[ https://issues.apache.org/jira/browse/OAK-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] José Andrés Cordero Benítez updated OAK-8984: - Attachment: infinite-recursion-OAK-8984.patch > A big number of NOOP changes can result in a StackOverflow > -- > > Key: OAK-8984 > URL: https://issues.apache.org/jira/browse/OAK-8984 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: José Andrés Cordero Benítez >Priority: Major > Attachments: infinite-recursion-OAK-8984.patch > > > We have a case where a sync job sometimes produce a StackOverflow when a big > number of NOOP changes are executed. The problem could be related with the > wrapping of a new ModifiedDocumentNodeState object in every call. > If the number of changes don't reach the UpdateLimit value, if will continue > creating objects until it throws a StackOverflow error. > The problem only happens in very specific conditions, but with help of > [~mreutegg] we were able to reproduce in a test that artificially recreates > the situation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8986) Segment flush thread can remanin in TIMED_WAITING state even when segment queue is empty
[
https://issues.apache.org/jira/browse/OAK-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071582#comment-17071582
]
Tomek Rękawek commented on OAK-8986:
The patch LGTM. I think we should have it, together with the test.
> Segment flush thread can remanin in TIMED_WAITING state even when segment
> queue is empty
>
>
> Key: OAK-8986
> URL: https://issues.apache.org/jira/browse/OAK-8986
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Affects Versions: 1.24.0, 1.26.0
>Reporter: Miroslav Smiljanic
>Priority: Major
> Attachments: proposed_patch.patch, test.patch
>
>
> If thread is in interrupted state, during execution of [SegmentWriteQueue.
> addToQueue
> |https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.26.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/queue/SegmentWriteQueue.java#L166]
> InterruptedException will be thrown and wrapped in IOException.
> Right befire calling queue.offer, element is added to segmentsByUUID map, and
> never removed.
> Normally that happens in thread that reads from
> [queue|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.26.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/queue/SegmentWriteQueue.java#L100],
> and that invokes [consume(SegmentWriteAction
> segment).|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.26.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/queue/SegmentWriteQueue.java#L117]
> Since item is not removed form the segmentsByUUID map,
> [flusher|http://[https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.26.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/queue/SegmentWriteQueue.java#L183]]
> thread will remain in TIMED_WAITING state.
> TarMK flush thread holds exclusivelly monitor needed by number of other
> threads, causing repository to be blocked.
> {noformat}
> "TarMK flush [/opt/aem/launcher/repository/segmentstore-composite-global]"
> #82 daemon prio=5 os_prio=0 cpu=83628.24ms elapsed=291420.48s
> tid=0x7fce902f3000 nid=0x1c2b in Object.wait() [0x7fce00aa5000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(java.base@11.0.3/Native Method)
> - waiting on
> at
> org.apache.jackrabbit.oak.segment.azure.queue.SegmentWriteQueue.flush(SegmentWriteQueue.java:183)
> - waiting to re-lock in wait() <0x0006b4911830> (a
> java.util.concurrent.ConcurrentHashMap)
> at
> org.apache.jackrabbit.oak.segment.azure.AzureSegmentArchiveWriter.flush(AzureSegmentArchiveWriter.java:187)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarWriter.flush(TarWriter.java:186)
> - locked <0x0006b4911960> (a java.lang.Object)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarFiles.flush(TarFiles.java:535)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.lambda$tryFlush$9(FileStore.java:359)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$$Lambda$232/0x00080067ac40.flush(Unknown
> Source)
> at
> org.apache.jackrabbit.oak.segment.file.TarRevisions.doFlush(TarRevisions.java:236)
> at
> org.apache.jackrabbit.oak.segment.file.TarRevisions.tryFlush(TarRevisions.java:216)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.tryFlush(FileStore.java:357)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.lambda$new$5(FileStore.java:212)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore$$Lambda$203/0x00080064b440.run(Unknown
> Source)
> at
> org.apache.jackrabbit.oak.segment.file.SafeRunnable.run(SafeRunnable.java:67)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.3/Executors.java:515)
> at
> java.util.concurrent.FutureTask.runAndReset(java.base@11.0.3/FutureTask.java:305)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base@11.0.3/ScheduledThreadPoolExecutor.java:305)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.3/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.3/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.3/Thread.java:834)
> {noformat}
> Here is the test case that demonstrates the problem.
> [^test.patch]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8987) Build Jackrabbit Oak #2684 failed
[ https://issues.apache.org/jira/browse/OAK-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-8987. --- Resolution: Duplicate > Build Jackrabbit Oak #2684 failed > - > > Key: OAK-8987 > URL: https://issues.apache.org/jira/browse/OAK-8987 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2684 has failed. > First failed run: [Jackrabbit Oak > #2684|https://builds.apache.org/job/Jackrabbit%20Oak/2684/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2684/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OAK-8987) Build Jackrabbit Oak #2684 failed
[ https://issues.apache.org/jira/browse/OAK-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger closed OAK-8987. - > Build Jackrabbit Oak #2684 failed > - > > Key: OAK-8987 > URL: https://issues.apache.org/jira/browse/OAK-8987 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2684 has failed. > First failed run: [Jackrabbit Oak > #2684|https://builds.apache.org/job/Jackrabbit%20Oak/2684/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2684/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8972) EOL Oak 1.10
[ https://issues.apache.org/jira/browse/OAK-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8972: Description: Users of 1.10 should switch to the latest release 1.22 release (currently 1.22.1). What it'll mean in actual actions: - links will be removed from the download page - news will be posted on the homepage - [announce] will be sent to jr-user, jr-dev, oak-dev - branch and tags WILL stay there - issue label "candidate_oak_1_10" will be removed and (in a case-by-case basis) replaced with "candidate_1_8". See also http://jackrabbit.apache.org/oak/docs/roadmap.html was: Users of 1.10 should switch to the latest release 1.22 release (currently 1.21.1). What it'll mean in actual actions: - links will be removed from the download page - news will be posted on the homepage - [announce] will be sent to jr-user, jr-dev, oak-dev - branch and tags WILL stay there - issue label "candidate_oak_1_10" will be removed and (in a case-by-case basis) replaced with "candidate_1_8". See also http://jackrabbit.apache.org/oak/docs/roadmap.html > EOL Oak 1.10 > > > Key: OAK-8972 > URL: https://issues.apache.org/jira/browse/OAK-8972 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > Users of 1.10 should switch to the latest release 1.22 release (currently > 1.22.1). > What it'll mean in actual actions: > - links will be removed from the download page > - news will be posted on the homepage > - [announce] will be sent to jr-user, jr-dev, oak-dev > - branch and tags WILL stay there > - issue label "candidate_oak_1_10" will be removed and (in a case-by-case > basis) replaced with "candidate_1_8". > See also http://jackrabbit.apache.org/oak/docs/roadmap.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8987) Build Jackrabbit Oak #2684 failed
Hudson created OAK-8987: --- Summary: Build Jackrabbit Oak #2684 failed Key: OAK-8987 URL: https://issues.apache.org/jira/browse/OAK-8987 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #2684 has failed. First failed run: [Jackrabbit Oak #2684|https://builds.apache.org/job/Jackrabbit%20Oak/2684/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2684/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
