<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Just quickly before you start doing stuff:<div><br></div><div>Does it make a difference if you just the direct client rather than the TCP client?</div><div><br></div><div>Ben</div><div><br><div><div>On 7 May 2008, at 21:50, Edwin Fine wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Thanks for the response, Ben. I will try to create a standalone program that reproduces the issue. I hope I can do it. The hesitation comes because the circumstances under which this occurred are:<br><ul><li>50 queues on one <<direct>> exchange</li> <li>A producer that is pushing 150 messages/second to the queues, evenly across the queue name</li><li>Each queue is doing a basic.deliver to one of 50 Erlang consumer processes (gen_event). The consumer processes all share the same channel (which may not be a good idea, because when the channel crashed, so did all 50 consumers. I wonder if I should have 1 channel for each consumer? Too heavy?).</li> <li>Because the channel.flow command is not implemented, I am using unsubscribe to try to do flow control, because I am finding that RabbitMQ is dumping all the basic.deliver messages into the Erlang message queue of each consumer gen_event process. This is totally not what I want - I want the messages to stay persisted in Rabbit-land until I can deliver them and tell Rabbit to release them.</li> <li>The reason I need flow control is because I am delivering messages via HTTP/XML to a number of different Web sites. Sometimes a web site may be down, often for hours, and I want to just be able to pause the consumer (and producer) until messages start going through again. Having the Erlang message queues filling up with thousands of messages will eventually crash the VM due to OOM. I know I can poll with basic.get, but the conundrum is that I want high performance while the web sites are accepting input, and shut-off when they are not. Any suggestions?<br> </li></ul>So I may have to build a simulated version of the above to get the problem to happen again. That's the hesitation - will it trigger the error?<br><br>Anyway, I am probably not doing this the right way, but I have no expertise in AMQP. My knowledge is of MQSeries a few years back.<br> <br>Regards,<br>Edwin Fine<br><br><div class="gmail_quote">On Wed, May 7, 2008 at 4:29 PM, Ben Hood <<a href="mailto:0x6e6562@gmail.com">0x6e6562@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Edwin,<div class="Ih2E3d"><br> <br> On 7 May 2008, at 18:57, Edwin Fine wrote:<br> <br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Using Rabbit 1.3.0, Erlang client, Ubuntu Linux Feisty, Erlang R12B-2 64-bit<br> <br> Consumer channel crashes as follows when I do the following:<br> <br> 1. Subscribe (basic.consume)<br> 2. Unsubscribe (basic.cancel)<br> <br> The channel crashes handling the basic.cancel_ok. I can't figure out<br> why. The channel is under some load (about 100 - 130 messages/second).<br> I haven't yet built a standalone test case to try to reproduce this,<br> but it happens consistently in my code.<br> <br> The code to subscribe is:<br> <br> #'basic.consume_ok'{consumer_tag = ConsumerTag} =<br> amqp_channel:call(Channel, BasicConsume, self())<br> <br> and this works fine.<br> <br> The code to cancel is<br> <br> BasicCancel = #'basic.cancel'{consumer_tag = ConsumerTag, nowait = false},<br> #'basic.cancel_ok'{consumer_tag = ConsumerTag} =<br> amqp_channel:call(Channel, BasicCancel).<br> <br> The problem seems to be<br> <br> ** {function_clause,<br> [{gen_server,reply,<br> [<<>>,<br> {'basic.cancel_ok',<<"XHG.DELIVERY.Q.HTTP031.HC031">>}]},<br> <br> <br> What am I doing wrong? Any ideas?<br> </blockquote> <br></div> What you are seeing is a symptom of an error in the RPC handling. Essentially, the channel process is receiving a notification that it thinks it has already sent to the invoking process.<br> <br> It would be really good if you could send some code that might help me reproduce this myself.<br> <br> In the meantime I will look into this and see if I can come up with a solution.<br> <br> HTH,<br><font color="#888888"> <br> Ben<br> <br> <br> </font></blockquote></div><br></blockquote></div><br></div></body></html>