RabbitMQ Management UI Fails with ERR_EMPTY_RESPONSE when Warm Standby Replication is active

Products

• RabbitMQ

Issue/Introduction

Users on RabbitMQ 4.0.x may encounter the following behavior when attempting to publish messages through the RabbitMQ Management UI or HTTP API:

• Browser Error: The web interface returns net::ERR_EMPTY_RESPONSE.
  
  
• Server Logs: The RabbitMQ logs record an internal Erlang crash with a function_clause exception.
  
  
• Network Behavior: The server abruptly severs the network socket during the publish attempt.
  
  
• Environment: The issue occurs specifically when Warm Standby Replication (WSR) is active for the target queue(s).

 

Environment

Rabbit MQ

Cause

This issue is caused by a technical incompatibility between the synchronous HTTP API publishing code path and the Warm Standby Replication (WSR) collection mechanism in early RabbitMQ 4.0.x releases.

• Synchronous Flow: Publishing via the Management UI/HTTP API uses a short-lived internal connection that enables publisher confirms and the mandatory flag. It synchronously awaits a confirmation from the broker.
  
  
• WSR Conflict: When WSR is enabled, RabbitMQ injects an extra routing destination to a special internal stream. The current WSR implementation is optimized for the asynchronous message and confirmation flow used by standard clients (AMQP, MQTT, STOMP).
  
  
• Crash: The system receives a flush command mid-transaction that it cannot safely process under these conditions, leading to an Erlang function_clause exception and a socket reset.

Resolution

Workaround: Use Standard Clients

To avoid this crash, publish messages using a standard AMQP, MQTT, or STOMP client rather than the Management UI. Standard clients use an asynchronous code path that is fully compatible with WSR.

Broadcom highly recommends against using the HTTP API for message publishing in production environments. It should be reserved for development and testing where no other viable option exists.