Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Metadata update issues #135

Merged
merged 2 commits into from
Oct 19, 2021
Merged

Metadata update issues #135

merged 2 commits into from
Oct 19, 2021

Commits on Oct 19, 2021

  1. Ensure mon plugins always process metadata first time for new inputs 

    For "new" inputs, don't rely on the changed flag - need to process metadata regardless if we've never processed any for the input so we set it's initial state. This state can occur if a new monitoring plugin is inserted. All metadata from inputs will have "changed" state as false if they haven't changed, but the monitoring plugin must process it anyway if it has never processed any metadata for an input so we set the correct initial state
    @firthm01 @rsjbailey
    firthm01 authored and rsjbailey committed Oct 19, 2021
    Configuration menu
    Copy the full SHA
    fa16d86 View commit details
    Browse the repository at this point in the history

  2. Ensure change flag set on metadata send 

    * Add helpers to setters that ensure lock set and flag updated on data modification
* Rename getMetadata to prepareMetadata and ensure data access protected
  Currently the setChanged flag is being cleared/set while the data mutex is not
  locked.
  As getMessage() already aquires this lock and is only ever used when sending a
  message, move the flag clear inside this method and rename to prepareMetadata to
  reflect the fact it is no longer simply retrieving data.
  Add a lock within the error callback in case sending fails and the flag must be
  reset
  This looks scary as we have multiple locks being aquired within sendMetadata()
  I think it's ok as on the send side we are already aquiring this lock, we're
  just adding a data mutation. On the receive side we're adding a lock, but we
  will only ever call the success or failure path, never both, so shouldn't be the
  case where we might deadlock waiting for two different mutexes - in this way
  it's no different to aquiring a lock in any of the setter methods.

* Don't hold data mutex on disconnect
  This shouldn't be necessary as all data access is now guarded where it
  happens, and could pause double lock/deadlock on the send error handler
  if an in flight message is cancelled by disconnect
    @firthm01 @rsjbailey
    firthm01 authored and rsjbailey committed Oct 19, 2021
    Configuration menu
    Copy the full SHA
    588d1d8 View commit details
    Browse the repository at this point in the history