[jira] [Commented] (OAK-9041) Build Jackrabbit Oak #2732 failed
[ https://issues.apache.org/jira/browse/OAK-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102910#comment-17102910 ] Hudson commented on OAK-9041: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2746|https://builds.apache.org/job/Jackrabbit%20Oak/2746/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2746/console] > Build Jackrabbit Oak #2732 failed > - > > Key: OAK-9041 > URL: https://issues.apache.org/jira/browse/OAK-9041 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2732 has failed. > First failed run: [Jackrabbit Oak > #2732|https://builds.apache.org/job/Jackrabbit%20Oak/2732/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2732/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-9053) Reindexing Strategy for ES indexes
[ https://issues.apache.org/jira/browse/OAK-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102640#comment-17102640 ] Amrit Verma commented on OAK-9053: -- Pull request implementing the first approach - [https://github.com/oak-indexing/jackrabbit-oak/pull/157] > Reindexing Strategy for ES indexes > -- > > Key: OAK-9053 > URL: https://issues.apache.org/jira/browse/OAK-9053 > Project: Jackrabbit Oak > Issue Type: Task > Components: indexing >Reporter: Amrit Verma >Priority: Major > Fix For: 1.28.0 > > > There are two approaches for handling re-indexing of ES indexes. > The simpler strategy would be to: > * create the new index > * move writes and reads to the new index > * delete old index > A more sophisticated strategy could: > * create the new index > * move writes to the new index > * reads will continue to use the old index until the new one catches up > * when the new one is in sync, move reads to the new index & delete the old > one > Both strategies can be implemented using Aliases in Elasticsearch to avoid > race conditions. To implement the second solution we need something that > tells us when the new index has caught up with the initial load. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-9041) Build Jackrabbit Oak #2732 failed
[ https://issues.apache.org/jira/browse/OAK-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102584#comment-17102584 ] Hudson commented on OAK-9041: - Build is still failing. Failed run: [Jackrabbit Oak #2745|https://builds.apache.org/job/Jackrabbit%20Oak/2745/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2745/console] > Build Jackrabbit Oak #2732 failed > - > > Key: OAK-9041 > URL: https://issues.apache.org/jira/browse/OAK-9041 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2732 has failed. > First failed run: [Jackrabbit Oak > #2732|https://builds.apache.org/job/Jackrabbit%20Oak/2732/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2732/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-9056) Setup job scanning for features marked for removal
Marcel Reutegger created OAK-9056: - Summary: Setup job scanning for features marked for removal Key: OAK-9056 URL: https://issues.apache.org/jira/browse/OAK-9056 Project: Jackrabbit Oak Issue Type: Task Components: continuous integration Reporter: Marcel Reutegger In order to detect incompatible JDK changes early, setup a Jenkins job that scans for upcoming removals using jdeprscan. https://docs.oracle.com/en/java/javase/11/tools/jdeprscan.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-9041) Build Jackrabbit Oak #2732 failed
[ https://issues.apache.org/jira/browse/OAK-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102479#comment-17102479 ] Hudson commented on OAK-9041: - Build is still failing. Failed run: [Jackrabbit Oak #2744|https://builds.apache.org/job/Jackrabbit%20Oak/2744/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2744/console] > Build Jackrabbit Oak #2732 failed > - > > Key: OAK-9041 > URL: https://issues.apache.org/jira/browse/OAK-9041 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2732 has failed. > First failed run: [Jackrabbit Oak > #2732|https://builds.apache.org/job/Jackrabbit%20Oak/2732/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2732/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-9055) Check for existence before staging files in UploadStagingCache
Amit Jain created OAK-9055: -- Summary: Check for existence before staging files in UploadStagingCache Key: OAK-9055 URL: https://issues.apache.org/jira/browse/OAK-9055 Project: Jackrabbit Oak Issue Type: Bug Components: blob-plugins Reporter: Amit Jain Assignee: Amit Jain Fix For: 1.26.0 Whenever duplicate multiple blobs are uploaded, there might be a race condition beetween the deletion cycle and the upload. Investigate the race condition and ignore errors in case the file is not present. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-9054) Improved blob listing performance for the Azure Segment Store
[ https://issues.apache.org/jira/browse/OAK-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-9054. -- Resolution: Fixed > Improved blob listing performance for the Azure Segment Store > - > > Key: OAK-9054 > URL: https://issues.apache.org/jira/browse/OAK-9054 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure >Affects Versions: 1.26.0 >Reporter: Rahul Bhardwaj >Assignee: Andrei Dulceanu >Priority: Critical > Fix For: 1.28.0 > > Attachments: OAK-9054.patch > > > Fix of OAK-8930 introduced a performance impact of a factor of 10x due to > trying to get blobs regardless, it succeeded the last time or not. > > [https://github.com/apache/jackrabbit-oak/commit/ba256b6d42b501fa2d50666fba7312ed7fe58ff6#diff-b7994e80d60e37866246062c059b5243R79-R98] > > /cc [~tomek.rekawek] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-9054) Improved blob listing performance for the Azure Segment Store
[ https://issues.apache.org/jira/browse/OAK-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102425#comment-17102425 ] Andrei Dulceanu commented on OAK-9054: -- Fixed in trunk at r1877506. Thanks for the contribution, [~bhardwajrahul20]! > Improved blob listing performance for the Azure Segment Store > - > > Key: OAK-9054 > URL: https://issues.apache.org/jira/browse/OAK-9054 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure >Affects Versions: 1.26.0 >Reporter: Rahul Bhardwaj >Assignee: Andrei Dulceanu >Priority: Critical > Fix For: 1.28.0 > > Attachments: OAK-9054.patch > > > Fix of OAK-8930 introduced a performance impact of a factor of 10x due to > trying to get blobs regardless, it succeeded the last time or not. > > [https://github.com/apache/jackrabbit-oak/commit/ba256b6d42b501fa2d50666fba7312ed7fe58ff6#diff-b7994e80d60e37866246062c059b5243R79-R98] > > /cc [~tomek.rekawek] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-9054) Improve blob listing performance for the Azure Segment Store
[ https://issues.apache.org/jira/browse/OAK-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-9054: - Summary: Improve blob listing performance for the Azure Segment Store (was: Fix of OAK-8930 introduced a performance impact leading to increase in time to get blobs from Azure) > Improve blob listing performance for the Azure Segment Store > > > Key: OAK-9054 > URL: https://issues.apache.org/jira/browse/OAK-9054 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure >Affects Versions: 1.26.0 >Reporter: Rahul Bhardwaj >Assignee: Andrei Dulceanu >Priority: Critical > Fix For: 1.28.0 > > Attachments: OAK-9054.patch > > > Fix of OAK-8930 introduced a performance impact of a factor of 10x due to > trying to get blobs regardless, it succeeded the last time or not. > > [https://github.com/apache/jackrabbit-oak/commit/ba256b6d42b501fa2d50666fba7312ed7fe58ff6#diff-b7994e80d60e37866246062c059b5243R79-R98] > > /cc [~tomek.rekawek] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-9054) Improved blob listing performance for the Azure Segment Store
[ https://issues.apache.org/jira/browse/OAK-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-9054: - Summary: Improved blob listing performance for the Azure Segment Store (was: Improve blob listing performance for the Azure Segment Store) > Improved blob listing performance for the Azure Segment Store > - > > Key: OAK-9054 > URL: https://issues.apache.org/jira/browse/OAK-9054 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure >Affects Versions: 1.26.0 >Reporter: Rahul Bhardwaj >Assignee: Andrei Dulceanu >Priority: Critical > Fix For: 1.28.0 > > Attachments: OAK-9054.patch > > > Fix of OAK-8930 introduced a performance impact of a factor of 10x due to > trying to get blobs regardless, it succeeded the last time or not. > > [https://github.com/apache/jackrabbit-oak/commit/ba256b6d42b501fa2d50666fba7312ed7fe58ff6#diff-b7994e80d60e37866246062c059b5243R79-R98] > > /cc [~tomek.rekawek] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098861#comment-17098861
]
Julian Reschke edited comment on OAK-9024 at 5/8/20, 9:46 AM:
--
[~baedke] I posted my comment, because I prefer to understand an issue before
it is fixed. I didn't get the impression that it was clear where the slf4j.impl
import came from, nor why (exactly) embedding slf4j-log4j12 seems to fix it.
Assuming that {{org.slf4j.impl.StaticLoggerBinder}} is never actually called,
embedding slf4j-log4j12 would be fine. However, I would then rather chose to
include slf4j-nop, which has no dependencies other than slf4j.api. In case the
class {{org.slf4j.impl.StaticLoggerBinder}} is never loaded, excluding
org.slf4j.impl from the imports would also be ok.
If {{org.slf4j.impl.StaticLoggerBinder}} is called, I think the situation is
more problematic. The Oak setups I know of (all Sling based) use an OSGi
wrapped logback-classic (org.apache.sling.commons.log), which exports
{{org.slf4j.impl}}. For this scenario, I think importing it would be the best
solution. Embedding any other binding may well lead to class loading issues in
OSGi.
So I think embedding slf4j-log4j12 may not solve the problem, or may only solve
it superficially. I would actually lean towards importing {{org.slf4j.impl}},
maybe adjusting the version range (if necessary) and linking back to this issue
from the POM to document this oddity.
was (Author: jsedding):
[~baedke] I posted my comment, because I prefer to understand an issue before
it is fixed. I didn't get the impression that it was clear where the slf4j.impl
impoprt came from, nor why (exactly) embedding slf4j-log4j12 seems to fix it.
Assuming that {{org.slf4j.impl.StaticLoggerBinder}} is never actually called,
embedding slf4j-log4j12 would be fine. However, I would then rather chose to
include slf4j-nop, which has no dependencies other than slf4j.api. In case the
class {{org.slf4j.impl.StaticLoggerBinder}} is never loaded, excluding
org.slf4j.impl from the imports would also be ok.
If {{org.slf4j.impl.StaticLoggerBinder}} is called, I think the situation is
more problematic. The Oak setups I know of (all Sling based) use an OSGi
wrapped logback-classic (org.apache.sling.commons.log), which exports
{{org.slf4j.impl}}. For this scenario, I think importing it would be the best
solution. Embedding any other binding may well lead to class loading issues in
OSGi.
So I think embedding slf4j-log4j12 may not solve the problem, or may only solve
it superficially. I would actually lean towards importing {{org.slf4j.impl}},
maybe adjusting the version range (if necessary) and linking back to this issue
from the POM to document this oddity.
> oak-solr-osgi imports org.slf4j.impl
>
>
> Key: OAK-9024
> URL: https://issues.apache.org/jira/browse/OAK-9024
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Minor
> Fix For: 1.28.0
>
> Attachments: OAK-9024.patch
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OAK-9054) Fix of OAK-8930 introduced a performance impact leading to increase in time to get blobs from Azure
[ https://issues.apache.org/jira/browse/OAK-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-9054: Assignee: Andrei Dulceanu > Fix of OAK-8930 introduced a performance impact leading to increase in time > to get blobs from Azure > --- > > Key: OAK-9054 > URL: https://issues.apache.org/jira/browse/OAK-9054 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure >Affects Versions: 1.26.0 >Reporter: Rahul Bhardwaj >Assignee: Andrei Dulceanu >Priority: Critical > Fix For: 1.28.0 > > Attachments: OAK-9054.patch > > > Fix of OAK-8930 introduced a performance impact of a factor of 10x due to > trying to get blobs regardless, it succeeded the last time or not. > > [https://github.com/apache/jackrabbit-oak/commit/ba256b6d42b501fa2d50666fba7312ed7fe58ff6#diff-b7994e80d60e37866246062c059b5243R79-R98] > > /cc [~tomek.rekawek] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096360#comment-17096360
]
Julian Reschke edited comment on OAK-9024 at 5/8/20, 9:45 AM:
--
bndtools may have the answer, in particular the [xref
command|https://bnd.bndtools.org/commands/xref.html]
The following is an excerpt from its output, indicating which classes use
(i.e. import on a java level) classes from {{org.slf4j.impl}}.
{noformat}
$ bnd xref -cf target/oak-solr-osgi-1.27-SNAPSHOT.jar
...
org.slf4j.impl.StaticLoggerBinder < org.apache.solr.logging.LogWatcher
org.apache.solr.servlet.StartupLoggingUtils
...
{noformat}
Removing these two classes from the {{Embed-Dependency}} instruction should
remove the import for {{org.slf4j.impl}}. However, it would still be required
to analyze where the Oak code (transitively) depends on these classes and
examine if it can be safely used without them. If removing these classes is not
an option, it may still be safe to exclude the import for {{org.slf4j.impl}}
explicitly, iff no code path is used, where the {{StaticLoggerBinder}} is used.
If it _is_ used, however, then it we really need {{StaticLoggerBinder}} on the
class path (or provide an upstream fix for Solr).
was (Author: jsedding):
bndtools may have the answer, in particular the [xref
command|https://bnd.bndtools.org/commands/xref.html]
The following is an excerpt from its output, indicating which classes use
(i.e. import on a java level) classes from {{org.slf4j.impl}}.
{noformat}
$ bnd xref -cf target/oak-solr-osgi-1.27-SNAPSHOT.jar
...
org.slf4j.impl.StaticLoggerBinder < org.apache.solr.logging.LogWatcher
org.apache.solr.servlet.StartupLoggingUtils
...
{noformat}
Removing these two classes from the {{Embed-Dependency}} instruction should
remove the import for {{org.slf4j.impl}}. However, it woudl still be required
to analyze where the Oak code (transitively) depends on these classes and
examine if it can be safely used without them. If removing these classes is not
an option, it may still be safe to exclude the import for {{org.slf4j.impl}}
explicitly, iff no code path is used, where the {{StaticLoggerBinder}} is used.
If it _is_ used, however, then it we really need {{StaticLoggerBinder}} on the
class path (or provide an upstream fix for Solr).
> oak-solr-osgi imports org.slf4j.impl
>
>
> Key: OAK-9024
> URL: https://issues.apache.org/jira/browse/OAK-9024
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Minor
> Fix For: 1.28.0
>
> Attachments: OAK-9024.patch
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-9054) Fix of OAK-8930 introduced a performance impact leading to increase in time to get blobs from Azure
[ https://issues.apache.org/jira/browse/OAK-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-9054: - Description: Fix of OAK-8930 introduced a performance impact of a factor of 10x due to trying to get blobs regardless, it succeeded the last time or not. [https://github.com/apache/jackrabbit-oak/commit/ba256b6d42b501fa2d50666fba7312ed7fe58ff6#diff-b7994e80d60e37866246062c059b5243R79-R98] /cc [~tomek.rekawek] was: Fix of OAK-8930 introduced a performance impact of a factor of 10x due to trying to get blobs regardless, it succeeded the last time or not. [https://github.com/apache/jackrabbit-oak/commit/ba256b6d42b501fa2d50666fba7312ed7fe58ff6#diff-b7994e80d60e37866246062c059b5243R79-R98] > Fix of OAK-8930 introduced a performance impact leading to increase in time > to get blobs from Azure > --- > > Key: OAK-9054 > URL: https://issues.apache.org/jira/browse/OAK-9054 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure >Affects Versions: 1.26.0 >Reporter: Rahul Bhardwaj >Priority: Critical > Fix For: 1.28.0 > > Attachments: OAK-9054.patch > > > Fix of OAK-8930 introduced a performance impact of a factor of 10x due to > trying to get blobs regardless, it succeeded the last time or not. > > [https://github.com/apache/jackrabbit-oak/commit/ba256b6d42b501fa2d50666fba7312ed7fe58ff6#diff-b7994e80d60e37866246062c059b5243R79-R98] > > /cc [~tomek.rekawek] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-9054) Fix of OAK-8930 introduced a performance impact leading to increase in time to get blobs from Azure
[ https://issues.apache.org/jira/browse/OAK-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Bhardwaj updated OAK-9054: Attachment: OAK-9054.patch > Fix of OAK-8930 introduced a performance impact leading to increase in time > to get blobs from Azure > --- > > Key: OAK-9054 > URL: https://issues.apache.org/jira/browse/OAK-9054 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure >Affects Versions: 1.26.0 >Reporter: Rahul Bhardwaj >Priority: Critical > Fix For: 1.28.0 > > Attachments: OAK-9054.patch > > > Fix of OAK-8930 introduced a performance impact of a factor of 10x due to > trying to get blobs regardless, it succeeded the last time or not. > [https://github.com/apache/jackrabbit-oak/commit/ba256b6d42b501fa2d50666fba7312ed7fe58ff6#diff-b7994e80d60e37866246062c059b5243R79-R98] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-9041) Build Jackrabbit Oak #2732 failed
[ https://issues.apache.org/jira/browse/OAK-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102392#comment-17102392 ] Hudson commented on OAK-9041: - Build is still failing. Failed run: [Jackrabbit Oak #2743|https://builds.apache.org/job/Jackrabbit%20Oak/2743/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2743/console] > Build Jackrabbit Oak #2732 failed > - > > Key: OAK-9041 > URL: https://issues.apache.org/jira/browse/OAK-9041 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2732 has failed. > First failed run: [Jackrabbit Oak > #2732|https://builds.apache.org/job/Jackrabbit%20Oak/2732/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2732/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-9054) Fix of OAK-8930 introduced a performance impact leading to increase in time to get blobs from Azure
Rahul Bhardwaj created OAK-9054: --- Summary: Fix of OAK-8930 introduced a performance impact leading to increase in time to get blobs from Azure Key: OAK-9054 URL: https://issues.apache.org/jira/browse/OAK-9054 Project: Jackrabbit Oak Issue Type: Bug Components: segment-azure Affects Versions: 1.26.0 Reporter: Rahul Bhardwaj Fix For: 1.28.0 Fix of OAK-8930 introduced a performance impact of a factor of 10x due to trying to get blobs regardless, it succeeded the last time or not. [https://github.com/apache/jackrabbit-oak/commit/ba256b6d42b501fa2d50666fba7312ed7fe58ff6#diff-b7994e80d60e37866246062c059b5243R79-R98] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8890) LDAP login may fail if a server or intermediate silently drops connections
[ https://issues.apache.org/jira/browse/OAK-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17100775#comment-17100775 ] Julian Reschke edited comment on OAK-8890 at 5/8/20, 8:59 AM: -- trunk: [r1877503|http://svn.apache.org/r1877503] [r1877435|http://svn.apache.org/r1877435] was (Author: baedke): Done: http://svn.apache.org/viewvc?view=revision=1877435 > LDAP login may fail if a server or intermediate silently drops connections > -- > > Key: OAK-8890 > URL: https://issues.apache.org/jira/browse/OAK-8890 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Fix For: 1.28.0 > > Attachments: OAK-8890.patch > > > This has been seen on production systems with Oak 1.10.2, where a firewall > was configured to drop idle connections after a timeout without sending an > RST (for security reasons). When this happens, the connection pool used by > the LdapPrincipalProvider will still consider these connections healthy. > Eventually such a connection will be used for an actual LDAP BIND/SEARCH, > which will simply timeout. > The connection pool is an instance of > org.apache.commons.pool.impl.GenericObjectPool, which has configuration > options to deal with the scenario (namely running an eviction task which will > properly close idle connections after a timeout which is shorter than the > timeout interval used by the firewall) . > The creation of the connection pool used is hard coded and most of the > configuration options are not available. > I propose to change that. I'll supply a patch soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-9052) Reindexing using --doc-traversal-mode may need a lot of memory
[ https://issues.apache.org/jira/browse/OAK-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-9052: Fix Version/s: 1.28.0 > Reindexing using --doc-traversal-mode may need a lot of memory > -- > > Key: OAK-9052 > URL: https://issues.apache.org/jira/browse/OAK-9052 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing, mongomk >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.28.0 > > Attachments: fileSizeOverTime.png > > > Indexing using oak-run and --doc-traversal-mode uses the FlatFileStore. For > aggregation, there is a limit on memory usage, by default around 100 MB. > Depending on the content structure, this limit can be exceeded. > It would be good to find a way to avoid a memory limit, for example using a > temporary storage (a file, or a persistent key/value store). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-9052) Reindexing using --doc-traversal-mode may need a lot of memory
[ https://issues.apache.org/jira/browse/OAK-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102318#comment-17102318 ] Thomas Mueller commented on OAK-9052: - http://svn.apache.org/r1877497 > Reindexing using --doc-traversal-mode may need a lot of memory > -- > > Key: OAK-9052 > URL: https://issues.apache.org/jira/browse/OAK-9052 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing, mongomk >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Attachments: fileSizeOverTime.png > > > Indexing using oak-run and --doc-traversal-mode uses the FlatFileStore. For > aggregation, there is a limit on memory usage, by default around 100 MB. > Depending on the content structure, this limit can be exceeded. > It would be good to find a way to avoid a memory limit, for example using a > temporary storage (a file, or a persistent key/value store). -- This message was sent by Atlassian Jira (v8.3.4#803005)
