1

We are using ActiveMQ 5.6 with the following configuration: - Flow control on - Memory limit for topics 1MB - Mirror Queues enabled (no explicit Virtual Topics defined)

There are persistent messages being sent to a queue QueueA. Obviously, this message is copied to Mirror.QueueA which is a non persistent and automatically created topic.

On this topic, there are no consumers. If there are consumers once in a while, they are non-durable subscribers.

After a while, the producer blocks and we get the following error:

Usage Manager memory limit reached for topic://Mirror.QueueA

According to various sources including the ActiveMQ documentation, there messages in a topic without durable subscribers will be dropped which is what I want and what had expected. But this is obviously not the case.

There is one related StackOverflow question but the accepted solution suggests using flow control but disabling disk-spooling:

That would not use the disk, and block producers when the memoryLimit is hit.

But I do not want to block producers because they will block indefinitely because there is no consumer coming. Why are these messages are being persisted?

I see few options: - This is a bug and probably fixed in later AMQ versions - This some configuration issue (of which I don't know how to resolve it) - There is some option to simply drop the oldest message when the memory limit is hit (I couldn't find any such option)

I hope someone can help!

Thanks,

//J

[Update]

Although we have already deployed versions of 5.6 out in the field, I am currently running the same endurance/load test on a 5.8 installation of AMQ with the same configuration. Right now, I have already transmitted 10 times the messages as on the 5.6 system without any issues. I will let this test run over night or even the next days to see if there is some other limit.

Community
  • 1
  • 1
jaw
  • 932
  • 2
  • 10
  • 24

1 Answers1

2

Ok,

as stated in the update before, I was running the same laod test on a 5.8 installation of ActiveMQ with the same configuration that cause the storage exceedance.

This was happening after approximately sending 450 transactions into 3 queues with a topic memory limit of 1MB. You could even watch the size of the KahaDB database file growing.

With AMQ 5.8, I stopped the load test after 4 days resulting in about 280.000 transactions sent. No storage issues, no stuck producer and the KahaDB file stayed approximately the same size all the time.

So, although I cannot say for sure that this is a bug in ActiveMQ 5.6, 5.8 is obviously behaving differently and as expected and documented. It is not storing message in the mirrored queues persistently when no subscriber is registered.

For existing installations of AMQ 5.6, we used a little hack to avoid changing the application code.

  • Since the application was consuming from topics prefixed with "Mirror." (the default prefix) and some wildcards, we simply defined a topic at start-up in the configuration using the <destinations> XML tag. Where wildcards were used we just used a hardcoded name like all-device. This was unfortunately required for the next step:
  • We defined a <compositeQueue> within the <destinationInterceptors> section of the config that routed copies of all messages (<forwardTo>) from the actual (mirrored) queue to one topic. This topic needs to be defined in advance or being created manually since simply defining the compositeQueue does not also create the topic. Plus, you cannot use
  • Then we removed the mirrored queue feature from the config

To sum it up, it looks a bit like this:

    <destinations>
        <topic name="Mirror.QueueA.all-devices" physicalName="Mirror.all-devices" />
    </destinations>

    <destinationInterceptors>
      <virtualDestinationInterceptor>
        <virtualDestinations>
          <compositeQueue name="QueueA.*" forwardOnly="false">
            <forwardTo>
              <topic physicalName="Mirror.QueueA.all-devices" />
            </forwardTo>
          </compositeQueue>
        </virtualDestinations>
      </virtualDestinationInterceptor>
    </destinationInterceptors>

Hope this helps. This "hack" may not be possible in every situation but since we never consumed on individual Mirror topics, this was possible.

jaw
  • 932
  • 2
  • 10
  • 24