since the last release , the xmx and xms are hardcoded on `env` , the goal is to use ACTIVEMQ_OPTS_MEMORY environement variable if needed to override memory options
(cherry picked from commit 1ba4628be6)
* [AMQ-7358] Use jetty atomic jar files instead of jetty-all uber jar
(deprecated according to Jetty team)
[AMQ-8461] Upgrade to Jetty 9.4.45.v20220203
(cherry picked from commit fa461c876a)
Add a unit test to the previous tests added in AMQ-7085 to verify
TempUsage is cleaned up and stopped on Queue.stop()
(cherry picked from commit df354fa023)
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.
(cherry picked from commit d1e9ba68b3)
Verify that maxFrameSizeEnabled being configured on the client or the
server is not negotiated and won't affect the other
(cherry picked from commit 26a3c55833)
- 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
(cherry picked from commit 67a2edbf0d)
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.
(cherry picked from commit 9167a79b79)
- Store maxFrameSize on client-side
- Check messages on outbound send to send an actionable exception to the caller
- Add a reason code for max message size exceeded (client-side)
(cherry picked from commit 48d0fb1171)
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"}
(cherry picked from commit 7c63227003)
Jean-Baptiste Onofré
Mikhail Pavlovich Sidorenko
Matt Pavlovich
Robbie Gemmell
Christopher L. Shannon
Lucas Tétreault
ilyes Ajroud
Cesar Hernandez
Artur Pedroso
Colm O hEigeartaigh
Endre Stølsvik
Alexej Timonin