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

Request ID shared between different requests #100

Closed
Akrog opened this issue Mar 7, 2019 · 0 comments · Fixed by #95
Closed

Request ID shared between different requests #100

Akrog opened this issue Mar 7, 2019 · 0 comments · Fixed by #95
Assignees
Labels
bug Something isn't working

Comments

@Akrog
Copy link
Member

Akrog commented Mar 7, 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:

@Akrog Akrog added the bug Something isn't working label Mar 7, 2019
@Akrog Akrog self-assigned this Mar 7, 2019
Akrog added a commit to Akrog/ember-csi that referenced this issue 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 issue 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.
@Akrog Akrog closed this as completed in #95 Mar 13, 2019
Akrog added a commit that referenced this issue Mar 13, 2019
Fix a number of bugs:

- Fix #94 - Bock attach and detach
- Fix #96 - Publish incompatible modes
- Fix #97 - List volume on CSI v0.3
- Fix #99 - Probe collision
- Fix #100 - Shared request ID
- Fix #101 - Repeated request IDs
- Fix #102 - Volume soft delete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant