I read about those items and checked out my configuration. I don't have
anything in there that should cause this. here's the section that defines
the flow control:
<destinationPolicy>
<policyMap>
<policyEntries>
<policyEntry topic=">" producerFlowControl="false">
<pendingSubscriberPolicy>
<vmCursor />
</pendingSubscriberPolicy>
</policyEntry>
<policyEntry queue=">" producerFlowControl="false">
</policyEntry>
</policyEntries>
</policyMap>
</destinationPolicy>
I did however run some tests without using receipts and was able to do about
4000 messages per second in these message size ranges. As soon as I enable
receiving of receipts, it goes back to 24 messages per second. I'm using
the Net::STOMP::Client module. The documentation says this about receipts:
"By default, you do not get any confirmation that the message has indeed
been received by the broker. If you want such a confirmation, you have to
use receipts. The following code snippet sends two messages with a receipt
header containing a pseudo-unique id and waits for matching RECEIPT frames
coming from the broker. This is easy because the Net::STOMP::Client module
keeps track of which receipts are expected and have not been received yet."
I am using the ack => 'client' parameter when subscribing to a queue. Seems
like sending an ack would be sufficient, but apparently I also need to send
a receipt.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Slow-delivery-of-messages-between-8KB-and-23KB-tp3824957p3827409.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.