Scenario on client:
1. Employing RedeliveryPolicy with exponential backoff (keeping maximum
redeliveries at default 6)
2. Enabled non-blocking redelivery
3. Receiving e.g. 100 consecutive poison messages (which eventually
should DLQ after max redeliveries)
This will result in massive redelivery delays due to a logic bug.
The reason is that redeliveryDelay is a field variable kept on the
ActiveMQMessageConsumer, instead of being a property on the message - or
that the redelivery delay was calculated per message based on the
redelivery count.
When consecutive messages rollbacks multiple times, the redeliveryDelay
field is continuously multiplied by the backoff multiplier, resulting in
enormous delays.
Fix: Ditch the field variable, instead calculating the redeliveryDelay
per delivery from the redelivery count. (This happens to be identical to
how it is done in afterRollback() in ActiveMQSession:1004.)
Test is added - which fails with the previous code, and passes with
this. Added a debug log line for the calculated delay.
Inside ActiveMQSslConnectionFactory the passwords should be checked for
null so a NPE isn't thrown. Null will be passed to the factories instead
and the keystore/truststore factories will try and load the keystores
using null for the password which may or may not work depending on the
implementation and if password is set.
-DurableFiveBrokerNetworkBridgeTest: Fix refactoring mistake
-SpringTest: Fix Spring xml files
-BrokerRedeliveryTest: Fix after sendDuplicateFromStoreToDLQ default
changed to false
-AMQ4952Test: Fix after sendDuplicateFromStoreToDLQ default
changed to false
-AMQ3537Test: Add missing package to SERIALIZABLE_PACKAGES
-OfflineDurableSubscriberTimeoutTest: Fix after log4j2 update
-JDBCConcurrentDLQTest: Fix after log4j2 update
Updates the modules part of the previous full.test profile to always
build but skip running tests by default.
Also fixed miss dependency updates including log4j and jetty
- Handle in the OpenWireFormat class
- Add unit tests to confirm
- Verify compression is accounted for
- Verify the ability to disable using wireFormat.maxFrameSizeEnabled=false
- [cshannon] Reworked max frame size test case to add in all transports and all client/server cases
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.
- API update only
- Throw UnsupportedOperationException
- Disable activemq-camel from build
- Formatting fixes
- Use geronimo-jms for osgi-related artifacts
- Fix features.xml invalid xml header
- Add a unit test to confirm JMS 2.0 methods for phase 1 (throw UnsupportedOperationException)
- Add deliveryTime field to Message
- Minor formatting fixes
This enables possibility to send messages containing commas in the body
with tools such as jconsole.
Example simple text as body: body=Hello, world!
Example json as body: body={"a":"b","c":"d"}
This makes sure the nio transport thread properly terminates if
maxFrameSize is exceeded with OpenWire to prevent an infinite loop that
uses up all the cpu
Endre Stølsvik
Jean-Baptiste Onofré
Matt Pavlovich
Christopher L. Shannon
Alexej Timonin
gtully
charlie-aws
Jonathan Gallimore
kimmking
Marcono1234
Roman Nevezhyn
murali.mogalayapalli
dhmgit
Colm O hEigeartaigh