5 Replies Latest reply on Mar 27, 2017 11:09 AM by jbertram

    JMS Messaging with DUPS_OK_ACKNOWLEDGE, the messages remain in the queue

    bsudhananthan

      I'm using WildFly 9.0.2.Final. I've JMS sessions created with DUPS_OK_ACKNOWLEDGE Acknowledgement-mode. So as we know, with this configuration the ack will only be sent, once the dups-ok-batch-size is reached. So in my case the dups-ok-batch-size is set considering the possible maximum JMS load in the system. But at sometimes if there is no load in the system,  the messages remain in the queue waiting for the acknowledgement (more than a day), as the dups-ok-batch-size was not reached.

       

      Is there any configuration to handle this case, like we have "max-batch-time" under jms-bridgeType?

        • 1. Re: JMS Messaging with DUPS_OK_ACKNOWLEDGE, the messages remain in the queue
          jbertram

          There 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.

          1 of 1 people found this helpful
          • 2. Re: JMS Messaging with DUPS_OK_ACKNOWLEDGE, the messages remain in the queue
            bsudhananthan

            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

              In 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.

              1 of 1 people found this helpful
              • 4. Re: JMS Messaging with DUPS_OK_ACKNOWLEDGE, the messages remain in the queue
                bsudhananthan

                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

                  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.