[rabbitmq-discuss] Channels closed unexpectedly in Java client

Wed Sep 14 14:39:05 BST 2011

On Wed, Sep 14, 2011 at 11:02:49AM +0100, Matthew Sackman wrote:
> Wow - I'd not considered that file systems these days would still have
> such limits... In my own testing a little while ago, I found that JFS
> had the best performance for my hardware when running Rabbit, but I
> didn't do any huge scaling tests so I wouldn't be surprised if that has
> even lower limits for such things.

...except it doesn't. I've just written a test to, erm, test this:

-module(test).
-compile([export_all]).

-include_lib("amqp_client/include/amqp_client.hrl").

loadsa_queues() ->
    {ok, Conn} = amqp_connection:start(#amqp_params_network{}),
    {ok, Chan} = amqp_connection:open_channel(Conn),
    Method = #'basic.publish'{},
    Content = #amqp_msg { props = #'P_basic'{ delivery_mode = 2 },
                          payload = <<0:8>> },
    [begin
         #'queue.declare_ok'{ queue = Q } =
             amqp_channel:call(Chan, #'queue.declare'{durable = true, exclusive = true}),
         amqp_channel:cast(Chan, Method#'basic.publish'{ routing_key = Q }, Content)
     end || _ <- lists:seq(1,100000)],
    amqp_connection:close(Conn).

The reason for doing the publish is that the queue creates its directory
lazily, so if you don't do the publish, the directory will never be
created, so you won't stress the filesystem.

So I ran that, at the same time as some
rabbitmqctl list_queues | wc -l
and
watch "ls /home/matthew/ssd/rabbitmq-rabbit-mnesia/queues/|wc -l"
and sure enough, it happily got up to the 100,000 queues I'd asked for.

Matthew