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

PubSub close() causes Connections from a ConnectionPool to disconnect #3487

Open
levic opened this issue Jan 24, 2025 · 0 comments
Open

PubSub close() causes Connections from a ConnectionPool to disconnect #3487

levic opened this issue Jan 24, 2025 · 0 comments

Comments

@levic
Copy link

levic commented Jan 24, 2025

I was wondering why my redis server showed more connect/disconnects than I expected when using PubSub

  • I obtain a connection from a ConnectionPool
  • I call pubsub = connection.pubsub()
  • I do some processing
  • I now call pubsub.close()
  • This calls reset()
  • reset() calls disconnect() before releasing the connection back to the pool
  • disconnect() causes the underlying TCP socket to get disconnected
  • the next time the connection is handed out from the ConnectionPool it has to reconnect (avoiding this is the main reason for using a ConnectionPool in the first place)

The documentation states:

When you’re finished with a PubSub object, call its .close() method to shutdown the connection.

(and there are various other places that will call it anyway, eg PubSub.__del__, PubSubWorkerThread.run)

There appears to be no other way to release the connection back to the ConnectionPool (and even if you don't call PubSub.close(), PubSub.__del__() will invoke it at some point anyway). Simply commenting out the disconnect() causes other errors, it looks like the "unsubscribe" acknowledgement is not consumed but I only did a quick test.

Is this an oversight or is there some limitation of PubSub that means it must reset the TCP connection?

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

No branches or pull requests

1 participant