fix vol_id env #2
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Akrog
added a commit
to Akrog/ember-csi
that referenced
this pull request
Mar 8, 2019
All concurrent requests are sharing the same request ID, so when we receive a new request it overwrites the request ID of the previous thread and they all start reporting the same ID. Timeline: - Request embercsi#1 comes in --> Start logging as embercsi#1 - Request embercsi#2 comes in --> Start logging as embercsi#2 - Request embercsi#1 logs as request embercsi#2 - Request embercsi#2 logs as request embercsi#2 - Request embercsi#3 comes in --> Start logging as embercsi#3 - Request embercsi#1 logs as request embercsi#3 - Request embercsi#2 logs as request embercsi#3 This is caused by not monkey patching the threading library soon enough and the thread storage is actually using the storage of the native thread instead of locations for each greenthread. There is only 1 case where the code will fail with this change, and that is if the `hostname` is not in /etc/hosts as the greenthread DNS library does not check /etc/hostname, only /etc/hosts. The solution is to either add the hostname to /etc/hosts or set environmental variable `EVENTLET_NO_GREENDNS=yes`. But we don't recommend the environmental variable, since this may also affect our drivers if they are using hostnames in their configurations.
Akrog
added a commit
to Akrog/ember-csi
that referenced
this pull request
Mar 12, 2019
All concurrent requests are sharing the same request ID, so when we receive a new request it overwrites the request ID of the previous thread and they all start reporting the same ID. Timeline: - Request embercsi#1 comes in --> Start logging as embercsi#1 - Request embercsi#2 comes in --> Start logging as embercsi#2 - Request embercsi#1 logs as request embercsi#2 - Request embercsi#2 logs as request embercsi#2 - Request embercsi#3 comes in --> Start logging as embercsi#3 - Request embercsi#1 logs as request embercsi#3 - Request embercsi#2 logs as request embercsi#3 This is caused by not monkey patching the threading library soon enough and the thread storage is actually using the storage of the native thread instead of locations for each greenthread. There is only 1 case where the code will fail with this change, and that is if the `hostname` is not in /etc/hosts as the greenthread DNS library does not check /etc/hostname, only /etc/hosts. The solution is to either add the hostname to /etc/hosts or set environmental variable `EVENTLET_NO_GREENDNS=yes`. But we don't recommend the environmental variable, since this may also affect our drivers if they are using hostnames in their configurations.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.