RabbitMQ QueueDeclare times out

[pantonis]

Once I switch on my dev pc and try to declare a queue I get the following exception.

   at RabbitMQ.Util.BlockingCell.GetValue(TimeSpan timeout)
   at RabbitMQ.Client.Impl.SimpleBlockingRpcContinuation.GetReply(TimeSpan timeout)
   at RabbitMQ.Client.Impl.ModelBase.QueueDeclare(String queue, Boolean passive, Boolean durable, Boolean exclusive, Boolean autoDelete, IDictionary`2 arguments)
   at RabbitMQ.Client.Impl.AutorecoveringModel.QueueDeclare(String queue, Boolean durable, Boolean exclusive, Boolean autoDelete, IDictionary`2 arguments)
   at Test.Proj.InitBrokerConsumer() in C:\SourceControl\Test\src\Test.Proj\MyMessageService.cs:line 105

After I restart RabbitMQ Service everything is back as normal. No exceptions.

I am using: RabbitMQ 3.6.12 Erlang 20.0 RabbitMQ-Net: 5.0.1 Windows 10 Version 1703 (OS Build 15063.674) Plugins: [e] amqp_client 3.6.12 [e] cowboy 1.0.4 [e] cowlib 1.0.2 [ ] rabbitmq_amqp1_0 3.6.12 [ ] rabbitmq_auth_backend_ldap 3.6.12 [ ] rabbitmq_auth_mechanism_ssl 3.6.12 [ ] rabbitmq_consistent_hash_exchange 3.6.12 [ ] rabbitmq_event_exchange 3.6.12 [ ] rabbitmq_federation 3.6.12 [ ] rabbitmq_federation_management 3.6.12 [ ] rabbitmq_jms_topic_exchange 3.6.12 [E] rabbitmq_management 3.6.12 [e] rabbitmq_management_agent 3.6.12 [ ] rabbitmq_management_visualiser 3.6.12 [ ] rabbitmq_mqtt 3.6.12 [E] rabbitmq_recent_history_exchange 3.6.12 [ ] rabbitmq_sharding 3.6.12 [ ] rabbitmq_shovel 3.6.12 [ ] rabbitmq_shovel_management 3.6.12 [e] rabbitmq_stomp 3.6.12 [ ] rabbitmq_top 3.6.12 [ ] rabbitmq_tracing 3.6.12 [ ] rabbitmq_trust_store 3.6.12 [e] rabbitmq_web_dispatch 3.6.12 [ ] rabbitmq_web_mqtt 3.6.12 [ ] rabbitmq_web_mqtt_examples 3.6.12 [E] rabbitmq_web_stomp 3.6.12 [ ] rabbitmq_web_stomp_examples 3.6.12 [e] sockjs 0.3.4

This is the code that has the problem...

channel.ExchangeDeclare(exchange: settings.ExchangeName, type: settings.ExchangeType, durable: true, autoDelete: false, arguments: null);
channel.QueueDeclare(queue: settings.QueueName, durable: true, exclusive: false, autoDelete: false, arguments: null);

For the server logs if you need them just send me an email address to send them on as I cannot publish them here.

Thanks

[michaelklishin]

Thank you for your time.

Team RabbitMQ uses GitHub issues for specific actionable items engineers can work on. This assumes two things:

1. GitHub issues are not used for questions, investigations, root cause analysis, discussions of potential issues, etc (as defined by this team)
2. 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 environment output)
• 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.

[lukebakken]

@pantonis - check out this mailing list thread

[michaelklishin]

There can be all kinds of reasons for why client operations time out. Some are natural operational events, e.g. resource alarms on the node being in effect. Server logs and as other metrics are critically important when investigating such cases.

The thread above is just one possible example.