Ben,<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div><div><br><div>In your patch, you also added an extra method to handle a spurious consume_ok message;</div>

<div><br></div><div><div>%% Edwin Fine bugfix: This is actually being called wrong from somewhere,</div><div>%% but this will fix it.</div><div>handle_method({&#39;basic.consume_ok&#39;, ConsumerTag}, State) -&gt;</div><div>

&nbsp;&nbsp; &nbsp;io:format(&quot;[~p] Got bad handle_method call!~n&quot;, [self()]),</div><div>&nbsp;&nbsp; &nbsp;handle_method(#&#39;basic.consume_ok&#39;{consumer_tag = ConsumerTag}, State);</div></div><div><br></div><div>This method is preceded in the code by the following function:</div>

<div><br></div><div><div>handle_method(BasicConsumeOk = #&#39;basic.consume_ok&#39;{consumer_tag = ConsumerTag},</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;State = #channel_state{pending_consumer = Consumer}) -&gt;</div><div>&nbsp;&nbsp; &nbsp;Consumer ! BasicConsumeOk,</div>

<div>&nbsp;&nbsp; &nbsp;NewState = register_consumer(ConsumerTag, Consumer, State),</div><div>&nbsp;&nbsp; &nbsp;{noreply, NewState2} = rpc_bottom_half(BasicConsumeOk, NewState),</div><div>&nbsp;&nbsp; &nbsp;{noreply, NewState2#channel_state{pending_consumer = &lt;&lt;&gt;&gt;} };</div>

<div><br></div><div>So I not quite sure why that didn&#39;t match first because&nbsp;#&#39;basic.consume_ok&#39;{consumer_tag = ConsumerTag} should match against&nbsp;{&#39;basic.consume_ok&#39;, ConsumerTag} and&nbsp;#channel_state{pending_consumer = Consumer} should match even if the pending_consumer was not defined.</div>

</div></div></div></div></blockquote><div>&nbsp;</div>Actually, I was
in the middle of trying to get that right, and it was late, so I would
ignore that comment (and the code) completely. In fact I have removed
it from the most recent code. I was trying to get rid of the error that
I saw in the stack trace of the amqp_channel, namely<br>
<br><span style="font-family: courier new,monospace;">** Reason for termination == </span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">** {badarg,[{amqp_channel,handle_method,2},</span><br style="font-family: courier new,monospace;">


<span style="font-family: courier new,monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {gen_server,handle_msg,5},</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {proc_lib,init_p,5}]}</span><br style="font-family: courier new,monospace;">

<br>Now that I am doing the basic.consume in the process that starts the consumers, the above issue does not occur.<br>Thanks
for all your help. In the meantime, until you have a more elegant
bugfix (to the rabbit_writer proliferation) than my hack, I will just
continue to use my modified Erlang client.<br>
<br>Ben, you also wrote:<br><div><br>&gt;&gt;&gt; That&#39;s a good point.
I think the cleanup code should go into the gen_server terminate
callback to keep it one place.<br><br>Funny thing, that - I *did* put
the cleanup code into the terminate, but it did not seem to be called.
It was only when I put it directly before the {stop, xxx} returns that
it finally got called. Again, this may have just been late night
syndrome, but I had extensive print statements and could clearly see
that it was not happening. At that time all I wanted was to get it to
work. Please understand that all the code I have submitted (other than
amqp_channel) is a pure hack to try to expose and duplicate the errors!<br>
<br></div>Thanks again.<br>Regards,<br>Ed<br>