Jedis Pub/Sub doesn't allow to subscribe more than once other than sequentially

[marcosnils]

Current Pub/Sub implementation is blocking and doesn't allow the same connection to subscribe to more than one channel in a nice and friendly way. The only way of achieving it now is by doing some logic in the pubsub listener methods which is not intuitive and straightforward.

Some observations have been discussed here already: https://github.com/xetorthio/jedis/issues/996#issuecomment-104432661. The idea of this issue is to look for better implementations so Jedis Pub/Sub can be something beautiful to use

Suggestions are welcome!

[xetorthio]

@DivineTraube @marcosnils this PR by @smparkes solves this issue in #196 by synchronizing the methods. I was trying to think about a different solution (hopefully better). But so far I've been unable to come up with another "simple enough" solution. Anything comes to your mind?

[itugs]

@xetorthio @marcosnils I checked this issue. The problem is contamination of output stream buffer. I made PR(https://github.com/xetorthio/jedis/pull/998) with investigation log.

Please check it.

[xetorthio]

Thanks @itugs! I would say that your PR is more related to #996 Lets use this issue to discuss other possible APIs for PubSub

[marcosnils]

Exactly!, Despite the fact that it fixes outputbuffer poisoning, it doesn't fixes the multiple subscribe on a JedisPubSub.

[itugs]

@marcosnils Multiple subscribe on a single JedisPubSub is possible if it is made by sequentially. Maybe do I missed some point?

[HeartSaVioR]

@itugs Maybe it means that multi-thread try to subscribe.

[itugs]

@HeartSaVioR Oh, I see. It's same as Jedis.

[HeartSaVioR]

@marcosnils Seems like we can change title to narrow boundary to "multi-threaded" since #998 resolves "other thread (sequentially) cannot request to subscribe more channel while connection is being subscribed".

[DivineTraube]

Suggestion for a new thread-safe PubSub API: https://github.com/xetorthio/jedis/issues/996#issuecomment-104607823

[marcosnils]

@HeartSaVioR title updated.

[Unbr8kbal]

Hi Guys,

I'm up against this issue in a project of mine. Has there been any progress in this? Is anybody assigned to this?

I'm more then happy to help with code or the whole idea, however will need some guidance since i feel like it's a fairly big change.

Thanks

[kaka2507]

I have some changes to adapt this purpose at here: https://github.com/kak2/jedis. And I have used this on my own project. I have already pulled request at https://github.com/xetorthio/jedis/pull/1186 @Unbr8kbal : Could you look and review my code? We can discussion about it more.

[Unbr8kbal]

@kak2 : Open source is greatly appreciated, and you've wrote more then me i haven't even started however, this requires a complete re-write to remove the thread blocking stuff, simple adding some timeout's won't be enough, I could only image not being the main contributor and not know anything about jedis, that the way they handle connections to jedis pubsub will have to change, something like, a pool thread, and threads listening on the subscribes channels since that's where the thread blocking is occurring.

Anybody please feel free to correct me if i'm wrong, this was just my assessment when using it.

[werkt]

I commented on the original PR for aacd1d77d8, and this thread seems dead as well, but I have done the same synchronization mechanism, available without modification of the jedis library through subclassing of JedisPubSub at 2.9.0. Every release since that version contains the flush modification change which breaks that solution, but are obviously desirable due to bugfixes.

I plan to PR a revert of aacd1d77d8, which makes no sense given the only users of that method are the subscriber process implementations. Thoughts?

[github-actions[bot]]

This issue is marked stale. It will be closed in 30 days if it is not updated.