-
Bug
-
Resolution: Done
-
Major
-
JBoss A-MQ 6.2
-
None
Using durable topic subscriptions it is possible for offline durable topic subscriptions to exceed the destination memory limit as well as the system memory limit.I have broker which is configured as follows:| <destinationPolicy>|
| <policyMap> |
| <policyEntries> |
| <policyEntry topic=">" producerFlowControl="true" memoryLimit="1mb" usePrefetchExtension="false"> |
| </policyEntry> |
| <policyEntry queue=">" producerFlowControl="true" memoryLimit="1mb"> |
| </policyEntry> |
| </policyEntries> |
| </policyMap> |
| </destinationPolicy> |
| ... |
| <systemUsage> |
| <systemUsage> |
| <memoryUsage> |
| <memoryUsage limit="250 mb"/> |
| </memoryUsage> |
| <storeUsage> |
| <storeUsage limit="100 gb"/> |
| </storeUsage> |
| <tempUsage> |
| <tempUsage limit="50 gb"/> |
| </tempUsage> |
| </systemUsage> |
| </systemUsage> |
Full config is attached.In this scenario there are two durable topic subscription, though one only consumes a few messages and then goes offline while the other remains online and consumes messages.The offline durable topic subscription will continue to receive pending messages until the heap is exhausted causing an "java.lang.OutOfMemoryError: GC overhead limit exceeded" to occur.in my test a heap dump reveal the following about the durable subscription memory usage:One instance of "org.apache.activemq.broker.region.DurableTopicSubscription" loaded by "org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ 0x7e1a916d0" occupies 395,238,672 (76.24%) bytes. The memory is accumulated in one instance of "org.apache.activemq.broker.region.cursors.OrderedPendingList" loaded by "org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ 0x7e1a916d0".Or:Class Name | Objects | Shallow Heap | Retained Heap
----------------------------------------------------------------------------------------------------
org.apache.activemq.broker.region.DurableTopicSubscription| 2 | 304 | >= 395,240,480
----------------------------------------------------------------------------------------------------This shows that one instance on the Durable Topic Subscription is using 395MB when it should have been limited to 1MB. This also far exceeds the brokers system memory limit which was configured at 250MB.While the test is running you can observe that offline durable subscription's CursorMemoryUsage appears to jump up and down in values as it would be expected if messages were actually being enqueued and dequeued. But in this case the PendingQueueSize is constantly increasing.
