Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Results Rankings index should be per virtual instance, not shared

Fix Priority

5

Components

Affects versions

Fix versions

Labels

Git Pull Request

Description

Steps to reproduce - Single deployment scenario

  1. Navigate to Control Panel > Search Tuning > Results Ranking

  2. Add a Results Ranking with the Example query

  3. Create a new Virtual Instance

  4. Navigate to Virtual Instance and login

  5. Navigate to Control Panel > Search Tuning > Results Ranking

Expected Result: The Results Ranking created in Step 2 shouldn't show up.

Actual Result: The Results Ranking created in Step 2 does show up.

Tested on:
Tomcat 9.0.17 + MySQL 5.7
Portal master-private SHA: bde67ee189e438bb57d8ceef095e82cf9e423fad
Portal 7.2.x-private SHA: 570fd31ff0fb47548c841ac0fd386849bdc3ac92

Steps to reproduce - Multi-tenant deployment scenario

Assumptions, facts:

  • Elasticsearch is multi-tenant: it can host multiple indexes

  • Liferay's Elasticsearch integration leverages multi-tenancy since each Virtual Instance has its own index

  • The name of the indexes for the Virtual Instances can be prefixed through the Elasticsearch 6 connector's System Settings ("Index Name Prefix")

  • Liferay/DXP can be configured to operate on "deployment data centers" so the Counter will generate values without fear of collision (for example for the company ID)

  1. Unpack 2 DXP 7.2 SP1 (or master-private/7.2.x-private) bundles (let's refer to them as "prod" and "uat")

  2. Configure Elasticsearch 6.8.x to use "LiferayElasticsearchCluster" as cluster name (elasticsearch.yml) and start it

  3. Configure the Elasticsearch 6 connector on the "prod" server like this:

    prod/osgi/configs/com.liferay.portal.search.elasticsearch6.configuration.ElasticsearchConfiguration.config

  4. Configure "prod" to connect to to its own DB (db-prod)

  5. Start "prod" ad perform a reindex
    Verify - prod that multiple indexes are created through the Control Panel - Configuration - Search - Field Mappings under "INDEX", something like

  6. Add an arbitrary content, for example Web Content Article

  7. Go to Control Panel - Search Tuning - Result Rankings on "prod" and create an arbitrary ranking entry (let's call it "dxp") pinning that article you just created

  8. Configure "uat" Tomcat to run on different ports

  9. Configure the Elasticsearch 6 connector on the "uat" server like this:

    uat/osgi/configs/com.liferay.portal.search.elasticsearch6.configuration.ElasticsearchConfiguration.config

  10. Configure "uat" to connect to to its own DB (db-uat)

  11. Configure Counter for "uat" like this:

    uat/portal-ext.properties

  12. Start "uat" ad perform a reindex
    Verify - uat that multiple indexes are created through the Control Panel - Configuration - Search - Field Mappings under "INDEX", something like

  13. Add an arbitrary content, for example Web Content Article

  14. Go to Control Panel - Search Tuning - Result Rankings on "uat"
    Result: The "dxp" Result Rankings entry appears even though we created it on "prod"

  15. Delete the "dxp" entry

  16. Go to Control Panel - Search Tuning - Result Rankings on "prod"
    Result: The "dxp" entry is missing

The liferay-results-rankings index is shared across the deployments.

100% Done
Loading...

Activity

Show:

Tibor Lipusz August 3, 2020 at 3:15 AM

Brooke March 3, 2020 at 3:14 PM
Edited

PASSED Manual Testing following the steps in the description.

Test on:
Tomcat 9.0.17 + MySQL 5.7 Portal master GIT ID: 34f64688dfc01e106cd8dbd04dcce0b53a835432

The Results Ranking created in one virtual instance is not shared with another virtual instance's Result Ranking

Jorge Díaz February 17, 2020 at 12:27 PM

Thank you for the information,

Michael Han February 17, 2020 at 9:19 AM

The issue here is the potential collisions between company/instanceIds. We have no way to guarantee that 2 different production instances have unique companyIds. We can certainly tell customers to go ahead and configure different index prefixes (e.g. instead of "liferay-" prefix, use "liferay-prod-1-" and "liferay-prod-2-"). However, that leaves a lot of manual configuration for customers that can be messed up.

The bug that we do have is the other indices beyond the "Liferay" index (e.g. the ones used for workflow) do not comply properly w/ the 1 index per company paradigm. This is something we do need to fix.

Wade Cao November 7, 2019 at 12:26 PM

Fix:

1) Adding indexNamePrefix to the "liferay-results-rankings"
prefix + "-0-liferay-search-tuning-rankings" per virtual instance.
The prefix is the value from System Settings -> Search > Elasticsearch*> Index Name Prefix

2) Scheduling a background task for renaming the existing liferay-results-rankings if there is one upon the module starting up.

per Tibor Lipuse's suggestion:

We have to be careful with this fix though: we can't break existing deployments where the index name was not prefixed (FP2 patch level).
Especially because there is no way to trigger a "reindex": we check on startup if the index is there and attempt to create if not. But if the index was created preciously without a prefix it won't find it if we force to use that prefix after fix.
Unless we introduce a logic that moves the existing RR entries from the existing index to the new now prefixed index upon startup, or something like that.

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Parent

Branch Version/s

7.2.x

Backported to Branch

Committed

Sprint

Zendesk Support

Created September 9, 2019 at 2:25 PM
Updated September 5, 2021 at 11:59 PM
Resolved February 28, 2020 at 7:25 AM
Configure