question: multi server subscriptions publishing same messages

So I have this problem, we are using graphql as our API interface, for subscriptions it uses websockets. We of course want to have multiple servers backing this API. Currently the subscription we have in place receives a rabbit message and then republishes that to the pubsub (websocket). The problem is that with multiple graph servers any of them could pick up the rabbit message.

My solution, is to create a unique queue name for each server so that each one will have it’s own queue. Currently I’m using the hostname to append to the static queue name. the hostname is derived from the docker container sha or whatever… (it’s the default container one), which means it will change if the containers build changes, creating a bunch of subscriptions.

One of my concerns here is that yesterday, and this is weird, 2 of my queues deliverable.subscription and deliverable.subscription.1234 (or whatever, similar), both seemed to be picked up by my handler, and that was causing duplicate publications.

I can’t nuke all the subscriptions because celery also has subscriptions (we’re migrating away from a django app).

my proposed solution is, to delete the previous via some pattern match, but I have no idea how I’d accomplish that. Can you tell me how I could do that? or do you have a better idea?

P.S. Thanks for all the help/consideration so far, and this project, we were losing messages somewhere and migrating to rascal seems to have solved it.

[xenoterracide]

I’m curious about whether messages can be delivered from the graph server to the browser after restarts.

uh… I’m not certain but I find it highly doubtful with how apollo server subscriptions are implemented. However, they do recommend “production” ready pubsub which I’m not using, but maybe there’s a way to implement a different one for rabbitmq that could do this.

Furthermore, if the server restarted because of a redeploy, it would get a new container sha. Not only would you have to re-establish connections, but you would also have to either consume from the previous queue, or move messages from the previous queue to the new one.

yes, and thinking about it (and the above), and how we’ve implemented things, I think auto-delete is actually a fine solution, the system also polls every minute (little frequent if you ask me, but there are reasons).

[cressie176]

btw, did you use a program to make your diagram?

monodraw