You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A "risk assessment" worker is a Kotlin service running in a container that listens to an SQS queue for a "risk assessment" payload. When one is received, it launches a thread for the task that does the following:
loads the proper risk assessment scoring algorithm measure from a library of selections (by an identifier in the payload)
executes the risk assessment measure on a single device node (by an identifier in the payload), outputting a risk score
saves the score to a DynamoDb table, where partition key is the device id and the sort key is the "{risk assessment measure id}#{timestamp}" of the assessment. The table contains the score as a column (see Create a DynamoDb table to store risk assessment results #77 for full details)
triggers an SNS notification that the work was completed.
either terminates itself or indicates to the manager that it is available for a new task.
NOTE: We should have a parameter to set a max "worker thread" per container because each measure might have different memory requirements and/or different computational complexity. Long term, we should have a cloudwatch alarm on the SQS topic that will spin up more of these containers should it back up.
NOTE 2: We need to make sure the SQS topic visibility timeout is sufficiently long. The default of 30 seconds may not be long enough, which will result in the workers doing repeat work.
The text was updated successfully, but these errors were encountered:
A "risk assessment" worker is a Kotlin service running in a container that listens to an SQS queue for a "risk assessment" payload. When one is received, it launches a thread for the task that does the following:
NOTE: We should have a parameter to set a max "worker thread" per container because each measure might have different memory requirements and/or different computational complexity. Long term, we should have a cloudwatch alarm on the SQS topic that will spin up more of these containers should it back up.
NOTE 2: We need to make sure the SQS topic visibility timeout is sufficiently long. The default of 30 seconds may not be long enough, which will result in the workers doing repeat work.
The text was updated successfully, but these errors were encountered: