Open sync opened 4 years ago
I hacked around it but it is definitely not a good solution:
https://github.com/sync/bb8/commit/876ed2c2b2b7d94922c83c1d87e69c3569341640
Having a second pool for this doesn't seem so bad. Why do you think it's not a good solution?
Can you get yourself a dedicated connection (via Pool<M>::dedicated_connection
) and use that? I'm not entirely sure how Redis's pub-sub stuff works but I added that for doing LISTENs on postgres.
I didn't like the fact that i have to create a fake subscription to see if pool is working... I've opened a PR let me know what you think: https://github.com/khuey/bb8/pull/71
@khuey i can't see any usage of the dedicated_connection in the codebase, do you have a sample somewhere ?
Pool::dedicated_connection()
is a simple method on the Pool
that uses the address/authentication information contained in the Pool
's ConnectionManager
to build a new connection, and then directly yields that connection to the caller. I think it would make sense to use for this (as discussed in #71 as well).
@djc might you be open to supporting a pubsub connection pool? The changes to do so seem pretty minimal (still need to figure out what is_valid
should look like there).
My usecase for it is that we're looking to use an adhoc pubsub channel to send back a response from a request received over a stream. Using a stream for the response is overkill because we want this to be ephemeral.
@bbaldino I'll consider it, please submit a PR.
Thanks @djc. Opened https://github.com/djc/bb8/pull/159
First of all thank you for the recent update to bb8 :-)
I can never turn a conn in into a pubsub connection calling
into_pubsub
for some reason. Have you had a chance to have a look pubsub with redis ?From redis