Commit Graph

809 Commits

Author SHA1 Message Date
Clebert Suconic 6ed1e4c87d [maven-release-plugin] prepare for next development iteration 2021-02-08 15:56:31 -05:00
Clebert Suconic 06b29806ca [maven-release-plugin] prepare release 2.17.0 2021-02-08 15:56:18 -05:00
Ingo Karkat 044d6101e9 ARTEMIS-3081 Swap precedence of key/tr.store props
If an application wants to use a special key/truststore for Artemis but
have the remainder of the application use the default Java store, the
org.apache.activemq.ssl.keyStore needs to take precedence over Java's
javax.net.ssl.keyStore. However, the current implementation takes the
first non-null value from
  System.getProperty(JAVAX_KEYSTORE_PATH_PROP_NAME),
  System.getProperty(ACTIVEMQ_KEYSTORE_PATH_PROP_NAME),
  keyStorePath

So if the default Java property is set, no override is possible. Swap
the order of the JAVAX_... and ACTIVEMQ_... property names so that the
ActiveMQ ones come first (as a component-specific overrides), the
standard Java ones comes second, and finally a local attribute value
(through Stream.of(...).firstFirst()).

(In our case the application uses the default Java truststore location
at $JAVA_HOME/lib/security/jssecacerts, and only supplies its password
in javax.net.ssl.trustStorePassword, and then uses a dedicated
truststore for Artemis. Defining both org.apache.activemq.ssl.trustStore
and org.apache.activemq.ssl.trustStorePassword now makes Artemis use the
dedicated truststore (javax.net.ssl.trustStore is not set as we use the
default location, so the second choice
org.apache.activemq.ssl.trustStore applies), but with the Java default
truststore password (first choice javax.net.ssl.trustStorePassword
applies instead of the second choice because it is set for the default
truststore). Obviously, this does not work unless both passwords are
identical!)
2021-02-03 12:02:19 -05:00
Tomas Hofman ebeea15c2a ARTEMIS-3074 Add ActiveMQServerControl#createBridge() method variant accepting a JSON string 2021-02-01 19:21:40 -05:00
Justin Bertram 4fbc8bf67d ARTEMIS-3008 mngmnt op to reload config file 2021-01-25 13:35:19 -06:00
franz1981 2e0f051d2d ARTEMIS-3063 AMQPMessage get property can use a String switch 2021-01-12 12:07:23 +01:00
Andy Taylor ea7f001776 ARTEMIS-3043 - improvements on new console
https://issues.apache.org/jira/browse/ARTEMIS-3043
2021-01-06 10:47:57 -05:00
franz1981 2b585508cc ARTEMIS-3025 JsonReader char[] leak 2020-12-09 10:55:09 -06:00
Domenico Francesco Bruscino 383ec0870e NO-JIRA Mask ssl context log passwords 2020-12-08 10:44:29 -05:00
Clebert Suconic e6a6e81b02 ARTEMIS-3019 expiry changes in AMQP Large Message 2020-12-07 10:44:51 -05:00
sebthom 80c51803da ARTEMIS-3001 Provide address and queue count via ActiveMQServerControl
See https://issues.apache.org/jira/browse/ARTEMIS-3001
2020-11-17 15:55:50 -05:00
Justin Bertram 1551983a73 ARTEMIS-2961 reset TLS values w/forceSSLParameters 2020-11-12 11:06:35 -05:00
Domenico Francesco Bruscino 14ec3cb7b0 ARTEMIS-2976 Remove password before creating server locator 2020-11-05 11:39:35 -05:00
Robbie Gemmell 5ff075b7ff ARTEMIS-2971: add ANONYMOUS and EXTERNAL SASL mechanism support for outgoing AMQP server connections 2020-11-05 11:32:35 -05:00
Clebert Suconic 4e7bb97df7 [maven-release-plugin] prepare for next development iteration 2020-11-02 17:45:51 -05:00
Clebert Suconic 9768017530 [maven-release-plugin] prepare release 2.16.0 2020-11-02 17:45:38 -05:00
Clebert Suconic 28919b6ad8 [maven-release-plugin] prepare for next development iteration 2020-10-30 10:16:29 -04:00
Clebert Suconic af5ca9f1e6 [maven-release-plugin] prepare release 2.16.0 2020-10-30 10:16:17 -04:00
Clebert Suconic 8499eac76c ARTEMIS-2937 Server Side AMQP Connectivity with options to transfer queues or replicate data 2020-10-28 11:37:25 -04:00
franz1981 b5753a0000 ARTEMIS-2958 Timed out waiting pool stop on backup restart
BackupManager::activated should correctly unblock
unauthorized blocking requests to allow a backup broker
to prompty restart in case of live failback
2020-10-22 12:44:42 -04:00
Domenico Francesco Bruscino 90434a4cf4 ARTEMIS-2935 Fix JMX ObjectNames
Fix invalid object names setting a default broker name if it cannot be used.
2020-10-22 15:10:02 +08:00
Emmanuel Hugonnet fdfc58171b [ARTEMIS-2939]: Artemis should not delete corrupt log files.
* Moving corrupted journal files to the attic folder.

Jira: https://issues.apache.org/jira/browse/ARTEMIS-2939
2020-10-20 18:39:06 -04:00
Justin Bertram 75e12b5e1d ARTEMIS-2947 Implement SecurityManager that supports replication 2020-10-19 10:07:57 -04:00
Andy Taylor 0ce173dcb5 ARTEMIS-2838 - migrate to HawtIO 2
https://issues.apache.org/jira/browse/ARTEMIS-2838
2020-10-09 09:20:29 +01:00
Mikko Uoti 2faafec737 ARTEMIS-2823 Use datasource with JDBC store db connections
Replaces direct jdbc connections with dbcp2 datasource. Adds
configuration options to use alternative datasources and to alter the
parameters. While adding slight overhead, this vastly improves the
management and pooling capabilities with db connections.
2020-10-06 08:32:58 +03:00
Andy Taylor c77bf50db4 ARTEMIS-2908 - Persist Divert Configuration in Bindings journal
https://issues.apache.org/jira/browse/ARTEMIS-2908
2020-09-25 10:03:40 -04:00
Justin Bertram 0f60b5a8e4 ARTEMIS-2906 add lastAckTimestamp to message counter 2020-09-24 12:51:00 -04:00
Justin Bertram beaacbfa8d ARTEMIS-2904 prevent acceptor from automatically starting 2020-09-23 20:19:16 -04:00
Justin Bertram 246bf08391 ARTEMIS-2909 revert ARTEMIS-2322
This reverts commit dbb3a90fe6.

The org.apache.activemq.artemis.core.server.Queue#getRate method is for
slow-consumer detection and is designed for internal use only.

Furthermore, it's too opaque to be trusted by a remote user as it only
returns the number of message added to the queue since *the last time
it was called*. The problem here is that the user calling it doesn't
know when it was invoked last. Therefore, they could be getting the
rate of messages added for the last 5 minutes or the last 5
milliseconds. This can lead to inconsistent and misleading results.

There are three main ways for users to track rates of message
production and consumption:

 1. Use a metrics plugin. This is the most feature-rich and flexible
way to track broker metrics, although it requires tools (e.g.
Prometheus) to store the metrics and display them (e.g. Grafana).

 2. Invoke the getMessageCount() and getMessagesAdded() management
methods and store the returned values along with the time they were
retrieved. A time-series database is a great tool for this job. This is
exactly what tools like Prometheus do. That data can then be used to
create informative graphs, etc. using tools like Grafana. Of course, one
can skip all the tools and just do some simple math to calculate rates
based on the last time the counts were retrieved.

 3. Use the broker's message counters. Message counters are the broker's
simple way of providing historical information about the queue. They
provide similar results to the previous solutions, but with less
flexibility since they only track data while the broker is up and
there's not really any good options for graphing.
2020-09-23 12:08:57 -04:00
Bernd Gutjahr 100d070942 ARTEMIS-2878 Add numberOfPages as metric
Added metric 'number.of.pages' to provide numberOfPages for an address.
2020-09-16 09:16:55 -05:00
Justin Bertram e47eb5ae20 ARTEMIS-589 flow control for individual STOMP subscribers 2020-09-16 10:13:47 -04:00
Justin Bertram 6be8966164 ARTEMIS-2901 support namespace for temporary queues 2020-09-16 10:10:28 -04:00
Andy Taylor c29a8cda5c ARTEMIS-2902 - expose at queue control messages held in a prepared tx
https://issues.apache.org/jira/browse/ARTEMIS-2902
2020-09-15 11:08:59 -04:00
Clebert Suconic 7cf5289efa ARTEMIS-2900 Expose property (getWholeMessageSize) so users can intercept size of messages and large messages 2020-09-14 15:35:46 -04:00
Stefan Krutzler 1783aa15cb ARTEMIS-2875 - retry to reattach sessions on failed failover for the specified amount of times set in reconnectAttempts parameter 2020-09-10 08:21:18 +02:00
Justin Bertram 90853409a0 ARTEMIS-2886 optimize security auth
Both authentication and authorization will hit the underlying security
repository (e.g. files, LDAP, etc.). For example, creating a JMS
connection and a consumer will result in 2 hits with the *same*
authentication request. This can cause unwanted (and unnecessary)
resource utilization, especially in the case of networked configuration
like LDAP.

There is already a rudimentary cache for authorization, but it is
cleared *totally* every 10 seconds by default (controlled via the
security-invalidation-interval setting), and it must be populated
initially which still results in duplicate auth requests.

This commit optimizes authentication and authorization via the following
changes:

 - Replace our home-grown cache with Google Guava's cache. This provides
simple caching with both time-based and size-based LRU eviction. See more
at https://github.com/google/guava/wiki/CachesExplained. I also thought
about using Caffeine, but we already have a dependency on Guava and the
cache implementions look to be negligibly different for this use-case.
 - Add caching for authentication. Both successful and unsuccessful
authentication attempts will be cached to spare the underlying security
repository as much as possible. Authenticated Subjects will be cached
and re-used whenever possible.
 - Authorization will used Subjects cached during authentication. If the
required Subject is not in the cache it will be fetched from the
underlying security repo.
 - Caching can be disabled by setting the security-invalidation-interval
to 0.
 - Cache sizes are configurable.
 - Management operations exist to inspect cache sizes at runtime.
2020-08-26 13:36:24 -05:00
Domenico Francesco Bruscino 32bf9680f2 [maven-release-plugin] prepare for next development iteration 2020-08-24 16:03:24 +02:00
Domenico Francesco Bruscino a549fcedde [maven-release-plugin] prepare release 2.15.0 2020-08-24 16:03:12 +02:00
Michael Pearce 2c506cc52a [ARTEMIS-2863] Add support to pause dispatch when group rebalance
Add test case
Add implementation
Add docs
2020-08-19 12:04:50 -04:00
franz1981 40f20cfe6a ARTEMIS-2877 Fix journal replication scalability
This is allowing journal appends to happen in burst
during replication, by batching replication response
into the network at the end of the append burst.
2020-08-17 13:01:41 -04:00
Clebert Suconic c551df770c ARTEMIS-2868 Protect Topology Updates from Split Brain on broker shutdown as well 2020-08-07 12:39:20 -04:00
Clebert Suconic 27cb9b37b1 ARTEMIS-2868 Protect Topology Updates from Split Brain 2020-08-06 17:40:57 -04:00
Clebert Suconic 3d86d78828 ARTEMIS-2587 Exposing ActiveMQServer::isActivate through management at ActiveMQServerControl 2020-07-29 11:41:41 -04:00
Scott Werner e3ed8e815b ARTEMIS-2847 socks5h support
Added 'socksRemoteDNS' transport parameter.
If set to true, remote destination socket is created unresolved
and DNS resolution is disabled.
2020-07-21 16:04:15 -04:00
Clebert Suconic 6690ba1d24 [maven-release-plugin] prepare for next development iteration 2020-07-09 12:49:08 -04:00
Clebert Suconic a76f41a7ed [maven-release-plugin] prepare release 2.14.0 2020-07-09 12:48:54 -04:00
Howard Gao 6f8ff55dec ARTEMIS-2835 Porting HORNETQ-1575 and HORNETQ-1578
1 of 2) - Porting of HORNETMQ-1575

In a live-backup scenario, when live is down and backup becomes live, clients
using HA Connection Factories can failover automatically. However if a
client decides to create a new connection by itself (as in camel jms case)
there is a chance that the new connection is pointing to the dead live
and the connection won't be successful. The reason is that if the old
connection is gone the backup will not get a chance to announce itself
back to client so it fails on initial connection.

The fix is to let CF remember the old topology and use it on any
initial connection attempts.
2020-07-08 11:27:36 -04:00
Justin Bertram fd207e75b0 ARTEMIS-2829 wrong return type for getDiskStoreUsage
Since getDiskStoreUsage on the ActiveMQServerControl is converting a
double to a long the value is always 0 in the management API. It should
return a double instead.
2020-07-07 08:18:28 -04:00
Justin Bertram cb7cd729d7 ARTEMIS-2828 add addressSize metric
Adding this metric required moving the meter registration code from the
AddressInfo class to the ManagementService in order to get clean access
to both the AddressInfo and AddressControl classes.
2020-07-07 08:18:28 -04:00
Justin Bertram 73c4e399d9 NO-JIRA clarify diskStoreUsage description 2020-07-07 08:18:28 -04:00