This PR adds a "Validated User" column to the Hawtio plugin. The column is
not visible by default. The "Validated User" column is available in the
Session, Consumer, and Producer tabs of the artemis-navigation notebook.
"Validated User" is also available for sort and filtering in those view.
The "Validated Consumer" in the Producer view is always blank. I debugged
as far as I could, but did not find the cause of the issue.
It is possible to receive a compressed message from the client as regular message. Such a message will already contain correct body size, that takes compression into account.
Older versions of Openwire clients wil be affected by AMQ-6431.
As a result of the issue if the ID of the message>Integer.MAX_VALUE
a consumer configured with Failover and doing duplicate detection on the client
will not be able to process duplicate detection accordingly and miss messages.
Paging only removes files at the beginning of the stream...
Say you have paged files 1 through 1000...
if all the messages are ack, but one message on file 1 is missing an ack, all the 999 subsequent files would not be removed until all the messages on file 1 is ack.
This was working as engineered, but sometimes devs don't have complete control on their app.
With this improvement we will now remove messages in the middle of the stream as well.
There is also some improvement to how browsing and page work with this
The utility methods in
`org.apache.activemq.artemis.core.management.impl.MBeanInfoHelper` are
executed *a lot* - especially for Jolokia which is used by the web
console. The `MBeanOperationInfo` and `MBeanAttributeInfo` results are
static and reflection is slow therefore they should not be calculated
over and over again. Rather they should be calculated once and cached
for later use.
Caching these results significantly improves performance. Over the
course of 1,000,000 invocations the difference is several orders of
magnitude. This improves usability substantially when dealing with,
for example, tens of thousands of addresses and/or queues.
When using a temporary queue with a `temporary-queue-namespace` the
`AddressSettings` lookup wasn't correct. This commit fixes that and
refactors `QueueImpl` a bit so that it holds a copy of its
`AddressSettings` rather than looking them up all the time. If any
relevant `AddressSettings` changes the
`HierarchicalRepositoryChangeListener` implementation will still
refresh the `QueueImpl` appropriately.
The `QueueControlImpl` was likewise changed to get the dead-letter
address and expiry address directly from the `QueueImpl` rather than
looking them up in the `AddressSettings` repository.
I modified some code that came from ARTEMIS-734, but I ran the test that
was associated with that Jira (i.e.
`o.a.a.a.t.i.c.d.ExpireWhileLoadBalanceTest`) and it passed so I think
that should be fine. There actually was no test included with the
original commit. One was added later so it's hard to say for sure it
exactly captures the original issue.
It sometimes makes sense to set an acceptor's port to 0 to allow the JVM
to select an ephemeral port (e.g. in embedded integration tests). This
commit adds a new getter on NettyAcceptor so tests can programmtically
determine the actual port used by the acceptor.
This commit also changes the ACCEPTOR_STARTED notification and the
related logging to clarify the actual port value where clients can
connect.
The auto-create-jms-queues, auto-delete-jms-queues,
auto-create-jms-topics, and auto-delete-jms-topics address settings
were deprecated in ARTEMIS-881 way back in 2016. There's no need to keep
them in the default broker.xml at this point.
JGroups 3.x hasn't been updated in some time now. The last release was
in April 2020 almost 2 years ago. Lots of protocols have been updated
and added and users are wanting to use them. There is also increasing
concern about using older components triggered mainly by other
recently-discovered high-profile vulnerabilities in the wider Open
Source Java community.
This commit bumps JGroups up to the latest release - 5.2.0.Final.
However, there is a cost associated with upgrading.
The old-style properties configuration is no longer supported. I think
it's unlikely that end-users are leveraging this because it is not
exposed via broker.xml. The JGroups XML configuration has been around
for a long time, is widely adopted, and is still supported. I expect
most (if not all) users are using this. However, a handful of tests
needed to be updated and/or removed to deal with this absence.
Some protocols and/or protocol properties are no longer supported. This
means that users may have to change their JGroups stack configurations
when they upgrade. For example, our own clustered-jgroups example had to
be updated or it wouldn't run properly.
MQTT 5 is an OASIS standard which debuted in March 2019. It boasts
numerous improvments over its predecessor (i.e. MQTT 3.1.1) which will
benefit users. These improvements are summarized in the specification
at:
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901293
The specification describes all the behavior necessary for a client or
server to conform. The spec is highlighted with special "normative"
conformance statements which distill the descriptions into concise
terms. The specification provides a helpful summary of all these
statements. See:
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901292
This commit implements all of the mandatory elements from the
specification and provides tests which are identified using the
corresponding normative conformance statement. All normative
conformance statements either have an explicit test or are noted in
comments with an explanation of why an explicit test doesn't exist. See
org.apache.activemq.artemis.tests.integration.mqtt5 for all those
details.
This commit also includes documentation about how to configure
everything related to the new MQTT 5 features.
The address-setting config-delete-diverts is not being applied correctly
hierarchically because it's not included in the merge() method. It is
also not being persisted to disk either. This commit fixes both issues.
scenario - avoid paging, if address is full chain another broker and produce to the head, consume from the tail using producer and consumer roles to partition connections. When tail is drained, drop it.
- adds a option to treat an idle consumer as slow
- adds basic support for credit based address blocking ARTEMIS-2097
- adds some more visiblity to address memory usage and balancer attribute modifier operations
The HTML output methods are hold-overs from way back when the code-base
started off as JBoss Messaging 2 and the broker mainly ran in JBoss AS 4
and 5 which leveraged an HTML-based JMX console where these methods
would be executed and spit out nicely formatted data. That stuff has all
long since been retired so this commit deprecates the HTML-based
management methods so they can be removed completely in a future release.
JSON is a better structured output format for this and most of the
deprecated methods have JSON alternatives.
Commit 481b73c8ca from ARTEMIS-3502
inadvertently broke this functionality. This commit restores the
original behavior.
autoDeleteAddress was renamed to forceAutoDeleteAddress which will ignore the address settings.
delete temporary queues will use forceAutoDeleteAddress=true.
this is done in collaboration with Justin Bertram
Adds support for extra configuration options to LDAP login module to
prepare for supporting any future/custom string configuration in LDAP
directory context creation.
Details:
- Changed LDAPLoginModule to pass any string configuration not
recognized by the module itself to the InitialDirContext contruction
environment.
- Changed the static LDAPLoginModule configuration key fields to an
enum to be able to loop through the specified keys (e.g. to filter out
the internal LDAPLoginModule configuration keys from the keys passed to
InitialDirContext).
- Few fixes for issues reported by static analysis tools.
- Tested that LDAP authentication with TLS+GSSAPI works against a
recent Windows AD server with Java
OpenJDK11U-jdk_x64_windows_hotspot_11.0.13_8 by setting the property
com.sun.jndi.ldap.tls.cbtype (see ARTEMIS-3140) in JAAS login.conf.
- Moved LDAPLoginModuleTest to the correct package to be able to
access LDAPLoginModule package privates from the test code.
- Added a test to LDAPLoginModuleTest for the task changes.
- Updated documentation to reflect the changes.
While converting a core message to an OpenWire message there may be an
error processing a property value. Currently this results in an
exception and the message is not dispatched to the client. The broker
eventually attempts to redeliver this message resulting in the same
error. Instead of throwing an exception the broker should simply log a
WARN message and skip the property. This will allow clients to receive
the message without the problematic property and the broker will not
have to attempt to redeliver the message again.
Justin Bertram
Clebert Suconic
Gary Tully
aaron.hoffer
iliya
Robbie Gemmell
Domenico Francesco Bruscino
nbrendah
franz1981
AntonRoskvist
Matteo Baccan
Emmanuel Hugonnet
Luis De Bello
Marlon Müller
Erwin Dondorp
Asukwo-comfort
pahamala
Andy Taylor
JiriOndrusek