Embedded RabbitMq conficts with already running server
Closed this issue · 6 comments
If a machine already has a running instance of RabbitMq then an attempt to launch embedded RabbitMq would cause an error.
At least a random port should be selected by default to solve this issue somehow.
From your previously reported issue (#28), it seems like you ran into this issue when you were running the JUnit tests and you abruptly stop the test execution, then tried it again and this second time, the RabbitMQ broker wouldn't even start because the previous process was still running, and in this case, you'd prefer to have a random port be assigned so it won't clash with other instances, correct?
If so, i do agree that the code in the tests itself could figure out a random port and instruct the Embedded RabbitMQ library to use such port. However, I don't think it should be up to the library itself to figure out a random port and use that port automatically.
Would you like to give this a try yourself?
I did think about creating a JUnit rule class that can be used to automatically start the Embedded RabbitMQ server, have a single instance available for all unit/integration tests and provide clean/independent "virtual hosts" for each test class to avoid clashes. However, this isn't a priority at this point in time, mostly because writing/maintaining a test-library might not be worth the effort when there will be so many different ways to do achieve the same thing. I'll probably just add sample code to the wiki so that people can copy and customize it.
Actually, no. I've killed all instances of RabbitMQ, and started it through systemd. Embedded RabbitMq runs on the default port and this causes the issue.
A random port for embedded resources is a very common pattern, imho. There is no problem to correctly setup it. An example would be nice, but I suggest to use random port by default.
A random port for embedded resources is a very common pattern, imho.
I've checked the following projects and here are my findings:
- embedded-redis: starts using default Redis port
6379(proof) - embedded-mongo: does start with a random port. (proof)
- embedded-mysql: starts with default mysql port
3310(proof) - embedded-postgres: starts with random port (proof)
From this small sample, it seems like it's both common and not. Got other projects you know of?
In any case, this research is making me lean more towards supporting the random port logic inside the library code instead of the code example/test-support library, however, i still feel iffy about doing this as the default port.
Btw, I'm not sure by when i'll be able to work on this, but if you're interested and have the time, feel free to submit a PR :)
Ok, I admit I was wrong about random ports, but I think implementing this in the library is a great idea.
I think implementing this in the library is a great idea.
Yeah, thanks for bringing this up :)
See PR #30