[rabbitmq-discuss] Channel crashes after basic.cancel_ok.

[Ben Hood]

Ed,

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.

HTH,

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080515/187f0ab5/attachment.htm