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.
This is the second commit. It improves the windows service
configuration file so that the service can be shutdown
gracefully (clean shutdown) and allow for a chance to
clean up the web tmp dir.
These improvements were also part of this task:
- Routing is now cached as much as possible.
- A new Runnable is avoided for each individual message,
since we use the Netty executor to perform delivery
https://issues.apache.org/jira/browse/ARTEMIS-2205
Optionally specify a queue routing type when creating a broker. Example:
"create --queues myqueue,mytopic:multicast". Defaults to anycast if
unspecified.
Added new cases:
- export from anycast queue, then import to multicast topic where number of queues > 1
- export from anycast queue, then import to multicast fqqn where number of queues > 1
- export from multicast topic, then import to anycast queue (both address)
- export from anycast queue, then import to multicast topic (both address)
Previously the port was always random. This caused problems with
remote JMX connections that needed to overcome firewalls. As of
this patch it's possible to make the RMI port static and whitelist
it in the firewall settings.
JMX configuration is now done via management.xml. Configuring JMX via
the start scripts could result in unexpected behavior since the
authorisation configuration from management.xml would be ignored.
Fix warning seen in logs during test case runs, caused by CF not being closed.
Oct 10, 2018 8:53:18 PM org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl finalize
WARN: AMQ212008: I am closing a core ClientSessionFactory you left open. Please make sure you close all ClientSessionFactories explicitly before letting them go out of scope! 639,542,871
java.lang.Exception
at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.<init>(ClientSessionFactoryImpl.java:171)
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:779)
at org.apache.activemq.artemis.cli.commands.messages.DestAbstract.getManagementSession(DestAbstract.java:103)
at org.apache.activemq.artemis.cli.commands.messages.DestAbstract.getQueueAttribute(DestAbstract.java:127)
at org.apache.activemq.artemis.cli.commands.messages.DestAbstract.getQueueIdFromName(DestAbstract.java:116)
at org.apache.activemq.artemis.cli.commands.messages.Producer.execute(Producer.java:75)
at org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:150)
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:98)
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:125)
at org.apache.activemq.artemis.cli.Artemis.main(Artemis.java:81)
Replace guava Preconditions with artemis Preconditions
Replace guava Predicate with java Predicate
Replace guava Ordering with java Comparator
Replace guava Immutable, with ArrayList/Set and then wrap with unmodifiable
cannot find login.config
The Windows variable ARTEMIS_ETC_INSTANCE was not set correctly,
as it was used as ARTEMIS_INSTANCE_ETC. So the fix is to make sure
that the two match, and additionally they it was renamed to more
closely match the other variables naming convention. This was done
in two files; so when 'artemis create mybroker' is run on a Windows
machine, the broker is correctly configured with login.config.
Minor fix of changing use of single quotes to correct usage of
double quotes when declaring variable
This option was removed in JRE 10 and its presence causes error on startup.
Artemis still does not compile on JDK 9 and up, so what I tried was
to compile on JDK 1.8 and then start Artemis on 1.8 and 10.
That now works for me.
It avoid using the system clock to perform the locks logic
by using the DBMS time.
It contains several improvements on the JDBC error handling
and an improved observability thanks to debug logs.
It allows a user to customize the max allowed distance between system and DB time,
improving HA reliability by shutting down the broker when the misalignment
exceeds configured limit.
The JDBC Lock Acquisition Timeout is no longer exposed to any user configuration and defaulted to infinite to match the behaviour of the journal (file-based) one.
Logging for the "fast-tests" profile used for PR builds could be reduced
significantly. This would save time as well as prevent log truncation
(Travis CI only supports logs up to 4MB).
This is good when you are a customer and an artemis engineer (e.g. me) asks your journal print-data but you can't do it because that would expose your user's data. If you do artemis data print --safe, that will only expose the journal structure without exposing user's data and eliminate any liability between the engineer and users.