Meteor Scaling - Redis Oplog [Status: Prod ready]


#606

Feel free to just use getRedisPusher so you won’t have to re-configure your native redis. Yes, this idea can work nicely. I would solve it elegantly like keep all the redis messages in a queue, and then have ability to flush them them, but that would require additional work on the redis-oplog codebase.


#607

@diaconutheodor, Thanks for reply
I was already using getRedisPusher but at the same time I have also namespace on the collection. When there is a namespace it is not getting pushed to redis and when I remove namespace then it is working fine.
How to deal with it when we have namespace ??
I have namespace something like

Collection.configureRedisOplog({
    mutation(options, { event, selector, modifier, doc }) {
      var companyId = selector && selector.companyId;
      if (event === Events.INSERT) {
        companyId = doc.companyId;
      }
      Object.assign(options, {
        namespace: `company::${companyId}`
      });
    })
})

My request to correct / update outside mutation documentation w.r.t to getRedisPusher usage because getRedisPusher is a function and not a object, I think it should be

getRedisPusher().publish('tasks', EJSON.stringify({ [RedisPipe.DOC]: {_id: taskId}, [RedisPipe.EVENT]: Events.UPDATE, [RedisPipe.FIELDS]: ['status'] });


#608

I see there hasn’t been much activity in the repo lately, with a few outstanding PRs that could be very useful for us to get merged in (like the monkey patching PR and hooking into core PR). As we seem to be in the mood for helping mup ELB along, is there something we could do to spur on this project too? :wink:


#609

Yes ofcourse, I totally understand. I will take care this week (most likely Friday, as I have it fully booked for open-source!)

Thank you for the friendly reminder