4 ms·
We use listen notify extensively and it is great. The things it lacks most for us is guaranteed single recipient. All subscribers get all notifications which le
by airocker 2y ago
We use listen notify extensively and it is great. The things it lacks most for us is guaranteed single recipient. All subscribers get all notifications which leads to problems in determining who should act on the message n our case.
- m11a 2y agoCould use the notify to awake, and then the worker needs to lock the job row? Whichever worker gets the lock, acts on the message
- airocker 2y agoThats exactly what we do but taking a lock takes 1 RTT to the database which means about 100ms. it limits the number of events receivers can handle. IF you have too many events, receivers will be just trying to take a lock most of the time.
- jeeybee 2y agoOf my head, you could attach a uuid or sequence number to the emitted event. Then based on the uuid or sequence you can let one or the other event consumer pick? Ex. you have two consumers, if the sequence number is odd, A picks it, if its even B picks.
- collingreen 2y agoWithout more logic than this does this mean any workers that are busy or down mean you lose jobs?
- airocker 2y agoWe use a garbage collector to error restart if a job is not served within a specified amount of time.
- airocker 2y agoGreat observation, I wrote a little wrongly. What we want ideally is guaranteed delivery to one random free worker. Uuid strategy is better than locking but this could mean that if one worker gets a longer job, all the others on this worker are delayed even if another worker is free.
- dopp0 2y agoI think this concept you mentioned would be called sharding? It's kinda required for apache Kafka and others.
- LunaSea 2y agoWouldn't it be possible for you to lose jobs if no subscriber is listening?
- airocker 2y agoWe use a garbage collector to error restart if a job is not served within a specified amount of time.