Description of problem:
See attached program that:
- creates a queue (via QMF) and fetches QMF response in a response queue (response got very fast)
- runs a new thread that subscribes to a queue and fetches messages in loop
- deletes the queue (not-used at all) via QMF and fetches response in a response queue
- joins the child thread

The latest fetch takes as much time as timeout is set on it. Despite the response gets quite fast (similarly as fast the QMF response to create request).


Version-Release number of selected component (if applicable):
qpid-cpp-client-0.18-14


How reproducible:
100%


Steps to Reproduce:
1. See attached test_qmf_DeleteOnly.cpp
2. g++ test_qmf_DeleteOnly.cpp -o test_qmf_DeleteOnly.cpp -lpthread -lqpidmessaging -lqpidclient -lqpidcommon -lqpidtypes -lboost_date_time -lboost_thread-mt
3. ./test_qmf_CreateDeleteOnly 3000
(the parameter specifies fetch timeout in ms)


Actual results:
2013-Apr-23 09:20:32.299674] Fetch timeout to be set to 3000ms.
2013-Apr-23 09:20:32.299860] Connecting to amqp:127.0.0.1:5672...
2013-Apr-23 09:20:32.313633] Creating session...
2013-Apr-23 09:20:32.315619] Creating sender...
2013-Apr-23 09:20:32.316667] Declaring queue...
2013-Apr-23 09:20:32.318789]  just before QMF fetch response on queue 1reply-queue; {create:always, node:{x-declare:{auto-delete:true}}}
2013-Apr-23 09:20:32.359730]  just after QMF fetch response: _method_response
2013-Apr-23 09:20:32.360898] Creating receiver...
2013-Apr-23 09:20:32.401596] Starting thread...
2013-Apr-23 09:20:32.402169] Deleting queue...
2013-Apr-23 09:20:32.443053]  just before QMF fetch response on queue 2reply-queue; {create:always, node:{x-declare:{auto-delete:true}}}
2013-Apr-23 09:20:35.456709]  just after QMF fetch response: _method_response
2013-Apr-23 09:20:35.457935] Finalizing thread...
2013-Apr-23 09:20:35.618518] Done, press Ctrl+C to exit

- see the 3 seconds delay after "just before QMF fetch response on queue 2reply-queue".
- increasing the program parameter (fetch timeout) directly impacts the delay

Expected results:
No such delay.


Additional info:
tcpdump showed that the client gets the message quite early but it re-issue credit to the broker in order to attempt to fetch new messages.

traces of qpid client library showed second (child) thread running fetch in loop in fact gets the message, but enqueues it to internal buffer - see qpid/client/amqp0_10/IncomingMessages.cpp, method IncomingMessages::process and log:

QPID_LOG(debug, "Pushed " << *content->getMethod() << " to received queue");

The child thread did the enqueue properly, as it fetches for messages of different destination; the problem is that the parent thread fetching QMF response does not check the received queue before querying broker.

The concurrent fetching in two threads is essential for the reproducer. Moving "should_end.unlock(); thread.join();" before deleting the queue _prevents_ the delay at all.