Sequence diagrams#

This section provides sequence diagrams for basic LIM operations.

Index creation diagram#

The index is built after creating a task to build it. There are two types of creating index building tasks - one-time and background.

Below is a sequence diagram for both types of task creation.

(1.1) Sending "create task" request to one-time index building
(1.2.1) Enabling dynamic indexing of lists by setting the "dynamic" value for the "indexing_list" setting
(1.2.2) Setting the minimum number of faces in the list by which the index will be built (default 50,000) in the "min_indexing_list_size" setting
(1.2.3) Reading the settings values from the Configurator service
(1.3.1) Setting a set of lists in the "indexing_list" setting
(1.3.2) Reading the setting value from the Configurator service
(2) Beginning of the planning routine (regulated by setting "planning_period" section "LIM_MANAGER_INDEXING"). Checking which sets of lists should be indexed
(3) Saving information about the task being created in the Redis storage
(4) Response that the task was placed in storage
(5) Sending the task to an internal queue
(6) Response that the task was queued. At this stage, the status of the task is set to "pending"
(7) Response that the task was created. Only for one-time index building (see (1.1))
(8) Beginning of lookup routine (regulated by setting "lookup_period" of section "LIM_MANAGER_INDEXING"). Checking the status of running Indexer instances
(9) Response that the Indexer instance is ready to start index creation
(10) Retrieving the task from the internal queue
(11) Response that the task was retrieved
(12) Request to build a index on the created task
(13) Response that the request to build the index on the created task was accepted
(14) Updating task information. At this stage, the status of the task is set to "indexing"
(15) Start making periodic indexing status requests
(16) Making requests to the Faces service to get descriptors belonging to the list
(17) Redirecting requests to the Faces database
(18) Uploading data from the Faces database
(19) Redirecting the uploaded data to the Faces service
(20) Index building process
(21) Saving the index to the Index storage
(22) Continuation of lookup routine. Checking the status of running Indexer instances
(23) Response that the instance has finished building the index
(24) Updating task information. At this stage, the status of the task is set to "success"
(25) Sending to Influx database
(26) End making of periodic indexing status requests

You can find out the current status of the task using the request "get tasks" after it has been created.

Diagram of initial index loading into memory#

Before the matching starts, the index is loaded into the Indexed Matcher memory service.

(1) Loading the most relevant index from the Storage into the memory of the Indexed Matcher service
(2) Caching the index into an intermediate directory. The directory is specified in the "lim_matcher_cache" setting of the Indexed Matcher service. By default, caching is disabled. See the "Index caching" section for details.
(3) Loading matching label in Redis. The label name is the same as the list ID
(4) Response that the label is loaded
(5) Register a Redis stream as a message handler for the appropriate matching label. At this point, the stream is given the name of the matching label (i.e. the name of the list id)
(6) Response that the stream is registered
(7) Waiting for matching request that contains a matching label with exactly the same name as the one loaded in Redis (3) and for which the stream was registered (5)

Diagram of matching descriptors#

This diagram assumes that the index is already loaded into the memory of the Indexed Matcher service (see "Diagram of initial index loading into memory").

(1) Sending the matching request
(2) Request to calculate the matching cost of request
(3) Checking whether the matching label is loaded to Redis
(4) Response
- (5.1.1) If the matching label exists, then the matching cost of the request is considered infinite and the matching plugin returns the corresponding information to the Python Matcher Proxy service
- (5.1.2) Request for matching to the Python Matcher service
- (5.1.3) Matching process in the Python Matcher service
- (5.1.4) Response about matching result to the Python Matcher Proxy
- (5.1.5) Response about matching result to the API
- (5.2.1) If the matching label not exists, then the certain matching cost of the request is calculated and the response is returned to the Python Matcher Proxy service
- (5.2.2) Sending the matching request to the matching plugin
- (5.2.3) Converting the request and sending it as a message to the Redis stream
- (5.2.4) The Indexed Matcher service is listening to the Redis stream (see "Diagram of initial index loading into memory"). As soon as the matching request appears, which contains the matching label with exactly the same name as the one that was previously uploaded to Redis and for which the stream was registered, then Indexed Matcher reads the message for matching
- (5.2.5) Response that the message was read
- (5.2.6) Performing license verification
- (5.2.7) Response about the license status (this diagram does not reflect the case of invalid license)
- (5.2.8) Performing the matching process
- (5.2.9) Recording the matching result in the Redis channel
- (5.2.10) The matching plugin reads the matching result from the Redis channel
- (5.2.11) Sending the matching result to the Python Matcher Proxy
- (5.2.12) Sending the matching result to the API

Index reloading diagram#

This diagram reflects only the sequence of work in the case when an index with a newer version of the matching label appears in the Index storage. If the index disappears from Index storage, then after checking the status of the index, the Indexed Matcher service deletes it from memory. This functionality is enabled using the "enabled = 1" setting (enabled by default) of the "LIM_MATCHER_REFRESH" section of the Indexed Matcher service settings.

Note. It is recommended to read the section "Index reloading".

(1) Checking whether the current index in the Index storage was changed. If the Index storage has a more recent index at the time of saving for the same matching label and with the desired version of the descriptor, then this will be taken into account as the fact that the current index is not relevant.
(2) Response that the index is not relevant
(3) Request to enable Redis lock
(4) Response about successful Redis lock. If it is currently impossible to perform the lock, then Indexed Matcher will perform lock attempts until the next attempt succeeds.
(5) If the lock is successful, then stop matching using the current index
(6) Deleting the old index from the Indexed Matcher memory
(7) Loading a new index from the Index storage into the Indexed Matcher service memory
(8) Response that the index is loaded into memory
(9) Request to disable Redis lock
(10) Response that the lock is disabled
(11) Continuation of the matching

Index refreshing diagram#

Below is a sequence diagram for the process of refreshing an index in the memory of the Indexed Matcher service.

Note. This information is described for an index that is already loaded into the memory of the Indexed Matcher service. The index in the service's memory and the index in the storage may differ. It is recommended to read the section "Refreshing index in memory".

(1) Receiving processing of matching requests
(2) Starting of matching
(3) Request to check the state of the list to Faces (request is performed every second)
(4) Redirecting the request to check the state of the list to the Faces database
(5) Response
(6) Response
- (7.1) If no new descriptors was added to the list, then the matching will continue until the next check of the list status (3)
- (7.2.1) If new descriptors were added to the list, the matchings stops
- (7.2.2) Request missing descriptors to the Faces service
- (7.2.3) Redirecting the request to the Faces database
- (7.2.4) Response containing missing descriptors
- (7.2.5) Response containing missing descriptors
- (7.2.6) Adding missing descriptors to the index located in the memory of the Indexed Matcher service (no more than 10 descriptors at a time)
- (7.2.7) Continuation of the matching until the next check of the state of the list (3)