Handle any exceptions from the proton transport and set the error on the
transport for processing in the events dispatch cycle by adding in handling
of the transport error event.
Updates artemis-log-annotation-processor to use artemis-project so that
artemis-pom can reference artemis-log-annotation-processor without cycle.
Split out its tests to their own module to faciltate, also exercising the
profile mechanism to enable the processor usage with trigger file.
Simplify disabling processing in the module using maven.compiler.proc prop
available since maven-compiler-plugin 3.13.0
Uses a dummy non-processor path at root to 'disable' processsing on JDK < 23,
accounting for Maven 3 not being able to unset maven.compiler.proc from a
parent, and JDKs < 21 requiring newest builds to support -proc:full value
needed otherwise to reenable processing once explicitly disabled.
This commit uses lambdas or method references wherever possible. There
are still a handful of places that appear like they could be changed but
couldn't mainly because they use "this" and the meaning of "this"
changes when using a lambda.
When setting expiration on the AMQPMessage the AMQP header TTL value
should be read as an unsigned integer and as such should use the longValue
API of UnsignedInteger to get the right value to set expiration.
When checking if address federation can be done the manager needs to look
at the policy level settings before looking at federation or connector
level settings for amqp credits.
This commit does the following:
- deprecate all QueueConfiguration ctors
- add `of` static factory methods for all the deprecated ctors
- replace any uses of the normal ctors with the `of` counterparts
This makes the code more concise and readable.
The receiver attach in broker connection does not wait for the remote
attach to arrive before creating the broker side receiver plumbing which
leads to the broker treating the remote sender as an anonymous relay when
it is not and should not be. Await the remote attach in response to the
attach sent by the broker connection to finish the link setup but use the
locally defined target address vs the remote to route the incoming messages.
When caching address query results the remote session can be blocked forever
from creating links on an address if the "does not exist" value is cached
since it is never updated again and will always report "does not exist" even
if the address is added manually via management later. The cache state can
cause other issues for long running sessions as well and should be removed
to avoid attach failures for cases where the current broker state could allow
the attach to succeed but the cached entry won't allow it.
This commit does the following:
- deprecate the verbosely named `toSimpleString` static factory
methods
- add `of` static factory methods for all the ctors
- replace any uses of the normal ctors with the `of` counterparts
This makes the code more concise and readable.
Allow the Source address to provide consumer priority on the address using the
same option value as a core consumer '?consumer-priority=X'. The change parses
any query string appended to an address and uses the address portion as the
actual receiver address and currently only looks at consumer priority values in
the extracted address query parameters and ignores any other options found. The
existing consumer priority taken from link properties takes precedence over the
value placed on the address query options if both are present.
Race on consumer create and broker shutdown could lead to a deadlocak trying
to access configuration from the policy manager while the federation instance
is trying to shutdown the policy manager.
If the writer is closed while flow controlled write attempts are pending in the
connection executor an NPE is thrown which should be avoided as the closed state
should trigger the writes to stop. Add fix and test that checks that this works
as it should.
This commit fixes the deadlock described on ARTEMIS-3622 by moving the
synchronization "up" a level from the MQTTSession to the
MQTTConnectionManager. It also eliminates the synchronization on the
MQTTSessionState in the MQTTConnectionManager because it's no longer
needed. This change should not only eliminate the deadlock, but improve
performance relatively as well.
There is no test associated with this commit as I wasn't able to
reproduce the deadlock with any kind of straight-forward test. There was
a test linked on the Jira, but it involved intrusive and fragile
scaffolding and wasn't ultimately tenable. That said, I did test this
fix with that test and it was successful. In any case, I think static
analysis should be sufficient here as the changes are pretty
straight-forward.
This is a list of improvements done as part of this commit / task:
* Page Transactions on mirror target are now optional.
If you had an interrupt mirror while the target destination was paging, duplicate detection would be ineffective unless you used paged transactions
Users can now configure the ack manager retries intervals.
Say you need some time to remove a consumer from a target mirror. The delivering references would prevent acks from happening. You can allow bigger retry intervals and number of retries by tinkiering with ack manager retry parameters.
* AckManager restarted independent of incoming acks
The ackManager was only restarted when new acks were coming in. If you stopped receiving acks on a target server and restarted that server with pending acks, those acks would never be exercised. The AckManager is now restarted as soon as the server is started.
When creating internal temporary queues for the federation control links and the
events link we should use a structured naming convention to ease in configuring
security for the federation user where all internal names fall under a root prefix
which can be used to grant read and write access for the federation user. This
change allows security on the wildcarded address "$ACTIVEMQ_ARTEMIS_FEDERATION.#".
This change also includes some further restrictions added to federation resources
and adds support for wildcarding '$' prefixed addresses.
The resume delivery on AMQP Large Message Writer is using runNow.
When a flow control is paused and then resumed, the runNow will make the first read to happen inline to the thread that's resuming other deliveries.
It would be better to not run the delivery within the same call. Hence the change here is simple, being just using a connection.runLater instead of runNow.
I have seen this on a thread dump from a production server.
No semantic issues were encountered but there was a theory that the Netty thread responsible to resume would be busy with a delivery when not supposed to.
Better to be safe on this case.
Allow for configuration of the batch size granted to the remote when an
AMQP federation queue receiver is pulling messages only when there is
local capacity to handle them. Some code housekeeping is done here to
make adding future properties a bit simpler and require fewer changes.
Create a new NettyConnector for each connection attempt that is configured from
distinct broker connection URIs which allows for differing TLS configuration
per remote connection configuration.
Fix the AMQP message scanning to account for the header not being at the
front of the buffer which also accounts for odd case of broker storing
message with delivery annotations ahead of the header.
The local variable constructorPos is initialized with the value of
buffer.position() in line 330, but the variable itself is not used
anywhere else, which may indicate an error.
In 1st branch (line 274) of the if() statement, the
Boolean.parseBoolean() method accepts the value
frame.getHeader(Stomp.Headers.Subscribe.NO_LOCAL), which is used in line
273.
In 2nd branch (line 276), the Boolean.parseBoolean() method accepts the
value frame.getHeader(Stomp.Headers.Subscribe.NO_LOCAL), although the
other value frame.hasHeader(Stomp.Headers.Subscribe.ACTIVEMQ_NO_LOCAL)
is used.
Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author A. Slepykh.
This is particularly true for the Mirrored SNF queue. Redistribution is not meant for internal queues. If an internal queue happens to have the same name on another server, it should not trigger redistribution when consumers are removed.
It would be possible to work around this by adding an address-setting specific to the address with redistribution disabled.
ClusteredMirrorSoakTest was intermittently failing because of this. For a few seconds while the mirror connection is still being made connections could move messages from one node towards another node if both have the same name.
When federation is configured in two directions between nodes for an address
the message can reflect from one node to another if max hops is not set or not
set correctly and in some federation topologies the max hops value can't solve
the issue and still result in a working configuration. This reflection should
be prevented at the federation consumer level for address consumers.
Timothy Bish
Justin Bertram
Clebert Suconic
Robbie Gemmell
aslepykh