Old statuses are kept unnecessarily #111
Assignees
Labels
bug
Something isn't working
Comments
callumforrester
changed the title
|
@keithralphs The bookkeeping is done, apparently wrong, in this class: https://github.com/DiamondLightSource/blueapi/blob/main/src/blueapi/worker/reworker.py#L194 |
joeshannon
added a commit
that referenced
this issue
May 15, 2023
For some devices there may be an additional status update broadcast after the on_complete callback. This causes the status to be added back to the dictionary where it will never be removed. Track which statuses have been completed and check this set when updating to ensure that a completed status is never added back to the snapshot after on_complete is called.
joeshannon
added a commit
that referenced
this issue
May 16, 2023
For some devices there may be an additional status update broadcast after the on_complete callback. This causes the status to be added back to the dictionary where it will never be removed. Track which statuses have been completed and check this set when updating to ensure that a completed status is never added back to the snapshot after on_complete is called.
joeshannon
added a commit
that referenced
this issue
May 16, 2023
For some devices there may be an additional status update broadcast after the on_complete callback. This causes the status to be added back to the dictionary where it will never be removed. Track which statuses have been completed and check this set when updating to ensure that a completed status is never added back to the snapshot after on_complete is called.
joeshannon
added a commit
that referenced
this issue
May 17, 2023
For some devices there may be an additional status update broadcast after the on_complete callback. This causes the status to be added back to the dictionary where it will never be removed. Track which statuses have been completed and check this set when updating to ensure that a completed status is never added back to the snapshot after on_complete is called.
joeshannon
added a commit
that referenced
this issue
May 18, 2023
For some devices there may be an additional status update broadcast after the on_complete callback. This causes the status to be added back to the dictionary where it will never be removed. Track which statuses have been completed and check this set when updating to ensure that a completed status is never added back to the snapshot after on_complete is called.
joeshannon
added a commit
that referenced
this issue
May 18, 2023
For some devices there may be an additional status update broadcast after the on_complete callback. This causes the status to be added back to the dictionary where it will never be removed. Track which statuses have been completed and check this set when updating to ensure that a completed status is never added back to the snapshot after on_complete is called. * Add module for test devices * Add devices module to test environment * Add test for progress events
|
Fixed with #203 |
rosesyrett
pushed a commit
that referenced
this issue
Nov 10, 2023
) As well as data documents, blueapi produces events when the status objects monitored by the run engine are updated. These events are useful for creating progress bars and similar updates. Unfortunately it seems very easy to unintentionally make plans/devices produce a very large number of these updates. The handling of all of these results in log spam and high CPU usage. We're seeing this now on I22 and have seen similar problems before (see #111). I think the easy way to make debugging easier is to make the status update handling optional and easy to turn off via config. To that end... Changes: - Add config option to disable status events - Make the worker only hook into the run engine if this option is marked as true
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When producing
TaskEvents. The worker includes statuses for completed operations e.g. moving a motor between two previous points in a scan. These are not needed and significantly bloat the size of the event, causing performance issues in client software.The text was updated successfully, but these errors were encountered: