[rabbitmq-discuss] rabbitmq-discuss Digest, Vol 57, Issue 28
Jose Jimenez Ortiz
j-jimenez at finamex.com.mx
Tue Feb 28 14:56:00 GMT 2012
Hi all,
I installed rabbitmq 2.7.1 and enable Rabbitmq_Management plugin but in the explorer I don't see anything on OVERVIEW panel.
Any idea?
Regards,
-----Mensaje original-----
De: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] En nombre de rabbitmq-discuss-request at lists.rabbitmq.com
Enviado el: Lunes, 27 de Febrero de 2012 06:00
Para: rabbitmq-discuss at lists.rabbitmq.com
Asunto: rabbitmq-discuss Digest, Vol 57, Issue 28
Send rabbitmq-discuss mailing list submissions to
rabbitmq-discuss at lists.rabbitmq.com
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
or, via email, send a message with subject or body 'help' to
rabbitmq-discuss-request at lists.rabbitmq.com
You can reach the person managing the list at
rabbitmq-discuss-owner at lists.rabbitmq.com
When replying, please edit your Subject line so it is more specific than "Re: Contents of rabbitmq-discuss digest..."
Today's Topics:
1. (no subject) (jay nanavati)
2. Apache MINA Integration (Uday Subbarayan)
3. Problem with using rabbitmqctl on EC2 (Codevally)
4. Re: [help] [beginner] server stops sending messages; publish
(in transaction) hangs on commit (Alistair Bayley)
5. dead connection lingers around? (stone)
6. Re: Problems with STOMP & access control (Steve Powell)
7. Re: Unexpected behaviour with STOMP & NACK (Steve Powell)
8. Re: Consumers and exceptions (Jon Hill)
9. Re: Problems with STOMP & access control (Lionel Cons)
10. Re: Ensuring low latency for publishers (Simon MacMullen)
11. Re: STOMP doesn't include the routing-key on MESSAGE frames
(Steve Powell)
12. Re: dead connection lingers around? (Simon MacMullen)
13. Re: ??: Passive queue declaration and channel closure
(Simon MacMullen)
14. Re: Apache MINA Integration (Michael Bridgen)
15. Re: [help] [beginner] server stops sending messages; publish
(in transaction) hangs on commit (Marek Majkowski)
----------------------------------------------------------------------
Message: 1
Date: Sun, 26 Feb 2012 18:45:39 +0000
From: jay nanavati <jaysnanavati at hotmail.co.uk>
Subject: [rabbitmq-discuss] (no subject)
To: <rabbitmq-discuss at lists.rabbitmq.com>
Message-ID: <BAY154-W539870CC6FC7A6D83362DC99680 at phx.gbl>
Content-Type: text/plain; charset="windows-1252"
Hi everyone,
I have followed this guide to setup rabbitMQ for android.http://simonwdixon.wordpress.com/2011/06/03/getting-started-with-rabbitmq-on-android-part-1/
The problem I am facing is On the line mConsumer.connectToRabbitMQ() in the ActivityHome, I have changed it to:
mOutput.append(?\n?+mConsumer.connectToRabbitMQ());
now when I have the wrong server, it prints false as expected however when I have the write server it does not print anything. In fact it does not even print the @string/hello which it should anyways..
The app does not consume messages and I think this could be the reason.. Also I have used loger and found out that the error must be on this method because I can logg before the call however I cannot logg anything after the call.
Any help would be greatly appreciated.. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120226/4bea75c7/attachment.html>
------------------------------
Message: 2
Date: Sun, 26 Feb 2012 12:51:53 -0800 (PST)
From: Uday Subbarayan <uday.subbarayan at yahoo.com>
Subject: [rabbitmq-discuss] Apache MINA Integration
To: "rabbitmq-discuss at lists.rabbitmq.com"
<rabbitmq-discuss at lists.rabbitmq.com>
Message-ID:
<1330289513.57728.YahooMailNeo at web44910.mail.sp1.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi All,
? ? ?Has anyone integrated Apache MINA with Rabbit MQ to publish and receive messages?
Thanks,
-Uday.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120226/55d812e1/attachment-0001.htm>
------------------------------
Message: 3
Date: Sun, 26 Feb 2012 19:00:15 -0800 (PST)
From: Codevally <codevally at gmail.com>
Subject: [rabbitmq-discuss] Problem with using rabbitmqctl on EC2
To: rabbitmq-discuss at lists.rabbitmq.com
Message-ID:
<17970f1d-15cf-42a2-9b5a-f431ffd74a6d at v2g2000vbx.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Experts
I have installed RabbitMQ 2.7.1 on EC2 (host name is ec2test2) and server getting started without any issue.
AMQP 0-9-1 / 0-9 / 0-8
Copyright (C) 2007-2011 VMware, Inc.
Licensed under the MPL. See http://www.rabbitmq.com/
node : rabbit at ec2test2
app descriptor : /app/rabbitmq_server-2.7.1/sbin/../ebin/rabbit.app
home dir : /root
config file(s) : (none)
cookie hash : 4lZvwoYL5ZJbkEiBx9CgDA==
log : /var/log/rabbitmq/rabbit at ec2test2.log
sasl log : /var/log/rabbitmq/rabbit at ec2test2-sasl.log
database dir : /app/rabbitmq-config/lib/rabbitmq/mnesia/
rabbit at ec2test2
erlang version : 5.9
But when I try to use rabbitmqctl, I am getting the below error.
ec2test2:/app/rabbitmq/sbin # sh rabbitmqctl {error_logger,{{2012,2,27},{2,55,8}},"Can't set long node name!
\nPlease check your configuration\n",[]} {error_logger,{{2012,2,27},{2,55,8}},crash_report,[[{initial_call,
{net_kernel,init,['Argument__1']}},{pid,<0.20.0>},{registered_name,[]},
{error_info,{exit,{error,badarg},[{gen_server,init_it,6,
[{file,"gen_server.erl"},{line,313}]},{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,227}]}]}},{ancestors,
[net_sup,kernel_sup,<0.9.0>]},{messages,[]},{links,[<0.17.0>]},
{dictionary,[{longnames,true}]},{trap_exit,true},{status,running},
{heap_size,6765},{stack_size,24},{reductions,2361}],[]]}
Host name is correctly configured and it displays:
ec2test2:/app/rabbitmq/sbin # hostname
ec2test2
ec2test2:/app/rabbitmq/sbin #
Could someone please explain this erroneous behavior?
Thanks.
------------------------------
Message: 4
Date: Mon, 27 Feb 2012 16:37:24 +1300
From: Alistair Bayley <alistair at abayley.org>
Subject: Re: [rabbitmq-discuss] [help] [beginner] server stops sending
messages; publish (in transaction) hangs on commit
To: Simon MacMullen <simon at rabbitmq.com>
Cc: rabbitmq-discuss at lists.rabbitmq.com
Message-ID:
<CAKYODbip9zOg2=7xNukG6oMAGVqZHdU1ibza=5+98xvUTQtzow at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On 25 February 2012 00:38, Simon MacMullen <simon at rabbitmq.com> wrote:
>>
>> OK. Can I have some guidance as to how much memory we should allocate?
>
> This is a real how-long-is-a-piece-of-string question I'm afraid. 512M
> would already be a significant step towards the comfort zone though.
rabbitmqctl report shows a large number of channels (in the thousands) and memory usage seems to correlate with the large number of channels.
I've left the server running and shut down each of the clients, and the channels have vanished from the report output, so I suspect a dodgy client here. We're using python kombu over ampqlib, so maybe kombu is doing something undesirable. A quick glance at the source shows that it has a channel pool, so maybe that's to blame. Anyway, more investigation required...
Once the number of channels is down to less than 10, the memory usage is around 32M, which seems fine to me. Maybe I don't need to allocate more, if I can solve this channels problem.
>> Is there an
>> option to get the server to return something that says that it is not
>> accepting messages?
>
> In ancient history we used to do this; there's a method in AMQP 0-9-1
> called channel.flow which the server should be able to use to tell a
> client to shut up. In practice it was unreliable (client may not
> support it, or may take too long to take notice of it).
I will do some more testing. Maybe the immediate flag on basic_publish will do something useful. python amqplib is protocol version 0.8, so whatever I do must fit in with that.
Alistair
------------------------------
Message: 5
Date: Mon, 27 Feb 2012 10:25:37 +0100
From: stone <zmstone at gmail.com>
Subject: [rabbitmq-discuss] dead connection lingers around?
To: rabbitmq-discuss at lists.rabbitmq.com
Message-ID:
<CAPNZrFUMw1ZarWq-cuooqw8g6FJXhCNM7xgaBuiYS=a+cwHHQw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi
Have a problem while testing my Erlang client based application.
I have no idea if it's due to some bad behavior in my app or whatsoever, hope I can get some useful information here.
In my case, I have:
three rabbit nodes in a cluster;
one non-durable topic exchange;
two connections established;
several channels and queues (exclusive & non-exclusive) declared.
While i'm testing, sometimes the connections they just linger around even the client has quit already.
For instance, here is one or my dead connections (copied from admin page):
AMQP 0-9-110.15.36.246:36526rabbit at test-app20B/s(1.9kB total) 0B/s(1.1kB total)4guestrunning I'm pretty sure that the client on 10.15.36.246 has been killed already, but the connection is still in "running" state.
/stone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120227/3187eb08/attachment-0001.htm>
------------------------------
Message: 6
Date: Mon, 27 Feb 2012 09:44:56 +0000
From: Steve Powell <steve at rabbitmq.com>
Subject: Re: [rabbitmq-discuss] Problems with STOMP & access control
To: Lionel Cons <lionel.cons at cern.ch>
Cc: rabbitmq-discuss at lists.rabbitmq.com
Message-ID: <7245AC14-4662-4F85-B38A-EAFF206DD7EF at rabbitmq.com>
Content-Type: text/plain; charset=us-ascii
Lionel,
Apologies for tardy reply.
Presently there is no way to set access control based upon the STOMP names, though I agree this would be desirable. Does the STOMP specification talk about access control at all?
I think the destination names aren't all entirely opaque, so it might be possible to exert access control on some resources, but a comprehensive solution is not available, I'm afraid.
Steve Powell
steve at rabbitmq.com
[wrk: +44-2380-111-528] [mob: +44-7815-838-558]
On 21 Feb 2012, at 13:44, Lionel Cons wrote:
> I've read http://www.rabbitmq.com/access-control.html and
> http://www.rabbitmq.com/stomp.html and I did not find any practical
> way to use access control with STOMP.
>
> In the STOMP world (in fact, since STOMP is broker behavior agnostic,
> this is rather tied to the JMS world), one can use destinations like
> /queue/test.foo or /topic/test.bar. It would be natural to use these
> names in the access control regexps to allow, for instance, a given
> user to access all queues matching "test\..*".
>
> Unfortunately, the STOMP destinations names get mapped to AMQP
> resource names that loose the original names, for instance
> amq.gen-AXVr2gFuBTO4duQ5OEC9b9.
>
> Is there a way in RabbitMQ to use access control based on the STOMP
> destination names?
>
> Cheers,
>
> Lionel
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
------------------------------
Message: 7
Date: Mon, 27 Feb 2012 10:21:39 +0000
From: Steve Powell <steve at rabbitmq.com>
Subject: Re: [rabbitmq-discuss] Unexpected behaviour with STOMP & NACK
To: Lionel Cons <lionel.cons at cern.ch>
Cc: rabbitmq-discuss at lists.rabbitmq.com
Message-ID: <C71F5D87-E010-4007-8CEB-7560CCEBFFD7 at rabbitmq.com>
Content-Type: text/plain; charset=us-ascii
Lionel,
Apologies for the tardy reply.
Thank you for reporting this. What is happening is that the NACK sets the 'requeue=true' flag, which, by definition, puts the message back on its queue.
It is then available for redelivery. Whether it gets redelivered to the same consumer depends on lots of things, but is entirely possible, and is expected when there is only one consumer.
Currently, we expect this behaviour and did not think it was prohibited by the specification.
If this is determined to violate the specification we could set requeue=false on NACK, then neither this client, nor any other, will see the message; which is allowable server behaviour. There is currently no mechanism for re-routing messages that are NACKd, but this may change in the near future.
Steve Powell
steve at rabbitmq.com
[wrk: +44-2380-111-528] [mob: +44-7815-838-558]
On 22 Feb 2012, at 12:24, Lionel Cons wrote:
> I get an unexpected behaviour with STOMP & NACK with RabbitMQ 2.7.1.
>
> Here is my test, using an empty queue.
> - client1 connects, sends a message to the queue and disconnects
> - client2 connects, subscribes to the queue with ack:client
> - client2 receives the message (so far so good) but does not ack it
> - client3 connects, subscribes to the queue
> - client2 sends a NACK frame for the message
> - client2 receives the message once more
> - client3 receives nothing
>
> I would have expected the other client (client3) to receive the
> message that has not been consumed by client2. In fact, this is how
> ActiveMQ and Apollo work.
>
> FWIW, the STOMP 1.1 spec mentions:
>
> | NACK is the opposite of ACK. It is used to tell the server that the
> | client did not consume the message. The server can then either send
> | the message to a different client, discard it, or put it in a dead
> | letter queue. The exact behavior is server specific.
>
> So, although the behavior is not strictly defined, re-sending the
> message to the same client does not look appropriate to me.
>
> What do you think?
>
> Cheers,
>
> Lionel
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
------------------------------
Message: 8
Date: Mon, 27 Feb 2012 02:30:15 -0800 (PST)
From: Jon Hill <jon.hill at comshen.com>
Subject: Re: [rabbitmq-discuss] Consumers and exceptions
To: rabbitmq-discuss at lists.rabbitmq.com
Message-ID:
<3b4977f4-5f27-4b7b-97bc-64606fc3acc9 at hs8g2000vbb.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Steve
Many thanks for the reply. That makes sense, and I am now progressing.
All the best
Jon
------------------------------
Message: 9
Date: Mon, 27 Feb 2012 11:31:45 +0100
From: Lionel Cons <lionel.cons at cern.ch>
Subject: Re: [rabbitmq-discuss] Problems with STOMP & access control
To: Steve Powell <steve at rabbitmq.com>
Cc: rabbitmq-discuss at lists.rabbitmq.com
Message-ID: <20299.23441.992131.685344 at mail.cern.ch>
Content-Type: text/plain; charset="us-ascii"
Steve Powell writes:
> Does the STOMP specification talk about access control at all?
No. The specification does not describe the broker behavior. Even something like "/topic/foo" means a JMS-style topic named "foo" is outside of the spec.
> I think the destination names aren't all entirely opaque, so it > might be possible to exert access control on some resources, but a > comprehensive solution is not available, I'm afraid.
It seems that things might work with queues since a STOMP destination of "/queue/foo" will AFAIK use a queue named "foo". To be confirmed.
Topics are more problematic but this does not seem to be STOMP specific.
In AMQP, how would you configure the RabbitMQ ACLs so that client A can only send to amq.topic with a routing key matching A.* while client B is restrcited to routing keys matching B.*?
The http://www.rabbitmq.com/access-control.html page does not really describe what a reource is. Would a syntax like amq.topic:A.* make sense to perform routing key based access control?
Cheers,
Lionel
------------------------------
Message: 10
Date: Mon, 27 Feb 2012 10:42:00 +0000
From: Simon MacMullen <simon at rabbitmq.com>
Subject: Re: [rabbitmq-discuss] Ensuring low latency for publishers
To: rabbitmq-discuss at lists.rabbitmq.com
Message-ID: <4F4B5DF8.5090500 at rabbitmq.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 24/02/12 18:07, Eric wrote:
> In reality, the throttling case is extremely unlikely anyway, right?
> You basically have to create a case where publishers are outpacing
> consumers and/or the speed of disk writes on the broker. So you'd
> have to publish something like 100mb/s with little or no consumption,
> and our application is roughly 5mb/minute.
With small messages in fact the first thing you run into is being CPU-bound making routing decisions. But the general principle holds, yes.
> In conclusion, I finally did what I should have done in the first
> place. I mocked up the threading scenario we're likely to see in
> production and benchmarked it against Java's LinkedBlockingQueue and
> ArrayBlockingQueue. Compared to each producer thread having its own
> linked list (the completely uncontended scenario) the blocking queues
> introduced virtually no additional waiting - a microsecond or two at
> most. That's the case even at rates 50x or more than we'd see in
> production. So blocking queue it is, and that's a comfortingly simple
> solution.
>
> Thanks for all the help and apologies for under-researching what I was
> doing.
Ah, good.
I had a quick look at implementing non-blocking publish on Java on Friday. Unfortunately it's not possible to do this without NIO on Java, so a prerequisite becomes "port the Java client to NIO", which... makes it less likely to happen I'm afraid.
Cheers, Simon
--
Simon MacMullen
RabbitMQ, VMware
------------------------------
Message: 11
Date: Mon, 27 Feb 2012 10:56:09 +0000
From: Steve Powell <steve at rabbitmq.com>
Subject: Re: [rabbitmq-discuss] STOMP doesn't include the routing-key
on MESSAGE frames
To: Tony Garnock-Jones <tonygarnockjones+rabbitmq at gmail.com>
Cc: RabbitMQ Discuss <rabbitmq-discuss at lists.rabbitmq.com>
Message-ID: <5E2DB83D-C02B-48D6-97C2-FDB76643B855 at rabbitmq.com>
Content-Type: text/plain; charset=us-ascii
Tony,
Read your patch, and prefer this solution to adding extra headers.
I'm raising a bug (24763) to fix our spec-compliance problem (thank you for
pointing this out), and see if we can get this change in.
Steve Powell
steve at rabbitmq.com
[wrk: +44-2380-111-528] [mob: +44-7815-838-558]
On 20 Feb 2012, at 20:36, Tony Garnock-Jones wrote:
> Hi Steve,
>
> How about the attached patch? It attempts to bring the "destination"
> header in MESSAGEs in to line with the STOMP 1.1 spec. I've paid
> cursory attention to binary-and-slash-escaping issues but it could use
> a second glance before being committed, I reckon.
>
> Regards,
> Tony
>
> On 20 February 2012 14:56, Tony Garnock-Jones
> <tonygarnockjones+rabbitmq at gmail.com> wrote:
>> Adding the routing_key puts the final small missing piece in place. A
>> perhaps more STOMPish way of giving it would be to have a "to" header
>> or similar carried in a MESSAGE, containing the full destination given
>> in the SEND. Oh wait! I've just checked, and actually that's what's
>> required by the 1.1 spec already. So the STOMP adapter isn't quite
>> spec-compliant, in that it's giving the destination from the
>> *subscribe* rather than the *send*.
> --
> Tony Garnock-Jones
> tonygarnockjones at gmail.com
> http://homepages.kcbbs.gen.nz/tonyg/
> <better-destination-patch.patch>
------------------------------
Message: 12
Date: Mon, 27 Feb 2012 11:05:56 +0000
From: Simon MacMullen <simon at rabbitmq.com>
Subject: Re: [rabbitmq-discuss] dead connection lingers around?
To: stone <zmstone at gmail.com>
Cc: rabbitmq-discuss at lists.rabbitmq.com
Message-ID: <4F4B6394.10903 at rabbitmq.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi.
Sometimes if a TCP connection gets killed outright the OS never notices
and so we don't know either.
This probably implies you are not closing connections properly? (i.e.
with the AMQP close handshake, by invoking amqp_connection:close/1.)
Enabling AMQP heartbeats will allow RabbitMQ to detect this condition.
Cheers, Simon
On 27/02/12 09:25, stone wrote:
> Hi
>
> Have a problem while testing my Erlang client based application.
> I have no idea if it's due to some bad behavior in my app or whatsoever,
> hope I can get some useful information here.
>
> In my case, I have:
> three rabbit nodes in a cluster;
> one non-durable topic exchange;
> two connections established;
> several channels and queues (exclusive & non-exclusive) declared.
>
> While i'm testing, sometimes the connections they just linger around
> even the client has quit already.
>
> For instance, here is one or my dead connections (copied from admin page):
>
> AMQP 0-9-1 10.15.36.246:36526 <http://10.15.36.246:36526>
> rabbit at test-app2 0B/s_(1.9kB total) 0B/s_(1.1kB total) 4 guest running
>
> I'm pretty sure that the client on 10.15.36.246 has been killed already,
> but the connection is still in "running" state.
>
> /stone
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
--
Simon MacMullen
RabbitMQ, VMware
------------------------------
Message: 13
Date: Mon, 27 Feb 2012 11:06:49 +0000
From: Simon MacMullen <simon at rabbitmq.com>
Subject: Re: [rabbitmq-discuss] ??: Passive queue declaration and
channel closure
To: Simone Busoli <simone.busoli at gmail.com>
Cc: "rabbitmq-discuss at lists.rabbitmq.com"
<rabbitmq-discuss at lists.rabbitmq.com>
Message-ID: <4F4B63C9.7070909 at rabbitmq.com>
Content-Type: text/plain; charset=GB2312
On 25/02/12 18:37, Simone Busoli wrote:
> David, I somewhat agree with you, lack of documentation about
> operational aspects of broker behavior is something I have been missing
> as well.
Yeah, I suspect our documentation could still be better. But this is one
of the areas where it's really easy to be blinded by over-familiarity.
What sort of things do you think are particularly missing?
Cheers, Simon
--
Simon MacMullen
RabbitMQ, VMware
------------------------------
Message: 14
Date: Mon, 27 Feb 2012 11:43:12 +0000
From: Michael Bridgen <mikeb at rabbitmq.com>
Subject: Re: [rabbitmq-discuss] Apache MINA Integration
To: rabbitmq-discuss at lists.rabbitmq.com
Message-ID: <4F4B6C50.9070702 at rabbitmq.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Has anyone integrated Apache MINA with Rabbit MQ to publish and receive
> messages?
What form would you expect such an integration to take?
------------------------------
Message: 15
Date: Mon, 27 Feb 2012 11:49:18 +0000
From: Marek Majkowski <majek04 at gmail.com>
Subject: Re: [rabbitmq-discuss] [help] [beginner] server stops sending
messages; publish (in transaction) hangs on commit
To: Alistair Bayley <alistair at abayley.org>
Cc: rabbitmq-discuss <rabbitmq-discuss at lists.rabbitmq.com>
Message-ID:
<CABzX+qznWcOPTsLob0w+uK0vUg7GBbOqot0EzhbKud12DDLAJQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Mon, Feb 27, 2012 at 03:37, Alistair Bayley <alistair at abayley.org> wrote:
> On 25 February 2012 00:38, Simon MacMullen <simon at rabbitmq.com> wrote:
>>>
>>> OK. Can I have some guidance as to how much memory we should allocate?
>>
>> This is a real how-long-is-a-piece-of-string question I'm afraid. 512M would
>> already be a significant step towards the comfort zone though.
>
> rabbitmqctl report shows a large number of channels (in the thousands)
> and memory usage seems to correlate with the large number of channels.
> I've left the server running and shut down each of the clients, and
> the channels have vanished from the report output, so I suspect a
> dodgy client here. We're using python kombu over ampqlib, so maybe
> kombu is doing something undesirable. A quick glance at the source
> shows that it has a channel pool, so maybe that's to blame. Anyway,
> more investigation required...
Right. This is definitely possible that channels are the main
thing that consumes memory.
> Once the number of channels is down to less than 10, the memory usage
> is around 32M, which seems fine to me. Maybe I don't need to allocate
> more, if I can solve this channels problem.
Yup, quite possible.
>>> Is there an
>>> option to get the server to return something that says that it is not
>>> accepting messages?
>>
>> In ancient history we used to do this; there's a method in AMQP 0-9-1 called
>> channel.flow which the server should be able to use to tell a client to shut
>> up. In practice it was unreliable (client may not support it, or may take
>> too long to take notice of it).
>
> I will do some more testing. Maybe the immediate flag on basic_publish
> will do something useful. python amqplib is protocol version 0.8, so
> whatever I do must fit in with that.
Nope, "immediate" flag is a completely unrelated:
http://www.rabbitmq.com/amqp-0-9-1-reference.html#basic.publish
Marek
------------------------------
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
End of rabbitmq-discuss Digest, Vol 57, Issue 28
************************************************
More information about the rabbitmq-discuss
mailing list