[rabbitmq-discuss] Clustered queues and bindings dropped when sending large messages

Tue Oct 25 11:54:06 BST 2011

It does take more than 60 seconds yes.
For testing we use some remote virtual machines which are a bit
sluggish (read: horribly slow) on the I/O.
But the nodes already get partitioned in about 15-20 seconds which
doesn't really match the default earliest possibility of 45 seconds.

Next to this, there is no way that the cluster will try to
re-partition after such incident?

- Irmo

Any reason why it won't re-partition after the message is finally delivered

On Tue, Oct 25, 2011 at 12:36 PM, Simon MacMullen <simon at rabbitmq.com> wrote:
> On 25/10/11 11:21, Simon MacMullen wrote:
>>
>> That sounds almost like the cluster is getting partitioned
>
> Matthias points out that this can indeed happen, if transmitting one message
> across the cluster takes longer than the configured ticktime (see
> net_ticktime at http://www.erlang.org/doc/man/kernel_app.html). But by
> default that's 60s, and we don't change it. Is your cluster that slow?
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, VMware
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>