and I had bluebird promises representig message processing there, and if someone edited a message while it was still being processed, I cancelled the promise and started processing again.
In 3.x I decided to have as little state in memory as possible; I still need a way to cancel message processing.
My first thought was to store only the promises in memory, rest data in redis, and use pub-sub to broadcasr cancellation event to other instances (in case it would be running in a cluster).
But, I think I'll go for something more subtle -- each time a message is processed, set an uuid on the data. If it changes, message was edited, and job should cancel itself.
What do you think?
Long story short, is setting new uuid on update good way of notifying about update?
so in the first one you're storing whole promises, rest data and emitting cancelation events, and in the second one you store all the data and add uuid to all of it?
Обсуждают сегодня