Failed connect to address "localhost", 8000
decaz opened this issue · 3 comments
I'm using RabbitMQ 3.7.2 and getting the following error:
2017-12-23 19:42:20.351 [error] <0.2068.0> STOMP error frame sent:
Message: access_refused
Detail: "ACCESS_REFUSED - access to topic 'test' in exchange 'exchange' in vhost 'vhost' refused for user 'user', backend rabbit_auth_backend_http returned an error: {failed_connect,\n
...\n"
Server private detail: none
2017-12-23 19:42:23.468 [error] <0.2123.0> access to topic 'test' in exchange 'exchange' in vhost 'vhost' refused for user 'user', backend rabbit_auth_backend_http returned an error: {failed_connect,[{to_address,{"localhost",8000}},{inet,[i
net],econnrefused}]} 2017-12-23 19:42:23.469 [error] <0.2123.0> Channel error on connection <0.2113.0> (172.18.0.1:52446 -> 172.18.0.4:15671, vhost: 'vhost', user: 'user'), channel 1:
operation queue.bind caused a channel exception access_refused: access to topic 'test' in exchange 'exchange' in vhost 'vhost' refused for user 'user', backend rabbit_auth_backend_http returned an error: {failed_connect,
[{to_address,
{"localhost",
8000}},
{inet,
[inet],
econnrefused}]}
I think that "localhost:8000" is from PROJECT_ENV which is defined in Makefile and can't be overwritten by the configuration file:
auth_backends.1 = internal
auth_backends.2 = http
auth_http.http_method = post
auth_http.user_path = http://some_url
auth_http.vhost_path = http://some_url
auth_http.resource_path = http://some_url
Thank you for your time.
Team RabbitMQ uses GitHub issues for specific actionable items engineers can work on. This assumes two things:
- GitHub issues are not used for questions, investigations, root cause analysis, discussions of potential issues, etc (as defined by this team)
- We have a certain amount of information to work with
We get at least a dozen of questions through various venues every single day, often quite light on details.
At that rate GitHub issues can very quickly turn into a something impossible to navigate and make sense of even for our team. Because of that questions, investigations, root cause analysis, discussions of potential features are all considered to be mailing list material by our team. Please post this to rabbitmq-users.
Getting all the details necessary to reproduce an issue, make a conclusion or even form a hypothesis about what's happening can take a fair amount of time. Our team is multiple orders of magnitude smaller than the RabbitMQ community. Please help others help you by providing a way to reproduce the behavior you're
observing, or at least sharing as much relevant information as possible on the list:
- Server, client library and plugin (if applicable) versions used
- Server logs
- A code example or terminal transcript that can be used to reproduce
- Full exception stack traces (not a single line message)
rabbitmqctl status(and, if possible,rabbitmqctl environmentoutput)- Other relevant things about the environment and workload, e.g. a traffic capture
Feel free to edit out hostnames and other potentially sensitive information.
When/if we have enough details and evidence we'd be happy to file a new issue.
Thank you.
@decaz it is not hardcoded. PROJECT_ENV only provides defaults. We tested 3.7.2 multiple times against 2 example apps that use different ports. Please keep questions to the mailing list.
RabbitMQ configuration guide contains a section about config file verification, most importantly for this question whether the config file was loaded from the path you expect/or at all.