Logstash refuses to start when 3 or more rabbitmq outputs are used. (message=>"The error reported is: \n)

logstash 2.2.2
logstash-output-rabbitmq (3.0.7)

After upgrading to logstash 2.2.0 and updating all plugins, my instance of logstash is refusing to start.

The logstash log only contains:
{:timestamp=>"2016-02-22T09:39:49.413000-0800", :message=>"The error reported is: \n "}

Running config test yields:
[root@bombay conf.d]# service logstash configtest
The error reported is:

After spending some time debugging, I've tracked the issue back to the rabbitmq-output plugin. (The output section of my logstash configuration file is at the end of this post.)

My configuration has 4 separate rabbitmq outputs. Each of these outputs works on it's own (ie. I removed the other 3 rabbitmq outputs). I also tested every permutation using 2 out out 4 outputs and had no issues. However, as soon as I add a third rabbitmq output, I get the error messages above and am unable to start logstash.

logstash.conf output section

output {

if [alert_source] == "u2json" {
rabbitmq {
exchange => 'snort_events_ex'
exchange_type => 'direct'
host => '127.0.0.1'
key => 'snort_events'
vhost => '/sock'
user => 'logstash'
password => 'sekret'
}
}

if [alert_source] in ["snort","repsm"] or "udp_syslog" in [tags] {
rabbitmq {
exchange => 'ids_alerts_ex'
exchange_type => 'direct'
host => '127.0.0.1'
key => 'ids_alerts'
vhost => '/sock'
user => 'logstash'
password => 'sekret'
}
}

if [dhcp_source] == "standard" or [dhcp_source] == "infoblox" {
rabbitmq {
exchange => 'dhcp_logs_ex'
exchange_type => 'direct'
host => '127.0.0.1'
key => 'dhcp_logs'
vhost => '/sock'
user => 'logstash'
password => 'sekret'
}
}

if "infoblox_audit" in [tags] {
rabbitmq {
exchange => 'infoblox_audit_ex'
exchange_type => 'direct'
host => '127.0.0.1'
key => 'infoblox_audit'
vhost => '/sock'
user => 'logstash'
password => 'sekret'
}
}

}

For anyone else running into this, there is an open github issue:

That's strange. I have 8 outputs to RabbitMQ from one server with no issue. Although, it might be because they are separated into 8 different configuration files. I've never tried having them in one. You could possibly try separating them. I don't think it matters that they are in the same file or not. It should still grab them based on your if statements. I remember messing up on an if statement for one of the 8 configurations and everything flooded into the single one as well as going to their individual outputs.

Could be the new pipeline / multi thread architecture, how many pipeline workers did you set?