Already created QPID-5828 to cover these issues (plus some others). I
have also attached several boost unit tests that help demonstrate the
problems.
I have a few more issues to report with the messaging API, but I have
run out of time to get them detailed with boost unit tests today, I will
try and add them in the next few days. But in summary the outstanding
issues are:
- valgrind with helgrind tool reports out of order locking problems
between Session and Sender locks (may cause deadlock)
- valgrind with helgrind tool reports race condition with bool
writePending variable in .qpid/sys/posix/AsynchIO.cpp. Variable defined
as volatile, not sure this is actually enough to avoid data race
conditions, as volatile keyword provides no guarantees on concurrent access.
- Session::checkError can throw exceptions that extend from
qpid::Exception, not sure how to catch these as cannot find this
exception in installation directory.
- Once a sender has transitioned in to a flush state (capacity/4 >
outgoing queue size) and a connection does not exist to the broker,
messages sent will not be placed in the outgoing queue.
Should I add these additional issues to QPID-5828, and attach new test
cases as and when I can?
On 16/06/2014 16:38, Gordon Sim wrote:
On 06/16/2014 01:20 PM, CLIVE wrote:
Hi,
A client has been having problems with TTL on their messages,
specifically messages being delivered when they believe the TTL should
have expired. (They are using QPID 0.28 on CentOS 6.4).
I have tracked the problem(s) down and reproduced the potential issues
in the attached BOOST unit testcases.
The first issue is to do with the qpid::messaging::Sender. If an
application sends messages while the sender is not connected, they are
stored in the senders outgoing queue (assuming flush mechanism hasn't
been activated). When the sender finally gets reconnected (using the
reconnect functionality on the qpid::messaging::Connection), the
messages in the senders outgoing queue get flushed as part of the
Session reset mechanism. But if the TTL on these messages is say 1
second and the Sender has been disconnected for more than this period,
the messages still get sent and delivered to the associated set of
receivers. No adjustment in TTL gets made by the Sender Implementation.
Therefore messages that should have expired still get delivered.
That would be nice to fix.
The second issue is to do with the qpid::messaging::Receiver. If a
sender and receiver are both created with an address string of
"amq.topic/fred" and the receiver is configured with a capacity of 10.
Then if the sender sends 100 messages with a TTL of 1 second, but the
associated receiver is not serviced by the application for 2 seconds,
when the receiver is serviced (using get/fetch) then 10 messages are
still delivered to the application. In fact the number of messages
delivered to the application, under this kind of scenerio, matches the
capacity setting of the receiver. It would appear that even though the
Broker is expiring messages from the queue (using qpid-tool I can see 90
messages have been expired from the queue), it does not manage to do
this for messages that have already been cached by the receiver due to
its capacity setting.
By default a receiver on amq.topic/fred will be using unacknowledged
transfer. Therefore if the message has been sent to the client, the
broker has already deleted its record.
I.e. the issue is that the receiver does not itself do any expiration
of messages from the prefetch buffer.
What are peoples thoughts on this behavior?
I think both issues can clearly be considered bugs. If you raise a
JIRA I can take a look at what a fix might involve (unless you have
already done so).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
