Hacker News Reader

Comment by airocker | Hacker News Reader

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.

View on HN

Could use the notify to awake, and then the worker needs to lock the job row? Whichever worker gets the lock, acts on the message

Thats 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.

Of 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.

Without more logic than this does this mean any workers that are busy or down mean you lose jobs?

We use a garbage collector to error restart if a job is not served within a specified amount of time.

Great 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.

I think this concept you mentioned would be called sharding? It's kinda required for apache Kafka and others.

Wouldn't it be possible for you to lose jobs if no subscriber is listening?

We use a garbage collector to error restart if a job is not served within a specified amount of time.

Reply on news.ycombinator.com