[jira] [Commented] (OAK-10411) Build Jackrabbit/jackrabbit-oak-1.22 #70 failed
[ https://issues.apache.org/jira/browse/OAK-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773452#comment-17773452 ] Hudson commented on OAK-10411: -- Previously failing build now is OK. Passed run: [Jackrabbit/jackrabbit-oak-1.22 #94|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-1.22/94/] [console log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-1.22/94/console] > Build Jackrabbit/jackrabbit-oak-1.22 #70 failed > --- > > Key: OAK-10411 > URL: https://issues.apache.org/jira/browse/OAK-10411 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit/jackrabbit-oak-1.22 #70 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-1.22 > #70|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-1.22/70/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-1.22/70/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10476) Need example Jackrabbit Oak Spring-Boot OSGI project with RDB storage
Wallace Howery created OAK-10476:
Summary: Need example Jackrabbit Oak Spring-Boot OSGI project with
RDB storage
Key: OAK-10476
URL: https://issues.apache.org/jira/browse/OAK-10476
Project: Jackrabbit Oak
Issue Type: Documentation
Components: jcr
Affects Versions: 1.50.0
Reporter: Wallace Howery
Hello, I'm supporting a 7 year old production application that uses Jackrabbit
Oak, Spring-boot, OSGI, and postgres RDB document storage. The spring-boot is
around version 2.5, and the jackrabbit-oak is 1.50. Due to security
vulnerabilities, we need to move to newer version of spring-boot and other
supporting dependencies.
My problem is there seems to be very little information available about running
Oak in OSGI and spring-boot. I'm getting the impression that OSGI is on the way
out, or at least not in widespread use? An example project that used
Spring-Boot 3 would probably get me out of this crunch.
Also, is OSGI really necessary? We don't need to support hot swaps, multiple
versions of bundles, or any of the things OSGI seems to be geared towards.
One last question: when I start up the app on my laptop, it creates an index in
a folder like \{user}/data/oak/index/ but then uses tables in the Postgres
for storage and search. I'm guessing that folder being created on the file
system is not necessary when using RDB storage, was a bug from the original
developers?
Also, I've been searching online regarding this issue for weeks, I'm at the
point where I would buy a book that described spring-boot/oak/OSGI/rdb-storage.
Any help or guidance is very appreciated!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10475) Expose the mongo connection in MongoDocumentNodeStoreBuilderBase
[ https://issues.apache.org/jira/browse/OAK-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nuno Santos updated OAK-10475: -- Description: This is a follow up of OAK-10453, which changed the indexing job to use custom codecs when downloading from Mongo. For this, the indexing logic needs access to the Mongo Connection to register the codec. If a client uses the MongoDocumentStore (was: This is a follow up of ) > Expose the mongo connection in MongoDocumentNodeStoreBuilderBase > > > Key: OAK-10475 > URL: https://issues.apache.org/jira/browse/OAK-10475 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Nuno Santos >Priority: Minor > > This is a follow up of OAK-10453, which changed the indexing job to use > custom codecs when downloading from Mongo. For this, the indexing logic needs > access to the Mongo Connection to register the codec. If a client uses the > MongoDocumentStore -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10475) Expose the mongo connection in MongoDocumentNodeStoreBuilderBase
[ https://issues.apache.org/jira/browse/OAK-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nuno Santos updated OAK-10475: -- Description: This is a follow up of OAK-10453, which changed the indexing job to use custom codecs when downloading from Mongo. For this, the indexing logic needs access to the Mongo Connection to register the codec. If a library client uses MongoDocumentNodeStoreBuilderBase to build a MongoDocumentStore instance, then it may also need access to the Mongo connection to pass it to the indexing logic. (was: This is a follow up of OAK-10453, which changed the indexing job to use custom codecs when downloading from Mongo. For this, the indexing logic needs access to the Mongo Connection to register the codec. If a client uses the MongoDocumentStore) > Expose the mongo connection in MongoDocumentNodeStoreBuilderBase > > > Key: OAK-10475 > URL: https://issues.apache.org/jira/browse/OAK-10475 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Nuno Santos >Priority: Minor > > This is a follow up of OAK-10453, which changed the indexing job to use > custom codecs when downloading from Mongo. For this, the indexing logic needs > access to the Mongo Connection to register the codec. If a library client > uses MongoDocumentNodeStoreBuilderBase to build a MongoDocumentStore > instance, then it may also need access to the Mongo connection to pass it to > the indexing logic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10475) Expose the mongo connection in MongoDocumentNodeStoreBuilderBase
[ https://issues.apache.org/jira/browse/OAK-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nuno Santos updated OAK-10475: -- Description: This is a follow up of > Expose the mongo connection in MongoDocumentNodeStoreBuilderBase > > > Key: OAK-10475 > URL: https://issues.apache.org/jira/browse/OAK-10475 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Nuno Santos >Priority: Minor > > This is a follow up of -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10475) Expose the mongo connection in MongoDocumentNodeStoreBuilderBase
Nuno Santos created OAK-10475: - Summary: Expose the mongo connection in MongoDocumentNodeStoreBuilderBase Key: OAK-10475 URL: https://issues.apache.org/jira/browse/OAK-10475 Project: Jackrabbit Oak Issue Type: Improvement Components: indexing Reporter: Nuno Santos -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10470) Build Jackrabbit/jackrabbit-oak-trunk #1182 failed
[ https://issues.apache.org/jira/browse/OAK-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773307#comment-17773307 ] Hudson commented on OAK-10470: -- Previously failing build now is OK. Passed run: [Jackrabbit/jackrabbit-oak-trunk #1188|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1188/] [console log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1188/console] > Build Jackrabbit/jackrabbit-oak-trunk #1182 failed > -- > > Key: OAK-10470 > URL: https://issues.apache.org/jira/browse/OAK-10470 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #1182 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #1182|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1182/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1182/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10462) o.a.j.o.plugins.version.VersionEditor#propertyAdded() may mistakenly assume an ongoing restore operation
[ https://issues.apache.org/jira/browse/OAK-10462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-10462: - Fix Version/s: (was: 1.58.0) > o.a.j.o.plugins.version.VersionEditor#propertyAdded() may mistakenly assume > an ongoing restore operation > > > Key: OAK-10462 > URL: https://issues.apache.org/jira/browse/OAK-10462 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Rishabh Daim >Assignee: Manfred Baedke >Priority: Major > > The implementation always uses the value of jcr:versionHistory property but > it needs to check whether the node is versionable or not as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10462) o.a.j.o.plugins.version.VersionEditor#propertyAdded() may mistakenly assume an ongoing restore operation
[ https://issues.apache.org/jira/browse/OAK-10462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-10462: - Summary: o.a.j.o.plugins.version.VersionEditor#propertyAdded() may mistakenly assume an ongoing restore operation (was: o.a.j.o.plugins.version.VersionEditor#propertyAdded() may mistakenly assume an ongoing restore operation.) > o.a.j.o.plugins.version.VersionEditor#propertyAdded() may mistakenly assume > an ongoing restore operation > > > Key: OAK-10462 > URL: https://issues.apache.org/jira/browse/OAK-10462 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Rishabh Daim >Assignee: Manfred Baedke >Priority: Major > Fix For: 1.58.0 > > > The implementation always uses the value of jcr:versionHistory property but > it needs to check whether the node is versionable or not as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (OAK-10462) o.a.j.o.plugins.version.VersionEditor#propertyAdded() may mistakenly assume an ongoing restore operation.
[ https://issues.apache.org/jira/browse/OAK-10462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reopened OAK-10462: -- > o.a.j.o.plugins.version.VersionEditor#propertyAdded() may mistakenly assume > an ongoing restore operation. > - > > Key: OAK-10462 > URL: https://issues.apache.org/jira/browse/OAK-10462 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Rishabh Daim >Assignee: Manfred Baedke >Priority: Major > Fix For: 1.58.0 > > > The implementation always uses the value of jcr:versionHistory property but > it needs to check whether the node is versionable or not as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10462) o.a.j.o.plugins.version.VersionEditor#propertyAdded() may mistakenly assume an ongoing restore operation.
[ https://issues.apache.org/jira/browse/OAK-10462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke resolved OAK-10462. -- Fix Version/s: 1.58.0 Resolution: Fixed > o.a.j.o.plugins.version.VersionEditor#propertyAdded() may mistakenly assume > an ongoing restore operation. > - > > Key: OAK-10462 > URL: https://issues.apache.org/jira/browse/OAK-10462 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Rishabh Daim >Assignee: Manfred Baedke >Priority: Major > Fix For: 1.58.0 > > > The implementation always uses the value of jcr:versionHistory property but > it needs to check whether the node is versionable or not as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10462) o.a.j.o.plugins.version.VersionEditor#propertyAdded() may mistakenly assume an ongoing restore operation.
[ https://issues.apache.org/jira/browse/OAK-10462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773285#comment-17773285 ] Manfred Baedke commented on OAK-10462: -- PR#1141 improves the heuristics used to identify a sentinel node: it has the mix:versionable mixin, but doesn't have a jcr:isCheckedOut property, which hopefully is a unique feature. This is ugly, but it already was before the fix and unfortunately there is no API to detect a restore operation. > o.a.j.o.plugins.version.VersionEditor#propertyAdded() may mistakenly assume > an ongoing restore operation. > - > > Key: OAK-10462 > URL: https://issues.apache.org/jira/browse/OAK-10462 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Rishabh Daim >Assignee: Manfred Baedke >Priority: Major > > The implementation always uses the value of jcr:versionHistory property but > it needs to check whether the node is versionable or not as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10419) Release Oak 1.56.0
[ https://issues.apache.org/jira/browse/OAK-10419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-10419. -- Resolution: Fixed > Release Oak 1.56.0 > -- > > Key: OAK-10419 > URL: https://issues.apache.org/jira/browse/OAK-10419 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10474) Release Oak 1.58.0
Julian Reschke created OAK-10474: Summary: Release Oak 1.58.0 Key: OAK-10474 URL: https://issues.apache.org/jira/browse/OAK-10474 Project: Jackrabbit Oak Issue Type: Task Reporter: Julian Reschke Assignee: Julian Reschke -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OAK-10419) Release Oak 1.56.0
[ https://issues.apache.org/jira/browse/OAK-10419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke closed OAK-10419. > Release Oak 1.56.0 > -- > > Key: OAK-10419 > URL: https://issues.apache.org/jira/browse/OAK-10419 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9922) segment-tar: parallel compaction
[ https://issues.apache.org/jira/browse/OAK-9922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773243#comment-17773243 ] Julian Reschke commented on OAK-9922: - Opened OAK-10472 to track future refactoring, and amended this change to use a private copy of the counter class. > segment-tar: parallel compaction > > > Key: OAK-9922 > URL: https://issues.apache.org/jira/browse/OAK-9922 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Lucas Weitzendorf >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.58.0 > > > Add ability to parallelize compaction over subtrees with multiple threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9922) segment-tar: parallel compaction
[ https://issues.apache.org/jira/browse/OAK-9922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773244#comment-17773244 ] Julian Reschke commented on OAK-9922: - trunk: [c747535b92|https://github.com/apache/jackrabbit-oak/commit/c747535b9274403f4d56a15ebf25aadd109700d0] [c6b4b08da6|https://github.com/apache/jackrabbit-oak/commit/c6b4b08da66e4a362e8ea0a05df3866fb8de5f07] (1.56.0) [965da4c51b|https://github.com/apache/jackrabbit-oak/commit/965da4c51bdd2ba9b0afaa3d4ba840ef91a7768d] [c7aa4f0f7b|https://github.com/apache/jackrabbit-oak/commit/c7aa4f0f7b19567544a633a1e2df6e10fb1b42f9] [ed8494b5e3|https://github.com/apache/jackrabbit-oak/commit/ed8494b5e3a90f0021f3cd6e3fc7112ec9ec6653] (1.46.0) [6545b7912c|https://github.com/apache/jackrabbit-oak/commit/6545b7912cbd4ff602488dc827d93199ebbc87eb] > segment-tar: parallel compaction > > > Key: OAK-9922 > URL: https://issues.apache.org/jira/browse/OAK-9922 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Lucas Weitzendorf >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.58.0 > > > Add ability to parallelize compaction over subtrees with multiple threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10472) Refactor counter APIs from oak-core for use outside oak-core
[ https://issues.apache.org/jira/browse/OAK-10472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-10472: - Summary: Refactor counter APIs from oak-core for use outside oak-core (was: Move ApproximateCounter from oak-core to a place where it can be used by oak-segment-tar) > Refactor counter APIs from oak-core for use outside oak-core > > > Key: OAK-10472 > URL: https://issues.apache.org/jira/browse/OAK-10472 > Project: Jackrabbit Oak > Issue Type: Wish > Components: core >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > Maybe oak-store-spi? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10472) Move ApproximateCounter from oak-core to a place where it can be used by oak-segment-tar
[ https://issues.apache.org/jira/browse/OAK-10472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke reassigned OAK-10472: Assignee: Julian Reschke (was: Andrei Dulceanu) > Move ApproximateCounter from oak-core to a place where it can be used by > oak-segment-tar > > > Key: OAK-10472 > URL: https://issues.apache.org/jira/browse/OAK-10472 > Project: Jackrabbit Oak > Issue Type: Wish > Components: core >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > Maybe oak-store-spi? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9922) segment-tar: parallel compaction
[ https://issues.apache.org/jira/browse/OAK-9922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773168#comment-17773168 ] Marcel Reutegger commented on OAK-9922: --- bq. I believe this is undesirable I agree. oak-core makes use of the NodeStore API in oak-store-spi and oak-segment-tar is an implementation of this API. It doesn't yet introduce a cyclic dependency, but reduces room for manoeuvre. > segment-tar: parallel compaction > > > Key: OAK-9922 > URL: https://issues.apache.org/jira/browse/OAK-9922 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Lucas Weitzendorf >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.58.0 > > > Add ability to parallelize compaction over subtrees with multiple threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10470) Build Jackrabbit/jackrabbit-oak-trunk #1182 failed
[ https://issues.apache.org/jira/browse/OAK-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773152#comment-17773152 ] Hudson commented on OAK-10470: -- Previously failing build now is OK. Passed run: [Jackrabbit/jackrabbit-oak-trunk #1187|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1187/] [console log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1187/console] > Build Jackrabbit/jackrabbit-oak-trunk #1182 failed > -- > > Key: OAK-10470 > URL: https://issues.apache.org/jira/browse/OAK-10470 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #1182 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #1182|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1182/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1182/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10457) Add support to filter and sort a given FFS based provided with predicates and preffered paths
[ https://issues.apache.org/jira/browse/OAK-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Kataria resolved OAK-10457. - Resolution: Duplicate > Add support to filter and sort a given FFS based provided with predicates and > preffered paths > - > > Key: OAK-10457 > URL: https://issues.apache.org/jira/browse/OAK-10457 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Priority: Major > > Given a base FFS on root / , which is only sorted by path without considering > preferredPathElements, > and a set of preferredPathElements and a predicate based on include/exclude > paths, > produce a new FFS that is filtered and sorted based on the provided predicate > and preferred path. > > Also write a test to verify an FFS produced this was is exactly similar to > one produced by normal FFS creation process that picks the > preferredPathElements and predicates from the index definition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10463) Retrieve flatFileStore for indexing from baseFlatFileStore
[ https://issues.apache.org/jira/browse/OAK-10463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Kataria updated OAK-10463: Description: Downloading nodes from mongo is most time consuming part in whole re-indexing process. To avoid it we can maintain flatFileStore using incrementalFFS. Now to make sure this pre-processed FFS can be used for all indexes. The preprocessed FFS should be made on root without any filters. And to finally we can create FFS based on index by filtering and structuring this baseFFS. Steps: # We create BaseFFS without any preferredPaths and filter predicate at checkpoint C1. # We create incrementalFFS between checkpoint C1 and C2. # Merge BaseFFS and incrementalFFS to create baseFFS till C2. # create FFS from baseFFS using preferredPaths and filter predicate from index definition. # Index using the FFS created in step 4. This issue is to perform step 4. was: Downloading nodes from mongo is most time consuming part in whole re-indexing process. To avoid it we can maintain flatFileStore using incrementalFFS. Now to make sure this pre-processed FFS can be used for all indexes. The preprocessed FFS should be made on root without any filters. And to finally we can create FFS based on index by filtering and structuring this baseFFS. > Retrieve flatFileStore for indexing from baseFlatFileStore > -- > > Key: OAK-10463 > URL: https://issues.apache.org/jira/browse/OAK-10463 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > Fix For: 1.58.0 > > > Downloading nodes from mongo is most time consuming part in whole re-indexing > process. To avoid it we can maintain flatFileStore using incrementalFFS. > Now to make sure this pre-processed FFS can be used for all indexes. The > preprocessed FFS should be made on root without any filters. And to finally > we can create FFS based on index by filtering and structuring this baseFFS. > Steps: > # We create BaseFFS without any preferredPaths and filter predicate at > checkpoint C1. > # We create incrementalFFS between checkpoint C1 and C2. > # Merge BaseFFS and incrementalFFS to create baseFFS till C2. > # create FFS from baseFFS using preferredPaths and filter predicate from > index definition. > # Index using the FFS created in step 4. > > This issue is to perform step 4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
