Redis Pub/Sub Messaging for a social Application
554 views
Skip to first unread message
Mohammad Habbab
Jun 30, 2012, 3:09:18 PM6/30/12
to servic...@googlegroups.com
Hey There,
I'm working on an application that involves multiple clients connecting to a redis server via web-service .. A Person (pA) following a set of people F(pA) = {pB,pC,...}. He/She will check periodically for new comments posted by the people they follow. I use C# Redis library on github. If I were to use redis Pub/Sub subscriptions .. pA's thread would have to block after subscribing to his Set F(A) which leaves me with an un-usable client-object. [We're planning to use a Document Store as part of the infrastructure too, Raven-DB to be specific, if that information is helpful in anyway]. With an unpredictable amount of users logged into the system how would i manage all the objects that blocked? I do feel that pub/sub is not the best solution for this problem due to the complexity of managing all clients objects (one foreach client). I'm a Newbie here (in redis domain, and in NoSQL movement in general :) ) so i appreciate every possible help !
Thanx in advance, Cheers !
I'm working on an application that involves multiple clients connecting to a redis server via web-service .. A Person (pA) following a set of people F(pA) = {pB,pC,...}. He/She will check periodically for new comments posted by the people they follow. I use C# Redis library on github. If I were to use redis Pub/Sub subscriptions .. pA's thread would have to block after subscribing to his Set F(A) which leaves me with an un-usable client-object. [We're planning to use a Document Store as part of the infrastructure too, Raven-DB to be specific, if that information is helpful in anyway]. With an unpredictable amount of users logged into the system how would i manage all the objects that blocked? I do feel that pub/sub is not the best solution for this problem due to the complexity of managing all clients objects (one foreach client). I'm a Newbie here (in redis domain, and in NoSQL movement in general :) ) so i appreciate every possible help !
Thanx in advance, Cheers !
Demis Bellot
Jun 30, 2012, 3:27:00 PM6/30/12
to servic...@googlegroups.com
I would use a single blocking Pub/Sub subscription for all events when possible.
See the implementation of RedisMqServer for an example:
Mohammad Habbab
Jun 30, 2012, 4:41:35 PM6/30/12
to servic...@googlegroups.com
Thank you very much for the fast response Demis !
Louis Haußknecht
Jul 2, 2012, 12:39:14 AM7/2/12
to servic...@googlegroups.com
Another option is to use notifications in RavenDB. This is an upcomming feature and is based on SignalR.
See:
Demis Bellot
Jul 2, 2012, 1:20:21 AM7/2/12
to servic...@googlegroups.com
Sure though handling multiple concurrent connections as done in Pub/Sub in an async event-loop like Redis is its bread and butter - I'd don't expect Raven to handle anywhere near the number of concurrent connections as a redis server instance.
I should also add that marc.gravell's Booksleeve redis client should also be considered if you want to maintain multiple different Pub/Sub subscriptions with very few threads.
Louis Haußknecht
Jul 2, 2012, 1:49:39 AM7/2/12
to servic...@googlegroups.com
Sure. Just wanted to throw another option in the mix.
Am 02.07.2012 07:20 schrieb "Demis Bellot" <demis....@gmail.com>:
Mohammad Habbab
Jul 2, 2012, 4:56:11 AM7/2/12
to servic...@googlegroups.com
Demis, thanx for pointing out the BookSleeve library .. will try it !
Louis, Raven notification concept is a great thing indeed. I guess it will fit perfectly into the solution of other requirements i have :)
Louis, Raven notification concept is a great thing indeed. I guess it will fit perfectly into the solution of other requirements i have :)
Reply all
Reply to author
Forward
0 new messages