Thanks a lot, Daniel! I will use your ideas related to using Redis queues to build robust database client, spreading requests across many workers in the pool. That is wonderful idea!
But for caching i need some other scheme: One master process that will update Cache::FastMmap cache on receiving update records from Redis subscribrion. A lot of workers processes that will read Cache::FastMmap and replies to user requests. In Mojolicious it is obvious how to do some processing in workers, but... how to use the main process to do some background tasks in application context, but not to process any user requests? Thank you for your response again! 2017-04-18 3:14 GMT+03:00 Daniel Mantovani <[email protected]>: > Hi, > > I am not sure I fully understand your question, but if you already have > Redis and you want that only one spawned process receives an event, and > that on next event next spawned process do the same, you could use queue > commands from Redis for that (instead of PUB/SUB that would be addressed to > all childs that are listening to the published key). > > So your "publisher" should send events to a queue using for instance, > RPUSH somelist someevent, and your mojo app should be listening with BLPOP > somelist 0 (0 means indefinitelly). > > For the listening inside your Mojo app, you should take a look on > Mojo::Redis2. > > Just as an example, you could do something like: > > use Mojolicious::Lite; > use Mojo::Redis2; > > helper redis => sub { shift->stash->{redis} ||= Mojo::Redis2->new; }; > > Mojo::IOLoop->next_tick(sub { > my $c = app->build_controller; > my $element_get; > $element_get = sub { > $c->redis->blpop('myqueue', 0, sub { > my ($self, $err, $res) = @_; > $c->app->log->info("Worker $$ received an event from $res->[0]: > $res->[1]"); > $element_get->(); # get next element from 'myqueue' > }); > }; > $c->app->log->info("Worker $$ started"); > $element_get->(); > }); > > get '/' => {text => 'Hello Word!!!'}; > > app->start; > > That way, you will not block the ioloop, and only one child will take next > event. > The child that gets the event should rotate just because it is the way > Redis queues work. > As stated in the cookbook, you can use "next_tick" to run code whenever a > new process is spawned. > > You can check this code running it with hypnotoad and opening on another > terminal a redis-cli instance and sending strings to the 'myqueue' list, > like: > > > rpush myqueue whatever "whatever 2" "whatever 3" "whatever 4" "whatever > 5" > > Hope this helps, > > > El jueves, 13 de abril de 2017, 10:46:24 (UTC-3), Ганц Аккерман escribió: >> >> Hello! >> >> In my hypnotoad application i want to update cache (Cache::FastMmap) on >> some event, which fired by Redis subscription. >> But now i have to subscribe on Redis events and update local perl hash in >> every spawned process, which at the same time serve users requests. >> How to use only one process to support actualized cache state, so all >> workers can read information from that cache, but not update it? >> >> I think, i need to subscribe on Redis events and maintain cache in the >> main process, but Mojolicious Cookbook tell me that is impossible (IOLoop >> not running in the main process). >> I think Minion is not suitable for me because we use only Redis+MariaDB >> in our production environments and i cant install PostgreSQL for Minion. >> So i m in doubt, how to operate cache in traditional way (one auxiliary >> updater process - many frontend processes-readers). >> >> Tell me please, whether is it possible in Mojolicious application running >> on Mojolicious::Server::Prefork/hypnotoad? >> >> Thank you! >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Mojolicious" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/mojolicious/djY6qVG1sTo/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/mojolicious. > For more options, visit https://groups.google.com/d/optout. > -- 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 https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
