-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
PythonParser vs HiredisParser on_disconnect behavior #1085
Comments
I suspect it's because it's not covered with test cases. Feel free to provide a PR with coverage that does not break compatibility. |
I'm sorry, but I don't understand, what a PR should cover? |
You're right, the inconsistency is an error. From briefly scanning this, it seems wrong that Are you proposing that we simply remove the |
Yes, this, at least, will make "on disconnect" behaviour similar regardless of parser used in connection. |
@popravich I agree. If you want to create a PR that removes the I'm also open to addressing the fork issues you're seeing in kombu/celery. Just let me know. |
…onnect implementation/behavior (related to redis#1085). When hiredis is installed and HiredisParser is used (implicitly), connection can not be securily shared between process forks.
Hi, @andymccurdy, |
Sometimes a process with an active connection to Redis forks and creates child processes taht also want to talk to Redis. Prior to this change there were a number of potential conflicts that could cause this to fail. Retrieving a connection from the pool and releasing a connection back to the pool check the current proceeses PID. If it's different than the PID that created the pool, reset() is called to get a fresh set of connections for the current process. However in doing so, pool.disconnect() was caused which closes the file descriptors that the parent may still be using. Further when the available_connections and in_use_connections lists are reset, all of those connections inherited from the parent are GC'd and the connection's `__del__` was called, which also closed the socket and file descriptor. This change prevents pool.disconnect() from being called when a pid is changed. It also removes the `__del__` destructor from connections. Neither of these are necessary or practical. Child processes still reset() their copy of the pool when first accessed causing their own connections to be created. `ConnectionPool.disconnect()` now checks the current process ID so that a child or parent can't disconnect the other's connections. Additionally, `Connection.disconnect()` now checks the current process ID and only calls `socket.shutdown()` if `disconnect()` is called by the same process that created the connection. This allows for a child process that inherited a connection to call `Connection.disconnect()` and not shutdown the parent's copy of the socket. Fixes #863 Fixes #784 Fixes #732 Fixes #1085 Fixes #504
PythonParser's
on_disconnect
implementation is inconsistent with HiredisParser implementation (or vice versa):and
Why does the PythonParser closes the
_sock
object?By doing this the subsequent
shutdown()
andclose()
inConnection.disconnect
does not make any sense, in fact it shutdown on closed socket raises error which is ignored.I can submit a PR but please tell me what place to fix? (HiredisParser/PythonParser/shutdown)
PS: this issue causes other issues in other repos (celery/kombu#954, celery/celery#3898)
The text was updated successfully, but these errors were encountered: