Uploaded image for project: 'mod-data-export-spring'
  1. mod-data-export-spring
  2. MODEXPS-81

EDIFACT export scheduling doesn't support work in the cluster and after restart docker container

    XMLWordPrintable

Details

    • Thunderjet
    • Nolana R3 2022
    • !!!ALL!!!
    • Incomplete/missing requirements

    Description

      Overview

      Before running scheduled task(job) there is check, that module is registered for the Okapi tenant.
      Tenant information need to define DB schema for storing information about Job and etc.
      In the post tenant API controller specific user (data-export-system-user) is created for running scheduled export tasks.
      Also Okapi headers, system user, tenant information are stored in memory in a FolioExecutionContext.

      Registration is happened in the Post Tenant controller, which invoked by POST request
      "okapiprotocol://okapiurl:okapiport/_/proxy/tenants/xokapitenant/modules".

      When a problem is discovered :

      Case 1:

      One instance of the mod-data-export-spring is deployed and registered. Schedulers work and no problem.
      After some time instance crashed(no matter why) and Kubernetes(manually) restarts docker container.
      Container restarted and no need to register modules, because version is not changed. As result Post Tenant controller was not invoked and flag in memory "registered" in the FolioExecutionContextHelper is "false".
      Also no information about "system user" is stored in memory.
      Finally job was not started by schedule.

      Case 2:

      Two or more instance of the mod-data-export-spring are deployed and registered. Schedulers work and no problem.
      After some time one of the instance crashed(no matter why) and Kubernetes(manually) restarts docker container.
      Container restarted and no need to register modules, because version is not changed. As result Post Tenant controller was not invoked and flag in memory "registered" in the FolioExecutionContextHelper is "false".
      Also no information about "system user" is stored in memory.
      Finally job was not started by schedule.

      Question : How to understand which tenant or module version a particular deployed instance of the module belongs to?
      Answer : from Mark Johnson
      I think there are two parts to your question.
      Please do let me know if I’ve misunderstood your question. I think I might have, especially for the tenant part.
      Which tenant does a particular deployed instance of a module belongs to?
      Instances of a module do not belong to any specific tenant.
      All tenants in the same instance of FOLIO share all of the module instances.
      For example, if a module version is enabled for 5 tenants, all requests for those tenants will be spread across all of the instances of that module version.

      Which module version a particular deployed instance of the module belongs to?
      There may not be a good way to do this.
      Some modules might implement an endpoint that provides this kind of information. I don’t know if either RMB or FOLIO Spring Base do this by default. It could be worth FOLIO having a standard for such things.
      Otherwise it will likely depend upon how the module is packaged and deployed.
      For example, if it is a java module and running natively (against the JVM) then the jar might be named after the module version. If it is a docker image, the image might be named after the module version.

      Workaround

      If only one instance is used, then It is necessary to deploy and register a new version of the module using the same artifacts (docker container/image or fat Jar)

      Approach

      Open issues:

      1. Scheduling happened by specific user : System user.
      System user is initialized only in scope of PostTenant API (org.folio.des.controller.FolioTenantController).
      This is API never called after container restarting or adding new instances of the mod-data-export-spring
      2. Also looks like there is no easy way to define for which tenants particular instance is enabled.

      Suggested approaches

      1. To identify to which tenant instance is available looks like possible to use Okapi APIs, but for that need to define instance Id. After that will be possible to retrieve system users and instantiate org.folio.des.config.FolioExecutionContextHelper
      To achieve that implementing ApplicationListener for WebServerInitializedEvent can allow read port and url of the instance and using this info define instance Id and after list of tenants.

      Acceptance criteria

      Scheduler works after restarting module without registering.

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                Andrei_Makaranka Andrei Makaranka
                Andrei_Makaranka Andrei Makaranka
                Andrei Makaranka Andrei Makaranka
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                  Created:
                  Updated:

                  TestRail: Runs

                    TestRail: Cases