If everything is working this is fine. Process reaping sounds scary but isn’t really. Basically when a child process exits, as many often due in normal course of operation, it still has a pid and entry in the kernel process table. Those processes that no longer do anything but are still technically there are called zombie processes. Reaping is just what it’s called when those processes get fully removed and cleaned out. Now if the process reaper was reclaiming processes it shouldn’t or child processes are dying prematurely thus breaking things, that would be a problem, but since it is all working it sounds like it’s just going about things normally so I wouldn’t worry.
Just wanted to add a line in case others run into issues with using rabbitmq on fly (read: with docker) - since rabbitmq data storage paths are based on hostname and fly will change it per deployment, you should set the MNESIA_DIR as part of an environment variable:
@jbergstroem@franzwarning Were you folks successful in your RabbitMQ deploy/management? I’m about to roll out a Rabbit service on fly and wondered if you folks ran into any gotchas or what your setup looks like now.
It all seems fine as I deploy the app. I am also able to access the web based rabbitmq admin using app-hostname:5672 signing in with the user credentials I created. However, I can’t seem to connect to the queue via the standard connection uri - amqp://user:pass@host:port/.
I get this error when I try connecting from the my code base:
ERROR/MainProcess] consumer: Cannot connect to amqp://user:**@fly-app-hostname.fly.dev:5672//: timed out.
testing with pika throws :
pika.exceptions.IncompatibleProtocolError: StreamLostError: ("Stream connection lost: ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None)",)
I wonder if I might me missing something else here
might you know the issue here, happens after the server crashed and i redeployed it, removing the mount from fly.toml sections starts the server with no issue