[rabbitmq-discuss] Channel crashes after basic.cancel_ok.
rabbitmq-discuss_efine at usa.net
Sat May 10 01:02:27 BST 2008
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
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.
On Fri, May 9, 2008 at 7:07 PM, Ben Hood <0x6e6562 at gmail.com> wrote:
> On 8 May 2008, at 21:11, Ben Hood wrote:
>> On 8 May 2008, at 15:04, Edwin Fine wrote:
>>> Thanks for looking into this. In the "real" code, all the setup is
>>> actually done within a single Erlang process, and the only thing the
>>> consumers do is handle the basic.deliver, as well as any basic.consume_ok
>>> or basic.cancel_ok messages that may arise. In the test code, I rearranged
>>> some things specifically to be done concurrently, which I now see was a
>>> mistake. However, this is a bug in the test code, not in the production
>>> code. I will change the test code so that there is no concurrent work being
>>> done on a channel other than responding with basic.ack to basic.deliver
>> I've begun a discussion on this topic and it looks like we will add the
>> intelligence to the amqp_channel module to be able to serialize concurrent
>> RPC requests to the channel. I understand that you have a workaround anyway,
>> but on reflection, it seems like a good idea to put this capability into the
>> client. will let you know when it is done.
> This feature is now implemented in the trunk of the repo. There is also a
> test case to test the serialization of concurrent RPC requests.
> I will now look into the next 2 issues you raised.
> BTW, I am also in the process of moving the mtn repo to hg, so this might
> happen very soon as well.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss