-
1. Re: JMS Messaging with DUPS_OK_ACKNOWLEDGE, the messages remain in the queue
jbertram Mar 24, 2017 9:55 AM (in response to bsudhananthan)1 of 1 people found this helpfulThere is no timing configuration related to the acknowledgment batch size. The optimization related to batching acknowledgements is generally meant for use in a system with constant high throughput. If there is no message load you can close your consumer(s) and the close operation will flush any acks in the buffer.
I'm curious about your use-case. Did you benchmark your application and determine that acks were a performance bottleneck such that batching provided a statistically significant improvement? If not, then you can likely avoid these hanging acks by reducing the ack batch size to 0.
-
2. Re: JMS Messaging with DUPS_OK_ACKNOWLEDGE, the messages remain in the queue
bsudhananthan Mar 27, 2017 2:34 AM (in response to jbertram)Thanks Justin, for your quick reply.
Justin Bertram wrote:
I'm curious about your use-case. Did you benchmark your application and determine that acks were a performance bottleneck such that batching provided a statistically significant improvement?
I haven't done a benchmark, we initially went with the default sizing (i.e 1 MB) and reduced this size based on the message throughput.
Justin Bertram wrote:
If there is no message load you can close your consumer(s) and the close operation will flush any acks in the buffer.
If not, then you can likely avoid these hanging acks by reducing the ack batch size to 0.
In our case, the subscriber will receive a high notification messages and considerably low messages based on the server processing/load. In this case the consumer has to be remain open all the times.
So high batch size impacts the low message flow and setting the batch size to 0 will impact the high flow.
How to solve this case? Time factor like dups-batch-time along with the size param could resolve this.
-
3. Re: JMS Messaging with DUPS_OK_ACKNOWLEDGE, the messages remain in the queue
jbertram Mar 27, 2017 9:18 AM (in response to bsudhananthan)1 of 1 people found this helpfulIn our case, the subscriber will receive a high notification messages and considerably low messages based on the server processing/load.
I'm not really sure what this means. What is a "high notification message"? What is a "low message"?
...setting the batch size to 0 will impact the high flow.
Technically, yes. Having an ack batch size of 0 will impact high volume use-cases. However, if you haven't benchmarked how can you know the impact will be statistically significant?
How to solve this case? Time factor like dups-batch-time along with the size param could resolve this.
At this point I recommend you benchmark and then tune the appropriate settings for best overall throughput or whatever suits your performance requirements.
-
4. Re: JMS Messaging with DUPS_OK_ACKNOWLEDGE, the messages remain in the queue
bsudhananthan Mar 27, 2017 9:55 AM (in response to jbertram)Justin Bertram wrote:
I'm not really sure what this means. What is a "high notification message"? What is a "low message"?
By that I mean the jms message transfer rate will be high/low based on the server load/processing.
Justin Bertram wrote:
At this point I recommend you benchmark and then tune the appropriate settings for best overall throughput or whatever suits your performance requirements.
That I'll do. But I don't know how to derive the number for the above mentioned case (i.e combination of high and low throughput).
Thanks./
-
5. Re: JMS Messaging with DUPS_OK_ACKNOWLEDGE, the messages remain in the queue
jbertram Mar 27, 2017 11:09 AM (in response to bsudhananthan)But I don't know how to derive the number for the above mentioned case (i.e combination of high and low throughput).
That's what the benchmarking is for.