The on(message => $channel => ...) API is not going to be part of
Mojo::Redis2. It will just be on(message => sub { my ($self, $message,
$channel) = @_ }); The reason for that is to have a consistent API. (on()
is already defined in Mojo::EventEmitter)
And yes, it will only have one connection to the Redis server pr. $redis
object, even though you do $redis->subscribe("channel:$_") for 1..10000;
I'm planning to have one connection for the pubsub
<http://redis.io/commands#pubsub> commands, a new connection when you call
blpop,
brpop, brpoplpush <http://redis.io/commands#list>, and one connection for
everything else. The reason for creating a new connection on each blpop(),
brpop(), brpoplpush <http://redis.io/commands#list>() is that they are
blocking on the server side.
On Saturday, June 28, 2014 2:12:01 AM UTC+2, Daniel Mantovani wrote:
>
> Yes it absolutly matters, I need a different channel per connected
> websocket
>
> So if I understood correctly inside my websocket route I could write
> something like:
>
> my $applianceid = ... (some unique identifier for each appliance, I get it
> from a custom header)
> my $redis = Mojo::Redis2->new;
> $redis->on(message => "myapp:$applianceid", sub {
> my ($rself, $msg) = @_;
> .....
> do something with the received redis msg
> .....
> $tx->send($something); # use my transaction object to send some data to
> my connected appliance
>
> etc
>
> });
> ...
>
> and still use just one redis client despite I may have thousands of
> websocket clients connected and subscribed to different channels
> ("myapp:$applianceid")?
>
> In this case I think the solution would be perfect, I don´t care using
> one extra redis client for publishing, that I guess I will be able to share
> among all websockets.
>
> So at the end of the day I will be using just two redis clients per toad
> when running on hypnotoad... is that right or I missunderstood?
>
>
> El viernes, 27 de junio de 2014 10:11:52 UTC-3, Jan Henning Thorsen
> escribió:
>>
>> I had some typos:
>> I meant subscribing to "foo" and then "bar". (not sure if that matters
>> for the example though)
>> Also the $old comments should be "now there is two connections to the
>> Redis database".
>>
>> On Friday, June 27, 2014 3:09:35 PM UTC+2, Jan Henning Thorsen wrote:
>>>
>>> Mojo::Redis2 can (or at least it will be able to) (p)subscribe multiple
>>> times, using just one connection. I will try to illustrate the difference
>>> to be sure I understand you:
>>>
>>> my $old = Mojo::Redis->new;
>>> my $s1 = $old->subscribe("foo");
>>> my $s2 = $old->subscribe("foo");
>>> # now you two connections to the Redis database
>>>
>>> my $new = Mojo::Redis2->new;
>>> $new->subscribe("foo");
>>> $new->subscribe("foo");
>>> # still just one connection to the Redis database, since Mojo::Redis2
>>> is re-using the same subscribe connection
>>>
>>> Unfortunatly, issuing (P)SUBSCRIBE will only allow "subscribe like"
>>> commands <http://redis.io/commands/subscribe>, which renders any Redis
>>> module unable to do PUBLISH and SUBSCRIBE over the same database
>>> connection.
>>>
>>> On Friday, June 27, 2014 3:00:20 PM UTC+2, Daniel Mantovani wrote:
>>>>
>>>> Hi Jan, I´ve using Mojo::Redis and find it very convenient as the
>>>> glue that allows to comunicate non-blocking among different processes
>>>> (toads) when running hypnotoad (using subscribe and publish, just as the
>>>> "Websocket example" in the module's synopsis).
>>>>
>>>> Something I would suggest for you to take a look is related to the
>>>> scalling of simultaneos redis clients needed for a realtime app. I
>>>> understand that you would need a dedicated "subscribe" client plus a
>>>> "publish" per connected websocket, if you follow the mencioned example.
>>>>
>>>> That could be a problem depending on the nature of your app. In my
>>>> case I was working on an app that will have thousand of appliances with
>>>> very low traffic but allways on, so I ended up using Mojo ::Redis with
>>>> something like a psubscribe "app:*" client per toad, and just one
>>>> publishing client (probably blocking) also per toad (Anyway I'm not sure
>>>> how this solution will scale in the field, we will see in the followings
>>>> months probably).
>>>>
>>>> Hope you can add to Mojo::Redis2 some kind of support for a solution
>>>> that allows to share psubscribe redis connections among many users on a
>>>> single process or toad.
>>>>
>>>> BR,
>>>> Daniel
>>>>
>>>> El jueves, 26 de junio de 2014 09:24:00 UTC-3, Jan Henning Thorsen
>>>> escribió:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to make a new Redis driver for Mojolicious that makes
>>>>> sense. Me and Marcus Ramberg has been maintaining Mojo::Redis, but I see
>>>>> some issues with the API:
>>>>>
>>>>> * No blocking support
>>>>> * Really poor error handling
>>>>> * Trying to be clever with BLPOP and SUBSCRIBE, using an overloaded
>>>>> on() method
>>>>> * Some really weird bugs that that I can't seem to figure out (Got one
>>>>> project at work which fail on random)
>>>>> * Public methods that is confusing: connect(), connected(),
>>>>> disconnect() (?), protocol_redis() and timeout()
>>>>>
>>>>> So now I want to make a new version that Makes Sense (tm). The project
>>>>> is currently just a branch under the old mojo-redis repo:
>>>>> https://github.com/marcusramberg/mojo-redis/tree/v2
>>>>>
>>>>>
>>>>> # What I need help with
>>>>>
>>>>> 1. Look if the API makes sense.
>>>>> 2. Look at the code to see if it makes sense.
>>>>> 3. Tell me when something is awkward or plain wrong.
>>>>> 4. Figure out if ->execute() makes sense and/or if it could be replace
>>>>> with something "nicer"
>>>>> I often do many commands at once, so what execute() fix is this:
>>>>>
>>>>> Mojo::IOLoop->delay(
>>>>> sub {
>>>>> my ($delay) = @_;
>>>>> $redis->get(foo => $delay->begin);
>>>>> $redis->get(bar => $delay->begin);
>>>>> $redis->get(baz => $delay->begin);
>>>>> },
>>>>> sub {
>>>>> my ($delay, $foo_err, $foo, $bar_err, $bar, $baz_err, $baz) = @_;
>>>>> # ^ ONE MILLION ARGUMENTS!!
>>>>> },
>>>>> );
>>>>>
>>>>> 5. Does it make sense for one $redis object to have multiple
>>>>> connections to the database?
>>>>> This is one of the things I built in to the new module: blpop(),
>>>>> subscribe(), ... will make a new connection to the database instead of
>>>>> user
>>>>> of the module need to remember which method is blocking or take over the
>>>>> connection. But does it really make sense?
>>>>>
>>>>> 6. I need a method for UNSUBSCRIBE
>>>>> The module inherit from Mojo::EventEmitter, so I can't really use the
>>>>> unsubscribe() method to UNSUBSCRIBE from channels. Got an idea for an
>>>>> alternative way, or some fancy hack to make it work with unsubscribe()?
>>>>> I've been considering $redis->unsubscribe(message => $channel_name); but
>>>>> it
>>>>> kind of breaks the signature.
>>>>>
>>>>> 7. Do Mojo::Redis2 really need "encoding" attribute?
>>>>> Why isn't this always UTF-8? I don't get the encoding attribute, but I
>>>>> kept it because of legacy from the other redis modules.
>>>>>
>>>>> 8. What do you think about pipelined()?
>>>>> Please have a look at
>>>>> https://github.com/marcusramberg/mojo-redis/blob/v2/t/pipelined.t
>>>>>
>>>>> 9. ???
>>>>>
>>>>>
>>>>> # What is done (might be redesigned though)
>>>>>
>>>>> * I got basic redis methods working blocking and non-blocking
>>>>> * I got (p)subscribe methods working and (p)message events
>>>>> * I got pipelining working.
>>>>>
>>>>
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
