FQQN support for the CLI was implemented via ARTEMIS-1840 before general
FQQN support was added for producers via ARTEMIS-1867. The CLI's FQQN
functionality is slightly different from what is now generally available
and it can be confusing for users. By refactoring the CLI to use the
general FQQN support the code can be much simpler and consistent with
the expected behavior. Refactoring includes:
- Deprecating the use of "fqqn://". The CLI commands use JMS so using
"fqqn://" (instead of "queue://" or "topic://") makes the destination
type ambiguous which can yield unexpected message routing behavior.
Now "queue://" and "topic://" can be used with the normal FQQN syntax
(e.g. address::queue).
- Eliminating the use of the _AMQ_ROUTE_TO header when sending messags
to an FQQN. The _AMQ_ROUTE_TO header is an internal header used when
routing messages over a cluster bridge. Using it in the CLI for FQQN
support was a clever hack, but using the general FQQN support
eliminates complexity and makes behavior consistent between
standalone JMS clients using FQQN and the CLI.
- De-duplicating MessageSerializer initialization boilerplate.
- Removing limitation where using an FQQN with an anycast address
required the same name for the address and queue.
This is a Large commit where I am refactoring largeMessage Body out of CoreMessage
which is now reused with AMQP.
I had also to fix Reference Counting to fix how Large Messages are Acked
And I also had to make sure Large Messages are transversing correctly when in cluster.
There is an optimization in AMQP, that properties are only parsed over demand.
It happens that after ARTEMIS-2294 (commit 2dd0671698),
every send would request for the property on the message, resulting the properties to always be parsed upon send.
Even when there's no use of application properties.
Add the config parameter `page-sync-timeout` to set a customized value,
because if the broker is configured to use ASYNCIO journal, the timeout
has the same value of NIO default journal buffer timeout ie 3333333.
* Upgrading versions
* Adding wildfly-common dependency as jboss-logmanager now depends on it
for simple common operations such as getting hostname or process id
* Updating bootclasspath with wildfly-common
The Audit log allows user to log some important actions,
such as ones performed via management APIs or clients,
like queue management, sending messages, etc.
The log tries to record who (the user if any) doing what
(like deleting a queue) with arguments (if any) and timestamps.
By default the audit log is disabled. Through configuration can
be easily turned on.
brusdev
Clebert Suconic
Justin Bertram
Francesco Nigro
Wei Yang
Shailendra Kumar Singh
Emmanuel Hugonnet
Jiri Danek
Howard Gao