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

[Edwin Fine]

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.

Regards,
Ed

On Fri, May 9, 2008 at 7:07 PM, Ben Hood <0x6e6562 at gmail.com> wrote:

> Ed,
>
> 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
>>> messages.
>>>
>>
>> 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.
>
> HTH,
>
> Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080509/f26ac8e8/attachment.htm