In the JAAS login module for Kubernetes, the current implementation is
loading only a single CA from the bundle that is given by OpenShift,
which in turn leads to an issue where the broker don't find a proper
PKIX path.
This is fixing the issue by loading every certificates from the bundle.
When the ArtemisRbacMBeanServerBuilder class is used for the RBAC management,
a clash of authentication cache keys between clients failing authentication and
web console authenticated users can cause web console authenticated users to
receive authorization errors, blank screens and similar issues after successful
login to the console.
Add basic management views for AMQP broker connections and implement control
types for AMQP federation features along with the broker connection management
views. Some initial work also to provide support for other broker connection
features to add management control and also plan for future views of incoming
broker connections and management of AMQP federation resources.
When you start the broker without configuring HAPolicy, if clients
call this management api it'll get NPE because it doesn't check
if the HAPolicyConfiguration is null.
177e6820b541e0a71b952eebf503a4d2235910c5
e34fd09ce325a551bf2eaf579854e2e107435502
e065d25b6fb4cdfa7f5b72afd52d6f4771b50634
af9bd7b84aad32e4fe30f2c8909e51cf7300b475
f4bdacbc4cb46b308f80391940890c74bf111ecd
74951d9221b29336c6575de9390a8557114e10eb
fe0ca4d84fc587b701e4b83ae8e5f2240c222842
b08b91a32faa89cdff4403b532e60d96084f2d4a
85857ab8eb1b1eca2498306239740e0e39d2acd4
e02ec69021f24220c0b91b8324382c9630415276
bf9f6d213bf6b3bf4fd7e15430ada8c9954e69ce
2d806807b8d9006cf642392ad5da9878394cebae
52a4157bbb898ee8fd8d7f13fffca71a9c368630
53bb3ea1833cddda6c2ded70d3149286c8207570
d5f152c7254c378707b12ad4a0b798fdb8cb7b10
b3529dcea428fa697aacbceacc6641e47cfb74ba
246bf083914c7acbb05a7fe0904c471331242c39
8a04ee07de8a7c863daf37a07a1176131151caa0
6cb68f2ce923ea3c2400c21967b2003175c8a0f4
9873fccf744c0cb0a25dd905fab67ea52ef7aa7d
See PR for individual commits which were squashed to form this change. This closes#5320
The broker uses unique IDs for logging statements. As logging changes
over time we need a way to "retire" these IDs (e.g. when certain
logging statements are no longer needed) to ensure they are not used
This commit does the following:
- Removes all the logging methods which are no longer used and
"retires" the corresponding ID (i.e. adds them to the `retiredIDs`
list for that LogBundle).
- Updates the validation for IDs that have been retired or are in
active use including a new suggestion about a valid ID to use when an
invalid ID is found.
- Fixes all the regular expressions in all the various uses of
`@LogBundle` to ensure there are no overlaps to prevent duplicates
between bundles.
Changes from myself and Robbie Gemmell (see PR). This closes#5303.
Throughout the years, the standard mechanism for storing passwords has evolved.
In the beginning, passwords were stored in plaintext. Developers are now
encouraged to leverage adaptive one-way functions to store a password. Using a
two-way function by default for storing passwords without a warning could lead
users to a false sense of security.
Adds support for WebSocket compression using the netty server handler to
enable per message compression and decompression as a transparent layer of
the netty pipeine.
This commit adds support for a NOT_EQUALS operator to the management
operations which already support filtering.
It also adds a handful of tests for the predicate since there didn't
seem to be any such tests.
Throwing an exception when clearing the bindings when a
cluster-connection is closed short-circuits the clearing (and closing)
process. This commit fixes that by simply logging the failure to clear
and continues on.
No new tests are added with this commit. It relies on existing tests.
PriorityLinkedList has multiple sub-lists, before this commit PriorityLinkedList::setNodeStore would set the same node store between all the lists.
When a removeWithID was called for an item on list[0] the remove from list[4] would always succeed first. This operation would work correctly most of the time except
when tail and head is being used. Many NullPointerExceptions would be seen while iterating on the list for remove operations, and the navigation would be completely broken.
A test was added to PriorityLinkedListTest to make sure the correct lists were used however I was not able to reproduce the NPE condition in that test.
AccumulatedInPageSoakTest reproduced the exact condition for the NPE when significant load is used.
We've traditionally used org.apache.activemq.artemis.utils.Base64 for
Base64 encoding/decoding. This implementation is based on public domain
code from http://iharder.net/base64.
In Java 8 java.util.Base64 was introduced. I assumed we hadn't switched
to this implementation for performance reasons so I created a simple
JMH-based test to compare the two implementations and it appears to me
that java.util.Base64 is significantly faster than our current
implementation. Using the JDK's class will simplify our code and
improve performance. Also, it should be 100% backwards compatible
since Base64 encoding/decoding is standardized.
When an AMQP message is sent over a cluster bridge it is embedded into a
Core message. If the size of the AMQP message is barely beneath the
minLargeMessageSize then the Core message in which the AMQP message is
embedded will become a large message. The on the bridge target when the
embedded AMQP message is extracted from the large Core message it will
not be considered "large." In this situation the file for the large Core
message will leak.
Thanks to Erwin Dondorp for the test. I renamed and refactored it a bit,
but the fundamentals came from Erwin.
For embedded use-cases the Micrometer MeterRegistry may be passed in
from the application and used for other meters unrelated to the broker.
Therefore, the broker should not change the config of the MeterRegistry
(e.g. by adding common tags to all meters) as the config change(s) may
be incompatible with the needs of the embedding application.
Allow the client ID to be configured on normal bridge as well as
cluster-connection bridges. This makes the bridge connection easier to
identify on the target broker.
This is a small usability improvement for management whereby
invocations of some operations no longer require JSON boilerplate. It
impacts the following operations on the ActiveMQServerControl:
- listConnections
- listSessions
- listAddresses
- listQueues
- listConsumers
- listProducers
