ActiveMQ
  1. ActiveMQ
  2. AMQ-2217

Message delivery to selector based consumers pauses if selector leaves messages on the queue.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.1.0, 5.3.0
    • Fix Version/s: 5.4.1
    • Component/s: Broker
    • Labels:
      None
    • Environment:

      Windows XP Professional 2002, Service Pack 2, Intel Pentium D 3ghz, various 1.5 and 1.6 versions of jdk

      Description

      I have written a test case which will demonstrate the difference between the following two scenarios:

      1. Producer sending dissimilar JMSType messages to a queue, with a client consuming all messages (no selector).
      2. Producer sending dissimilar JMSType messages to a queue, with a client consuming every other message (using selector).

      With a large enough size of test messages (for my environment about 5k), scenario 2 will fail with delivery to the consumer halted, while scenario 1 will not.

      Test Output:

      waiting for consumer to pause ... consumer: 0, producer: 0
      waiting for consumer to pause ... consumer: 200, producer: 5000
      waiting for consumer to pause ... consumer: 200, producer: 5000
      waiting for consumer to pause ... consumer: 200, producer: 5000
      waiting for consumer to pause ... consumer: 200, producer: 5000
      waiting for consumer to pause ... consumer: 200, producer: 5000

        Issue Links

          Activity

          Hide
          Gary Tully added a comment -

          There is a workaround, demonstrated in the committed test case. Thanks for the neat test case btw.
          Increasing the maxPageSize from the default 200 to 5000 makes the test work. In xml config for all queues it would be something like:

          <destinationPolicy>
                      <policyMap>
                          <policyEntries>
                              <policyEntry queue=">" maxPageSize="5000"/>
                          </policyEntries>
                      </policyMap>
                  </destinationPolicy>
          Show
          Gary Tully added a comment - There is a workaround, demonstrated in the committed test case. Thanks for the neat test case btw. Increasing the maxPageSize from the default 200 to 5000 makes the test work. In xml config for all queues it would be something like: <destinationPolicy> <policyMap> <policyEntries> <policyEntry queue= ">" maxPageSize= "5000" /> </policyEntries> </policyMap> </destinationPolicy>
          Hide
          Gary Tully added a comment -

          The pageSize is the amount of messages that are pulled into memory by a destination prior to a dispatch, it needs to be large enough to bridge the gaps between messages with sparse selector distribution, otherwise messages of one type will halt the dispatch till they are consumed or expire. A sensible message expiry policy can help in tandem here.

          Show
          Gary Tully added a comment - The pageSize is the amount of messages that are pulled into memory by a destination prior to a dispatch, it needs to be large enough to bridge the gaps between messages with sparse selector distribution, otherwise messages of one type will halt the dispatch till they are consumed or expire. A sensible message expiry policy can help in tandem here.
          Hide
          Gary Tully added a comment - - edited

          This is a known limitation, with the Apollo (AMQ 6) project we will be able to address this architectural constraint.
          In the mean time, using a large maxPageSize, named queues at the application level, or filtered name virtual queues can provide an alternative strategy.

          Show
          Gary Tully added a comment - - edited This is a known limitation, with the Apollo (AMQ 6) project we will be able to address this architectural constraint. In the mean time, using a large maxPageSize, named queues at the application level, or filtered name virtual queues can provide an alternative strategy.
          Hide
          Saeid Mirzaei added a comment -

          Does this mean that there is no plan to fix it in future versions of ActiveMQ and not Appollo ?

          Show
          Saeid Mirzaei added a comment - Does this mean that there is no plan to fix it in future versions of ActiveMQ and not Appollo ?

            People

            • Assignee:
              Gary Tully
              Reporter:
              Jar Lyons
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development