Uploaded image for project: 'FUSE Message Broker'
  1. FUSE Message Broker
  2. MB-377

Using small queue prefetch sizes cause all consumers to run as fast as the slowest consumer.

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 5.0.0.17-fuse, 5.1.0.0-fuse
    • Fix Version/s: 5.0.0.19-fuse
    • Component/s: broker
    • Labels:
      None
    • Environment:

      Servicemix 3.3.1.3 on Windows, probably on all platforms.

      Description

      If you have a JMS producer sending messages to multiple consumers and you have the cacheLevel set to 3 or higher, eventually all consumers will run as slow as the slowest consumer.
      In the attached projects the SA sends messages to a MockOptimizer (JMS consumer) that has two threads. One sleeps for one second and the other sleeps for ten. Initially the thread sleeping for 1 second will consume most of the messages, but towards the end it will start to consume messages every ten seconds as well.

        Gliffy Diagrams

          Activity

          Hide
          chirino Hiram Chirino added a comment -

          Attaching the junit case that confirms the bug.

          Show
          chirino Hiram Chirino added a comment - Attaching the junit case that confirms the bug.
          Hide
          chirino Hiram Chirino added a comment -

          The issue revolves around how ActiveMQ 5.x pages and dispatches messages to consumers. Every queue keeps list of paged in messages which defaults to 100 max entires. It round robins dispatching messages between consumers, even the slow consumers. Once the slow consumer gets 100 dispatched messages which it has not yet acked due to it being slow, then no further messages are paged in since the page in list is full.

          I am evaluating different ways to implement this but, any change to this code could have repercussions which need to get evaluated.

          Show
          chirino Hiram Chirino added a comment - The issue revolves around how ActiveMQ 5.x pages and dispatches messages to consumers. Every queue keeps list of paged in messages which defaults to 100 max entires. It round robins dispatching messages between consumers, even the slow consumers. Once the slow consumer gets 100 dispatched messages which it has not yet acked due to it being slow, then no further messages are paged in since the page in list is full. I am evaluating different ways to implement this but, any change to this code could have repercussions which need to get evaluated.
          Hide
          chirino Hiram Chirino added a comment -

          https://issues.apache.org/activemq/browse/AMQ-1866 has the latest updates. In short we are still looking for an optimal fix for this. Already two different fix proposoals have been made but were found lacking. We still continuing to to work on the problem.

          Show
          chirino Hiram Chirino added a comment - https://issues.apache.org/activemq/browse/AMQ-1866 has the latest updates. In short we are still looking for an optimal fix for this. Already two different fix proposoals have been made but were found lacking. We still continuing to to work on the problem.
          Hide
          chirino Hiram Chirino added a comment -

          Update.. we are now currently evaluating and testing the attached patch. It fixes the slow producer problem but we are trying to verify that it as not caused any other regressions.

          Show
          chirino Hiram Chirino added a comment - Update.. we are now currently evaluating and testing the attached patch. It fixes the slow producer problem but we are trying to verify that it as not caused any other regressions.
          Hide
          garytully Gary Tully added a comment -

          fix from https://issues.apache.org/activemq/browse/AMQ-1866 is now on fuse fixes branch ready for .19 release.

          Show
          garytully Gary Tully added a comment - fix from https://issues.apache.org/activemq/browse/AMQ-1866 is now on fuse fixes branch ready for .19 release.

            People

            • Assignee:
              chirino Hiram Chirino
              Reporter:
              martinmurphy Martin Murphy
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: