Querying Nerada - AFS

AFS Installation and Administration Guide

Product
AFS
AFS_Version
7.10
Platform
RHEL
Category
Reference Guide

Nerada introduces the following optional query parameters:

  • afs:paf_id: Is used to synchronize with the search database. A typical usage would be to define afs:paf_id=3 in which 3 is the PaF ID returned by a search query.

    If the afs:paf_id parameter is not defined in the query, the most recent successful PaF ID known to Nerada is used. This can cause a response desynchronization.

    Note: In the Nerada context, a successful PaF is one that has not failed, and for which all documents were uploaded.

  • cr_driver (defined in AFS/MESSAGES/driver.proto): Can be set to one of the following values:
    • REPLY_DATABASE to read the response from the legacy content repository
    • NERADA to read the response from Nerada

No check is performed to verify that the corresponding writing switch is active, ContentRepository/Nerada/enableWrite or ContentRepository/Legacy/enableWrite.

The following diagrams shows the document workflow in a transition installation including both the UM and Nerada database.

Document workflow while transitioning from the legacy CR to Nerada

Nerada supports the following query types:
- Only queries by document URIs
- One document and one layer only per query

Example of scenario

The following chronology states what happens with a succession of three different PaFs:

  • 2 pm: The PaF #1 runs to index the two new documents A and B. The Indexer sends the documents to the Update Manager and Nerada.

    During the PaF1, the Indexer sends the documents to the UM and Nerada

    • 2:05 pm: Users cannot see the documents A and B on the front-end environments. Indeed, the PaF #1 search database were not sent to the front yet.

      Users see no document.

  • 2:10 pm: The Update Manager sends the PaF #1 search database to the fronts front-1 and front-2.

    The UM sends the documents to the front search database

    • 2:15 pm: Users can now see the documents A and B on the front-end environments.

      Users see documents A and B

  • 2:20 pm: The PaF #2 runs: the document A is updated to A-v2 and the document B is deleted. The Indexer sends the new instructions to the Update Manager and Nerada.

    During the PaF2, the Indexer sends the document and updates to  the UM and Nerada

    • 2:25 pm: Users still see the documents A and B on the front-end environments. Indeed the PaF #2 search database were not sent to the front yet.

      Users see documents A and B

  • 2:30 pm: The Update Manager sends the PaF #2 search database to the fronts front-1 and front-2.

    The UM sends the documents to the front search database

    • 2:35 pm: Users can now see the document A-v2 and cannot see the document B anymore on the front-end environments.

      Users only see the document A-v2

  • 2:40 pm: The PaF #3 runs with neither new document nor update. As fronts front-1 and front-2 are still synchronized with the PaF #2, a data cleanup is launched on Nerada and PaF #1 unused documents (A and B) are deleted.

    The PaF3 runs and Nerada is cleaned from unused documents

    • 2:45pm: The PaF #3 has no impact on users. Users can still see the document A-v2 and cannot see the document B on the front-end environments.

      Users only see the document A-v2