<div dir="ltr">Hi Emile, thanks for your reply.<div><br></div><div>As I mentioned I'm on a python oriented environment, so can't use the Tracer you provided directly. I look for an equivalent or if not I'll try to use that one. However, i'm pretty sure that the ACKs are sent correctly (there's only one line with basic_ack in my code, and from the logging messages it looks like it is called correctly). Nevertheless I'll use the tracer approach just to make sure. </div>
<div><br></div><div>About synchronizing the two threads that are using the channel I don't think it's possible. I could synchronize sending the ACK messages on the worker thread but the consumer thread can wait indefinitely for messages to come. And I don't see where I would have the opportunity to take a lock since once the consumer thread starts listening, we have no control over it. We only get the callback when a message arrives. I guess the general question here would be: what is the correct way of fetching the messages on one thread and doing the work on another (from a synchronization point of view)? </div>
<div><br></div><div>And to explain a bit more the "peeking at messages" scenario, here's the reason. Imagine each task requires fetching some data from a database (located on a different server). As always, doing bulk operations is a lot faster. So when the worker needs to fetch data for one task, from the database server, it will check if there are other tasks in the local queue that also need data, and request everything in bulk. So when the 1st task is processed, data is fetched also for task 2,3,4..10. So the processing for those tasks will be much faster afterwards, because they'll find the data they need in a local cache. Then task 11 will probably fetch the data for tasks 11 to 20 and so on. It's an optimization I'm making on the client side improve the speed. </div>
<div><br></div><div>I guess in a few words what I'm trying to implement is bulk processing on the client side. Maybe there's a different way to do this.</div><div><br></div><div>Cheers,</div><div>Raz</div><div><div class="gmail_extra">
<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 28, 2013 at 4:21 PM, Emile Joubert <span dir="ltr"><<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<br>
On 28/08/13 13:30, Razvan Dinu wrote:<br>
<br>
> it's usually because of double ack-ing, ack-ing on wrong channels or<br>
> ack-ing messages that should not be ack-ed. I've checked at least a<br>
> dozen times, and it doesn't seem to be the case for me.<br>
<br>
A good way to verify that claim independently from the client code is to<br>
connect to the broker via the Tracer:<br>
<br>
<a href="http://www.rabbitmq.com/javadoc/com/rabbitmq/tools/Tracer.html" target="_blank">http://www.rabbitmq.com/javadoc/com/rabbitmq/tools/Tracer.html</a><br>
<br>
The protocol trace will show whether messages are being acknowledged<br>
correctly.<br>
<br>
> I think it has something to do with ACK-ing from one thread using the<br>
> same channel that is used for listening on another thread.<br>
<br>
If you use multiple threads to access the same channel then you must<br>
make sure they are synchronised. A better solution is to provide each<br>
thread with its own channel.<br>
<br>
> it's because I need the worker to be able to take a peak at some of<br>
> the tasks in the queues.<br>
<br>
Can the criteria being peeked at be placed in a header or the routing<br>
key instead? Try to route those messages differently and avoid the need<br>
for peeking.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<br>
-Emile<br>
<br>
<br>
</font></span></blockquote></div><br></div></div></div>