- a test case which demonstrates the bug.
- the first test case sendDelayedMessage_usingNormalProducer works fine because it is using a normal named JMS MessageProducer. Included just for comparison purposes.
- the 2nd test case sendDelayedMessage_usingAnonymousProducer shows the bug.
- the bug fix: swap the order of the AdvisoryBroker and SchedulerBroker BrokerFilters.
- make AdvisoryBroker come after SchedulerBroker but before RegionBroker
- this ensures that when a delayed message gets eventually forwarded to the RegionBroker, the RegionBroker will "see" the AdvisoryBroker when it invokes 'addDestination'. Thus, the AdvisoryBroker gets to send out the advisory message as expected.
(cherry picked from commit 573ae71ec9197ae7392941239912bd62e7db2c87)
This fixes network subscriptions that are generated on demand when a
consumer uses composite destinations. Before this fix conduit
subscriptions didn't work correctly. This fix now splits up the
composite dest and generates correct demand for each of the individual
destinations.
(cherry picked from commit 901956d4ddb6a0ea9fe5fedf39732117ab68f087)
This fixes the rollback after the latest changes by using the
originalDestination property to look up the correct message audit on
rollback
(cherry picked from commit 459388185a3acd3a175d304b08af3c638e870292)
A store directory is created by MessageDatabase#getPageFile which
is called in two cases:
1. KahaDBStore.start() when creating a queue
2. KahaDBStore.size() which is performed when sending any persistent message
If both methods are called concurrently it's possible to get an IOException
thrown from the IOHelper.mkdirs method.
(cherry picked from commit 7de7ba2aa92dd1a98f48175fac5a538bd6e8579b)
This is best practice and will prevent unlock from being attempted
inside of a finally block when the thread doesn't actually own the
lock which can happen when the lock attempt throws an exception
such as calling lockInterruptibly()
(cherry picked from commit ed924cddac90b96bdc47b215852a68155d818bcd)
MemoryTransactionStores
This fixes a NPE when using the messageDelivered advisory and
transactions
(cherry picked from commit f83c5f1ba156ed850acf76dc42f944b4150d21f8)
Topic subscriptions expire a message
This fixes topic subs to send the right advisory type, if enabled, when
the server discards a message on dispatch to a topic sub. Also add some
more expiration tests for other subscription types
(cherry picked from commit 757a712890996d71cf380c56fc2cefbd5a82ec88)
current dispatched count
The previous way of computing the count of using total dispatched minus
total dequeued didn't work in the case of destination removal and
messages were not acked. The counter is needed as the dispatched list is
optional unlike prefetch subs.
(cherry picked from commit 8554a1464c6471f81ebbcd6c482376ae32cf6808)
managed region broker
This new approach just looks matching Subscriptions from the region for the
destination which prevents having to store another map and falls back to
the old approach if something went wrong.
(cherry picked from commit d46b74d674c2a67193bb95384290da266adf9a25)
Due to changes with Queues to check if consumers are full before adding
more messages to the subscription, the Queue dispatch logic needed to be
updated to mark subscriptions as slow and send advisories if configured
instead of relying on the subscription itself to do it.
(cherry picked from commit 596ee316874894ad0342475d8f242913bd507cd1)
If you have an application that creates lots of queues it will eventually
fail with OOM because TempUsage is started on Queue#start but never stopped.
The `systemUsage.getTempUsage().start()` used on the Queue#start
adds elements on a List from TempUsage parent and these elements
are never removed.
To reproduce this issue you need to leave an application
running for a long time creating different queues.
The only way to avoid the leak right now is to stop the BrokerService,
which isn't a solution.
Adding a feature (STATS_FIRST_MESSAGE_TIMESTAMP) to the
StatisticsBrokerPlugin's destination-statistics for getting the
timestamp of the first message in the destination(s) being requested: If
you on the query-message set the property
StatisticsBroker.STATS_FIRST_MESSAGE_TIMESTAMP to anything (e.g. boolean
true), a long value "firstMessageTimestamp" will be added to the
statistics reply message(s). Since the reply message has JMSTimestamp
set, which is the broker's now-timestamp, you may also on the query side
calculate the age of the first message in milliseconds. The key name was
chosen since that is the name of the corresponding feature in Artemis.
This extension of the existing feature is implemented to be as
non-intrusive as possible, adding very little runtime cost if not
requested. It also seems like the runtime cost for enabling this
feature, thus finding and adding the firstMessageTimestamp, is small.
While at it, also slightly improving an existing feature
(STATS_DENOTE_END_LIST) where a reply to a destination query can be
"null terminated": After sending the relevant replies, the
StatisticsBroker also sends an empty message. This feature is relevant
if the query is a wildcard query, thus returning multiple messages: The
empty message denotes the end of the replies. However, to activate this
feature, a somewhat complicated query destination had to be constructed.
Adopting the solution for the other StatisticsBroker feature where you
may reset the broker statistics by adding a property to the query
message, this null-termination feature now /also/ checks for the
presence of this query modifier STATS_DENOTE_END_LIST as a property.
(This property based solution was thus also adopted for the present
'firstMessageTimestamp' solution, as it was found much more intuitive).
Added tests for both the STATS_FIRST_MESSAGE_TIMESTAMP query modifier,
and the improved STATS_DENOTE_END_LIST property-based query modifier.
Had to make the Topic.doBrowse(List browseList, int max) public - the
corresponding method for Queue was already public.
Made the evaluation of whether this is a StatisticsBroker-relevant
message a microscopic bit more performant (exiting faster if not
relevant): To the initial test of whether the message is relevant, which
only checked for replyTo being set, a check for 'destination.
startsWith("ActiveMQ.Statistics")' was added. Only if so, the rest of
the evaluations kick in. Also using 'string.startsWith(..)' instead of
the verbose 'string.regionMatches(..)'.
Removed an unused import on PartitionBrokerTest.java, as IntelliJ
complained about not finding it.
