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.

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

fix: Add locking around MQTT client setup and around connecting to avoid race conditions. #474

Merged
merged 1 commit into from
Sep 10, 2020

Conversation

lenny-goodell
Copy link
Member

PR Checklist

Please check if your PR fulfills the following requirements:

  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • Other... Please describe:

What is the current behavior?

race case exist when setting up and connecting to the MQTT export client

Issue Number: #471

What is the new behavior?

Mutex locks added around setting up and connecting to the MQTT export client

Does this PR introduce a breaking change?

  • Yes
  • No

Are there any new imports or modules? If so, what are they used for and why?

No

Are there any specific instructions or things that should be known prior to reviewing?

Other information

@lenny-goodell lenny-goodell marked this pull request as draft September 9, 2020 04:33
@cloudxxx8
Copy link
Member

cloudxxx8 commented Sep 9, 2020

LGTM, but should we also fix the MQTTSend (mqtt.go)?
Although it is deprecated, the mqtt-export sample configuration is still using MQTTSend

@lenny-goodell
Copy link
Member Author

should we also fix the MQTTSend (mqtt.go)?

Yes, once I have a chance to run this one through real tests.

@lenny-goodell lenny-goodell force-pushed the race branch 2 times, most recently from 8606d82 to 1609e27 Compare September 9, 2020 21:50
@lenny-goodell lenny-goodell marked this pull request as ready for review September 9, 2020 21:53
@lenny-goodell
Copy link
Member Author

@cloudxxx8 , Added locking to MqttSend and also recheck conditions after locks to make sure still need to do the actions.
I have validated this has no impact on normal operations with Device Virtual producing the data. Can you validate with you use case that exposed the race condition?

@lenny-goodell
Copy link
Member Author

recheck

@weichou1229
Copy link
Member

@lenny-intel I tested your fixing with my use case and it works fine.

Copy link
Contributor

@jim-wang-intel jim-wang-intel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@lenny-goodell
Copy link
Member Author

recheck

@lenny-goodell lenny-goodell merged commit b0f6186 into edgexfoundry:master Sep 10, 2020
@lenny-goodell lenny-goodell deleted the race branch September 10, 2020 17:53
@cloudxxx8
Copy link
Member

@lenny-intel we opened this issue edgexfoundry/app-service-configurable#108 because we encountered the race condition in MQTTSend
The sample configuration profile is using MQTTSend, and our automation test has to use it

@cloudxxx8
Copy link
Member

Sorry, I just noticed it has been fixed in MQTTSend, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants