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.
In order to better indicate their nature as broker feature specific queues
we can mark the temporary queues created for AMQP federation events and
control link messages as internal.
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.
Prevents unintended link stealing scenarios when link names match for a new
link whose name is in use by another link still awaiting a detach response.
If an exception is thrown in the AMQP send path and there is an
active transaction we should mark that as rollback only so the
client will see an error when it tries to commit a transaction
that had a failed send.
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 is only double testing.
Instead of parameterizing with or without forceNextValue(MAX_INT)
I'm just always forcing it. No point on duplicating the test just for this.
When the Core client attempts to create the initial connection to a
broker when initialConnectAttempts > 1 it will adhere to retryInterval,
but it will ignore retryIntervalMultiplier & maxRetryInterval. This
commit fixes that so that these parameters are taken into account.
When a bytes property is added to an AMQPMessage and it is then reencoded it
will fail without first wrapping the byte array in an AMQP binary as required
by the ApplicationProperties section specification defined type allowances.
There was already some verification at AMQPMirrorControllerSource::invalidTarget
however the verification failed on soak test ReplicatedBothNodesMirrorTest,
and an user I was working with also gave me evidence of this happening.
I'm improving the previous verification, which is actually a simplification that works on every case.
When converting a large server message to an outgoing STOMP frame the converter
is allowing unsafe concurrent access to the large message internals which leads
to failures on message deliver as the state is out of sync amongst the dispatch
threads.
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.
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.
When using the replay functionality the application of filters to
the replayed messages fails to match against AMQP messages due to the
message not getting scanned when some message values are accessed.
Ensure that on server restart the original priority value assigned to an
AMQP message is used when dispatching durable messages from the store.
The AMQP Header section is scanned if present and the priority value
is recovered in an efficient manner.
Send operations should ignore replication, while the ack of the message should wait a round trip in replication.
That will allow us to ack the message faster and still have consistency with its replica.
If a user for some reason force closes the local mirror connection SNF
consumer or the actual connection but hasn't stopped the broker connection
itself the connection should recover and rebuild. The fix ensures that if
local connections are closed first then local session resources get freed.
When an address consumer explicitly closes or is closed we should remove the
address binding for that consumer right away instead of waiting for possible
configured auto delete as the demand is gone and we don't need to binding to
stick around any longer.
The federation sender links can react incorrectly when the source broker
closes a receiver because the demand is gone and they can result in the
remote broker closing its side of the connection causing the whole federation
to need to be rebuilt. Handle the closure events correctly to prevent an
unexpected close and rebuild.
Move parameters out of base classes where needed to avoid clashes with
subclasses [re-]defining their own params. Needed due to change of
field + method annotation search handling to adopt Java hiding/shadowing
semantics, leading to ParameterizedTestExtension discovering both parent
and subclass parameter definition methods and throwing.
Clebert Suconic
Andy Taylor
Timothy Bish
Howard Gao
Justin Bertram
Domenico Francesco Bruscino
Jean-Pascal Briquet
Robbie Gemmell
Gary Tully