[rabbitmq-discuss] Channel crashes after basic.cancel_ok.
0x6e6562 at gmail.com
Thu May 15 12:36:43 BST 2008
On 10 May 2008, at 01:02, Edwin Fine wrote:
> Thanks, Ben, I will take a look and give you some feedback.
> In the meantime, I have done the following:
> Changed my consumer code (I use the term "consumer" loosely as
> "anything that eats the output of a producer") to use basic.get
> instead of basic.consume. Actually, it's set up so that I can select
> basic.get or basic.consume behavior at run-time. I didn't want to
> throw away working basic.consume code :)
> Changed the process that creates consumers so that it now creates
> one channel per consumer. Previously, there was one channel only for
> all consumers. One-channel-per-consumer was the only way I could get
> the code to work with the network client; in the one-channel
> scenario I was getting back responses to messages destined for
> different consumers. I assume that with your changes I will be able
> to again use one channel for all consumers.
> I tested with 50 queues (each with its own consumer and channel) and
> it seemed reasonably performant, even with the get. I need to try a
> full-blast test soon.
> Again, thanks for your help and patience, and do let me know if you
> see any merit in the rbmq_admin module I wrote, or if maybe you guys
> are releasing an official one.
Sorry for not responding to this sooner, the offer is appreciated.
Having said that, part of the functionality you have written is a
wrapper around the rabbit_access_control module, which is pretty much
what the rabbit_control module is (see the rabbitmqctl script). That's
not to say there is no merit in improving the whole management aspect
of RabbitMQ, which I think is the important point you making with the
rbmq_admin module you have written. I know there have been a few posts
about the reshaping the current management facilities, but (although I
may stand corrected) these discussions have been more along the lines
of requirements gathering and getting users to say what types of
management functionality they'd like to see in the product. Hence your
module can definitely serve as a description of what you'd like to
see. In the past I have expressed some views about the remoting aspect
of rabbit management, but what you are touching on is the core
services that are offered. Obviously these will need to discussed in
order to come up with a stable API that isn't so tightly coupled to
the implementation aspects of the server, which *will* change over
time. To generate interest in this, I suggest you start a new
discussion topic on this.
On the other side of things, I have done some further refactoring to
the writer cleanup and concurrency of RPC requests, so if you did get
an opportunity to give your code a go using the single channel variant
with basic consume, that would be greatly appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss