
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Ed,<div><br><div><div>On 10 May 2008, at 01:02, Edwin Fine wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Thanks, Ben, I will take a look and give you some feedback.<br><br>In the meantime, I have done the following:<br><ul><li>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 :)<br> </li><li>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.<br> </li><li>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.<br></li></ul></blockquote><div><br></div></div>I have now commited fix 2 of 3 to the mtn repo which addresses the issue of not being able to subscribe concurrently. So the 2 issues you mention here should be addressed.</div><div><br></div><div>The outstanding issue is to close the writer down properly in the network case.</div><div><br></div><div>HTH,</div><div><br></div><div>Ben</div></body></html>