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.
