[jira] [Commented] (OAK-10509) Build Jackrabbit/jackrabbit-oak-trunk #1228 failed
[ https://issues.apache.org/jira/browse/OAK-10509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782333#comment-17782333 ] Hudson commented on OAK-10509: -- Previously failing build now is OK. Passed run: [Jackrabbit/jackrabbit-oak-trunk #1251|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1251/] [console log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1251/console] > Build Jackrabbit/jackrabbit-oak-trunk #1228 failed > -- > > Key: OAK-10509 > URL: https://issues.apache.org/jira/browse/OAK-10509 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #1228 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #1228|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1228/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1228/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10525) DefaultSyncContext.createValues : return value should be annotated with @NotNull
[
https://issues.apache.org/jira/browse/OAK-10525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-10525.
Fix Version/s: 1.60.0
Assignee: Angela Schreiber
Resolution: Fixed
> DefaultSyncContext.createValues : return value should be annotated with
> @NotNull
>
>
> Key: OAK-10525
> URL: https://issues.apache.org/jira/browse/OAK-10525
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Trivial
> Fix For: 1.60.0
>
>
> the return value of {{DefaultSyncContext.createValues}} is currently
> annotated with {{@Nullable}} but neither the returned array nor it's values
> are ever null and thus annotation {{@NotNull}} would be more appropriate IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10522) o.a.j.o.index.ReindexIT#reindexIgnoreMissingTikaDepThrow() fails with Java 21
[
https://issues.apache.org/jira/browse/OAK-10522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke reassigned OAK-10522:
Assignee: Julian Reschke
> o.a.j.o.index.ReindexIT#reindexIgnoreMissingTikaDepThrow() fails with Java 21
> --
>
> Key: OAK-10522
> URL: https://issues.apache.org/jira/browse/OAK-10522
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: run
>Reporter: Manfred Baedke
>Assignee: Julian Reschke
>Priority: Minor
>
> {code:java}
> [INFO] Running org.apache.jackrabbit.oak.index.ReindexIT
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.305
> s <<< FAILURE! - in org.apache.jackrabbit.oak.index.ReindexIT
> [ERROR]
> reindexIgnoreMissingTikaDepThrow(org.apache.jackrabbit.oak.index.ReindexIT)
> Time elapsed: 0.246 s <<< ERROR!
> java.lang.UnsupportedOperationException: The Security Manager is deprecated
> and will be removed in a future release
> at java.base/java.lang.System.setSecurityManager(System.java:429)
> at
> org.apache.jackrabbit.oak.index.ReindexIT.assertExits(ReindexIT.java:429)
> at
> org.apache.jackrabbit.oak.index.ReindexIT.reindexIgnoreMissingTikaDepThrow(ReindexIT.java:144)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10517) Consistently clean membership when switch between default and dynamic sync
[ https://issues.apache.org/jira/browse/OAK-10517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber resolved OAK-10517. Fix Version/s: 1.60.0 Resolution: Fixed > Consistently clean membership when switch between default and dynamic sync > --- > > Key: OAK-10517 > URL: https://issues.apache.org/jira/browse/OAK-10517 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Minor > Fix For: 1.60.0 > > > When dynamic sync is turned on for an existing oak repository any group > membership previously synchronized with the default sync context will be > clean up to comply with the new dynamic representation. However, this only > works for the first switch. If the configuration is switched back to default > and again to dynamic, the cleanup will be skipped. > cc: [~nscendoni] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10522) o.a.j.o.index.ReindexIT#reindexIgnoreMissingTikaDepThrow() fails with Java 21
[
https://issues.apache.org/jira/browse/OAK-10522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782206#comment-17782206
]
Julian Reschke commented on OAK-10522:
--
So it seems the whole circus is needed to avoid {{System.exit()}} to be called,
and to capture the exit status?
In which case it seems /much/ simpler just to modify the {{IndexCommand}} to
skip the exit call.
> o.a.j.o.index.ReindexIT#reindexIgnoreMissingTikaDepThrow() fails with Java 21
> --
>
> Key: OAK-10522
> URL: https://issues.apache.org/jira/browse/OAK-10522
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: run
>Reporter: Manfred Baedke
>Priority: Minor
>
> {code:java}
> [INFO] Running org.apache.jackrabbit.oak.index.ReindexIT
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.305
> s <<< FAILURE! - in org.apache.jackrabbit.oak.index.ReindexIT
> [ERROR]
> reindexIgnoreMissingTikaDepThrow(org.apache.jackrabbit.oak.index.ReindexIT)
> Time elapsed: 0.246 s <<< ERROR!
> java.lang.UnsupportedOperationException: The Security Manager is deprecated
> and will be removed in a future release
> at java.base/java.lang.System.setSecurityManager(System.java:429)
> at
> org.apache.jackrabbit.oak.index.ReindexIT.assertExits(ReindexIT.java:429)
> at
> org.apache.jackrabbit.oak.index.ReindexIT.reindexIgnoreMissingTikaDepThrow(ReindexIT.java:144)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10526) split doc can contain still referenced revisions without _sdMaxRevTime indicating so
[ https://issues.apache.org/jira/browse/OAK-10526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782201#comment-17782201 ] Stefan Egli edited comment on OAK-10526 at 11/2/23 3:49 PM: As a fix for this I'd suggest to set _sdMaxRevTime to the timestamp at the time of creating the split document. That would violate the meaning of that property - but it would ensure the split document gets deleted only a certain time (eg 24h) after any possible checkpoint or head revision existing at that time. Hence it would fix this. (renaming of this property would break backwards compatibility and seem to be an unnecessarily costly change) was (Author: egli): As a fix for this I'd suggest to set _sdMaxRevTime to the timestamp at the time of creating the split document. That would violate the meaning of that property - but it would ensure the split document gets deleted only a certain time (eg 24h) after any possible checkpoint of head revision existing at that time. Hence it would fix this. (renaming of this property would break backwards compatibility and seem to be an unnecessarily costly change) > split doc can contain still referenced revisions without _sdMaxRevTime > indicating so > > > Key: OAK-10526 > URL: https://issues.apache.org/jira/browse/OAK-10526 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Affects Versions: 1.58.0 >Reporter: Stefan Egli >Assignee: Stefan Egli >Priority: Major > > When a document grows too large, part of it is split into previous documents. > Those also called split documents are marked with _sdMaxRevTime reflecting > the newest (max) revision timestamp the document contains. GC later can > delete split documents where _sdMaxRevTime is older than 24h or any existing > checkpoint. This is based on the assumption that _sdMaxRevTime can be > compared to "older than 24h or any existing checkpoint" - while _sdMaxRevTime > only indicates the newest revision contained within. There can thus be a > situation when a split document contains a revision that is still referenced > by a current (not older than 24h) head revision or a checkpoint - but > _sdMaxRevTime is old enough for GC to remove that split doc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10526) split doc can contain still referenced revisions without _sdMaxRevTime indicating so
[ https://issues.apache.org/jira/browse/OAK-10526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782201#comment-17782201 ] Stefan Egli commented on OAK-10526: --- As a fix for this I'd suggest to set _sdMaxRevTime to the timestamp at the time of creating the split document. That would violate the meaning of that property - but it would ensure the split document gets deleted only a certain time (eg 24h) after any possible checkpoint of head revision existing at that time. Hence it would fix this. (renaming of this property would break backwards compatibility and seem to be an unnecessarily costly change) > split doc can contain still referenced revisions without _sdMaxRevTime > indicating so > > > Key: OAK-10526 > URL: https://issues.apache.org/jira/browse/OAK-10526 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Affects Versions: 1.58.0 >Reporter: Stefan Egli >Assignee: Stefan Egli >Priority: Major > > When a document grows too large, part of it is split into previous documents. > Those also called split documents are marked with _sdMaxRevTime reflecting > the newest (max) revision timestamp the document contains. GC later can > delete split documents where _sdMaxRevTime is older than 24h or any existing > checkpoint. This is based on the assumption that _sdMaxRevTime can be > compared to "older than 24h or any existing checkpoint" - while _sdMaxRevTime > only indicates the newest revision contained within. There can thus be a > situation when a split document contains a revision that is still referenced > by a current (not older than 24h) head revision or a checkpoint - but > _sdMaxRevTime is old enough for GC to remove that split doc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-9758) Oak run indexing silently broken without tika.jar (text rendition)
[ https://issues.apache.org/jira/browse/OAK-9758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-9758: Fix Version/s: 1.44.0 > Oak run indexing silently broken without tika.jar (text rendition) > -- > > Key: OAK-9758 > URL: https://issues.apache.org/jira/browse/OAK-9758 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Yu-An Lin >Assignee: Thomas Mueller >Priority: Major > Labels: indexing > Fix For: 1.44.0 > > > If "java oak-run.jar createIndex ..." is used without the tika.jar or its > dependencies, then text extraction is not made (for those binaries where the > parser is missing in the classpath). This is silent: there is no warning or > exception. > It would be better if oak-run createIndex prevents indexing if tika / its > dependencies are missing. An override is needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-9758) Oak run indexing silently broken without tika.jar (text rendition)
[ https://issues.apache.org/jira/browse/OAK-9758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-9758. - Resolution: Fixed trunk: (1.44.0) [db6d66fbcf|https://github.com/apache/jackrabbit-oak/commit/db6d66fbcf1098d26427bcb7eb41cfaeb99e4d42] [09c3542377|https://github.com/apache/jackrabbit-oak/commit/09c354237732e457868f81620f314d780c4e32cf] [0021d83dd2|https://github.com/apache/jackrabbit-oak/commit/0021d83dd296728d883d52dc5881d63288d647b7] [5f4fc13e40|https://github.com/apache/jackrabbit-oak/commit/5f4fc13e407b622a804e4c631e59caf32544] > Oak run indexing silently broken without tika.jar (text rendition) > -- > > Key: OAK-9758 > URL: https://issues.apache.org/jira/browse/OAK-9758 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Yu-An Lin >Assignee: Thomas Mueller >Priority: Major > Labels: indexing > > If "java oak-run.jar createIndex ..." is used without the tika.jar or its > dependencies, then text extraction is not made (for those binaries where the > parser is missing in the classpath). This is silent: there is no warning or > exception. > It would be better if oak-run createIndex prevents indexing if tika / its > dependencies are missing. An override is needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10523) Basic SNS support returns invalid node names
[
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-10523:
-
Attachment: OAK-10523.diffs
> Basic SNS support returns invalid node names
>
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-10523.diffs
>
>
> When encountering names using index notation in storage, oak-jcr treats the
> index suffix as part of the name. This causes issues with other components
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10523) Basic SNS support returns invalid node names
[
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782163#comment-17782163
]
Julian Reschke commented on OAK-10523:
--
Did some experimenting in [^OAK-10523.diffs] - but as expected, just "fixing"
getName() and getIndex() would not be sufficient.
> Basic SNS support returns invalid node names
>
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-10523.diffs
>
>
> When encountering names using index notation in storage, oak-jcr treats the
> index suffix as part of the name. This causes issues with other components
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10527) Improve readability of the explain query output
Thomas Mueller created OAK-10527:
Summary: Improve readability of the explain query output
Key: OAK-10527
URL: https://issues.apache.org/jira/browse/OAK-10527
Project: Jackrabbit Oak
Issue Type: Improvement
Components: query
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Currently the output "explain query" of Oak (the query plan) is hard to
interpret.
A more human-readable output would be better. Example:
Old:
{noformat}
[nt:base] as [nt:base] /*
lucene:slingResourceResolver-1(/oak:index/slingResourceResolver-1)
sling:vanityPath:[* TO *] sync:(sling:vanityPath is not null) where
([nt:base].[sling:vanityPath] is not null) and
(first([nt:base].[sling:vanityPath]) > '') */
{noformat}
New:
{noformat}
[nt:base] as [nt:base] /* lucene:slingResourceResolver-1
indexDefinition: /oak:index/slingResourceResolver-1
estimatedEntries: 46
luceneQuery: sling:vanityPath:[* TO *]
synchronousPropertyCondition: sling:vanityPath is not null
*/
{noformat}
Also, the formatting of the logged query statement should be improved: instead
of one single line with the whole statement, the statement should contain line
breaks before the important keywords. Example:
Old:
{noformat}
Parsing JCR-SQL2 statement: explain SELECT [sling:vanityPath],
[sling:redirect], [sling:redirectStatus] FROM [nt:base] WHERE NOT
isdescendantnode('/jcr:system') AND [sling:vanityPath] IS NOT NULL AND
FIRST([sling:vanityPath]) > '' ORDER BY FIRST([sling:vanityPath])
{noformat}
New:
{noformat}
Parsing JCR-SQL2 statement: explain SELECT [sling:vanityPath],
[sling:redirect], [sling:redirectStatus]
FROM [nt:base]
WHERE NOT isdescendantnode('/jcr:system')
AND [sling:vanityPath] IS NOT NULL
AND FIRST([sling:vanityPath]) > ''
ORDER BY FIRST([sling:vanityPath])
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10451) UserPrincipalProvider may cause many conflicts when under load
[ https://issues.apache.org/jira/browse/OAK-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-10451: --- Fix Version/s: 1.60.0 > UserPrincipalProvider may cause many conflicts when under load > -- > > Key: OAK-10451 > URL: https://issues.apache.org/jira/browse/OAK-10451 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, security >Reporter: Nicola Scendoni >Assignee: Nicola Scendoni >Priority: Major > Fix For: 1.60.0 > > Attachments: LoginTest_20231010_172626_with_patch.csv, > LoginTest_20231010_173013_without_patch.csv > > > UserPrincipalProvider can be configured to periodically cache group > membership by writing group principals on a rep:cache node. This will result > in thundering herd problem when the system is under load and the expiration > time for the cache is reached. Incoming requests that authenticate > concurrently will all try to refresh the cache and cause conflicts because > each request tries to set a new expiration time that is slightly different > from the others. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9250) 3rd level segment cache: perform direct memory allocation based on the value of the system property
[ https://issues.apache.org/jira/browse/OAK-9250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782072#comment-17782072 ] Julian Reschke commented on OAK-9250: - trunk: (1.36) [7385885d88|https://github.com/apache/jackrabbit-oak/commit/7385885d884f31134b589a9928ada092faab44ef] > 3rd level segment cache: perform direct memory allocation based on the value > of the system property > --- > > Key: OAK-9250 > URL: https://issues.apache.org/jira/browse/OAK-9250 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Miroslav Smiljanic >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.36.0 > > Attachments: OAK-9250.patch, > OAK-9250_increase_memory_for_tests.patch, OAK-9250_test_changed.patch > > > Currently redis and disk cache are doing direct memory allocation when > reading segments. It should be done based on the value of the system > property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
