Perfect then, thanks Jan
El domingo, 29 de junio de 2014 03:50:09 UTC-3, Jan Henning Thorsen
escribió:
>
> 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.
