[jira] [Assigned] (OAK-10093) Oak Blob Store support for SSE-C for AWS
[ https://issues.apache.org/jira/browse/OAK-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rishabh Daim reassigned OAK-10093: -- Assignee: Rishabh Daim > Oak Blob Store support for SSE-C for AWS > > > Key: OAK-10093 > URL: https://issues.apache.org/jira/browse/OAK-10093 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Rishabh Kumar >Assignee: Rishabh Daim >Priority: Major > > We need to provide the support for Customer Managed keys for Oak Blob Store > for AWS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10264) Build Jackrabbit/jackrabbit-oak-trunk #965 failed
[ https://issues.apache.org/jira/browse/OAK-10264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728297#comment-17728297 ] Hudson commented on OAK-10264: -- Build is still failing. Failed run: [Jackrabbit/jackrabbit-oak-trunk #971|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/971/] [console log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/971/console] > Build Jackrabbit/jackrabbit-oak-trunk #965 failed > - > > Key: OAK-10264 > URL: https://issues.apache.org/jira/browse/OAK-10264 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #965 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #965|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/965/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/965/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10265) Oak-run offline reindex - async lane revert not taking place for stored index def after index import
[ https://issues.apache.org/jira/browse/OAK-10265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728298#comment-17728298 ] Nitin Gupta commented on OAK-10265: --- trunk - https://github.com/apache/jackrabbit-oak/commit/846fcb4e89055504cb5b340462b1a961bfb0019d > Oak-run offline reindex - async lane revert not taking place for stored index > def after index import > > > Key: OAK-10265 > URL: https://issues.apache.org/jira/browse/OAK-10265 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > During offline reindex using oak-run, > the index import phase first changes the async property to temp-async and > keeps the original value in async-previous property. > This is reverted when the import is done. However it appears that the revert > doesn't happen for the stored index definition and leaves that at > async = temp-async > async-previous = [async, nrt] > We should probably add refresh=true to avoid this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10265) Oak-run offline reindex - async lane revert not taking place for stored index def after index import
[ https://issues.apache.org/jira/browse/OAK-10265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10265. --- Fix Version/s: 1.54.0 Resolution: Fixed > Oak-run offline reindex - async lane revert not taking place for stored index > def after index import > > > Key: OAK-10265 > URL: https://issues.apache.org/jira/browse/OAK-10265 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.54.0 > > > During offline reindex using oak-run, > the index import phase first changes the async property to temp-async and > keeps the original value in async-previous property. > This is reverted when the import is done. However it appears that the revert > doesn't happen for the stored index definition and leaves that at > async = temp-async > async-previous = [async, nrt] > We should probably add refresh=true to avoid this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10266) ClientIpFilterTest fails for localhost
Marcel Reutegger created OAK-10266: -- Summary: ClientIpFilterTest fails for localhost Key: OAK-10266 URL: https://issues.apache.org/jira/browse/OAK-10266 Project: Jackrabbit Oak Issue Type: Bug Components: segment-tar Reporter: Marcel Reutegger ClientIpFilterTest fails on my machine for filters=localhost. The JVM returns an IP v6 address, which does not match the expected 127.0.0.1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10266) ClientIpFilterTest fails for localhost
[ https://issues.apache.org/jira/browse/OAK-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned OAK-10266: -- Assignee: Marcel Reutegger > ClientIpFilterTest fails for localhost > -- > > Key: OAK-10266 > URL: https://issues.apache.org/jira/browse/OAK-10266 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > ClientIpFilterTest fails on my machine for filters=localhost. > The JVM returns an IP v6 address, which does not match the expected 127.0.0.1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10266) ClientIpFilterTest fails for localhost
[ https://issues.apache.org/jira/browse/OAK-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned OAK-10266: -- Assignee: (was: Marcel Reutegger) > ClientIpFilterTest fails for localhost > -- > > Key: OAK-10266 > URL: https://issues.apache.org/jira/browse/OAK-10266 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Reporter: Marcel Reutegger >Priority: Minor > > ClientIpFilterTest fails on my machine for filters=localhost. > The JVM returns an IP v6 address, which does not match the expected 127.0.0.1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10267) oak-search-elastic: index should be more lenient when a field cannot be converted to the mapped type
Fabrizio Fortino created OAK-10267: -- Summary: oak-search-elastic: index should be more lenient when a field cannot be converted to the mapped type Key: OAK-10267 URL: https://issues.apache.org/jira/browse/OAK-10267 Project: Jackrabbit Oak Issue Type: Improvement Components: elastic-search, indexing Reporter: Fabrizio Fortino Assignee: Fabrizio Fortino -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10147) Many move operations may consume a lot of memory
[ https://issues.apache.org/jira/browse/OAK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728395#comment-17728395 ] Marcel Reutegger commented on OAK-10147: During a discussions with [~stefanegli], [~daim], [~corderob] and [~ankitaagar] the suggestions was made to try to get rid of {{Move.destParent}} to reduce memory usage. With only the source and destination path left in a Move, memory usage will be drastically lower even when a MutableTree still references many pending Move operations. The PR https://github.com/apache/jackrabbit-oak/pull/962 is an implementation of this idea. The current implementation is retained and can be enabled again either with a system property {{oak.classicMove}} or feature toggle {{OAK-10147}}. I'd still like to spend a bit more time and add tests. I already discovered an issue in the current implementation (ClassicMoveTest#moveMoved()), which works fine on the new implementation. Either disable feature flag in ClassicMoveTest to run on the new implementation or run RootTest in oak-it, which has the same test. > Many move operations may consume a lot of memory > > > Key: OAK-10147 > URL: https://issues.apache.org/jira/browse/OAK-10147 > Project: Jackrabbit Oak > Issue Type: Task > Components: core >Reporter: Julian Reschke >Assignee: Marcel Reutegger >Priority: Major > > We have encountered an issue where a component did a huge number of move > operations in transient space, and oak-core's "MutableRoot" class consumed > ~800 MB for ca 3000 move operations. This seems to be a lot. > We should: > 1. Write a test / benchmark that reproduces the issue > 2. Check whether it's specific to a certain store implemention > 3. See whether the memory footprint can be reduced -- This message was sent by Atlassian Jira (v8.20.10#820010)