This makes a new connection on each request:
helper redis = sub { shift-stash-{redis} ||= Mojo::Redis2-new(url =
$redis_server)};
On Saturday, October 4, 2014 2:46:56 AM UTC+2, Daniel Mantovani wrote:
I was trying to handle several subscribe channels with only one redis
client using Mojo::Redis2, but it seems that I'm doing something wrong, I
end up using as many clients as open subscribed channels I have.
Maybe somebody can take a look at this test code and let me know :
https://github.com/dmanto/test-redis-connections.git
Thanks in advance,
El martes, 5 de agosto de 2014 11:04:45 UTC-3, Jan Henning Thorsen
escribió:
I pushed an experimental release to CPAN now:
https://metacpan.org/pod/Mojo::Redis2
-Any- feedback is more than welcome.
On Sunday, June 29, 2014 10:21:28 PM UTC+2, Daniel Mantovani wrote:
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..1;
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
