The following is part of a Rabbitmq consumer application that's built as a windows form in visual studio 2013. This form connects to an exchange that was set up in another program and listens for messages sent through one of three routing keys: "info", "error", and "warning". The user chooses which of those routing keys they would like to listen to by checking them on the windows form and then clicking the listen button.
private void listenButton_Click(object sender, EventArgs e)
{
var factory = new ConnectionFactory() { HostName = "localhost" };
using (var connection = factory.CreateConnection())
using (var channel = connection.CreateModel())
{
channel.ExchangeDeclare("direct_logs", "direct");
var queueName = channel.QueueDeclare().QueueName;
if (infoCheckBox.Checked)
{
channel.QueueBind(queueName, "direct_logs", "info");
}
if (errorCheckBox.Checked)
{
channel.QueueBind(queueName, "direct_logs", "error");
}
if (warningCheckBox.Checked)
{
channel.QueueBind(queueName, "direct_logs", "warning");
}
var consumer = new EventingBasicConsumer(channel);
consumer.Received += (model, ea) =>
{
var body = ea.Body;
var message = Encoding.UTF8.GetString(body);
messageTextBox.Text += "\n" + message;
};
channel.BasicConsume(queueName, true, consumer);
}
}
In order to be able to perform the method QueueBind, however, I need queueName. But the program always fails on the line var queueName = channel.QueueDeclare().QueueName;. It always freezes for about 10 seconds and then comes up with a timeout exception. I had almost the exact same code work in a console application. Is there something different that I need to account for when using a windows form? Thanks in advance for your help.
If you're always having RabbitMQ time out on a QueueDeclare, you might just have memory issues with a long-running job. As suggested in this google groups discussion, try running:
rabbitmqctl eval 'rabbit_diagnostics:maybe_stuck().'
This tool just checks if there are any jobs that haven't had any stack trace changes within a certain time window, but can be useful for finding hanging jobs. If something is amiss, you'll get output like:
2017-03-27 13:59:27 There are 269 processes.
2017-03-27 13:59:27 Investigated 9 processes this round, 5000ms to go.
2017-03-27 13:59:28 Investigated 9 processes this round, 4500ms to go.
2017-03-27 13:59:29 Investigated 9 processes this round, 4000ms to go.
2017-03-27 13:59:29 Investigated 9 processes this round, 3500ms to go.
2017-03-27 13:59:30 Investigated 9 processes this round, 3000ms to go.
2017-03-27 13:59:30 Investigated 9 processes this round, 2500ms to go.
2017-03-27 13:59:31 Investigated 9 processes this round, 2000ms to go.
2017-03-27 13:59:31 Investigated 9 processes this round, 1500ms to go.
2017-03-27 13:59:32 Investigated 9 processes this round, 1000ms to go.
2017-03-27 13:59:32 Investigated 9 processes this round, 500ms to go.
2017-03-27 13:59:33 Found 9 suspicious processes.
2017-03-27 13:59:33 [{pid,<10469.54.0>},
{registered_name,user},
{current_stacktrace,
[{user,get_chars,8,[{file,"user.erl"},{line,613}]},
{user,do_io_request,5,
[{file,"user.erl"},{line,183}]},
{user,server_loop,2,[{file,"user.erl"},
etc
I've usually been sucessful in cleaning up suspicious jobs with just a rabbitmqctl stop_app and rabbitmqctl start_app, but you can also kill specific jobs using
rabbitmqctl eval 'erlang:exit(c:pid(0,54,0),kill).'