Building on ARTEMIS-905 JCtools ConcurrentMap replacement first proposed but currently parked by @franz1981, replace the collections with primitive key concurrent collections to avoid auto boxing.

The goal of this is to reduce/remove autoboxing on the hot path. We are just adding jctools to the broker (should not be in client dependencies) Like wise targeting specific use case with specific implementation rather than a blanket replace all.

We have to create our own primitive long concurrent hash set, based on jctools as jctools currently don't have one.

This adds Support for ARTEMIS-3106 and adds the following parts:

• An implementation for SASL-SCRAM-SHA1/256/512 based on SCRAM SASL authentication for Java
• A properties based SASL-SCRAM LoginModule to manage user and roles
• A LoginModule using the acquired credentials from the SASL-SCRAM Module to perform the login in Artemis
• An example Server/Client that demonstrates the use

Improve paging throughput by using a specific executor for pageSyncTimer

Improving throughput on paging mode is one of our concerns since our cluster uses paging a lot. We found that pageSyncTimer in PagingStoreImpl shared the same executor with pageCursorProvider from thread pool. In heavy load scenario like hundreds of consumers receiving messages simultaneously, it became difficult for pageSyncTimer to get the executor due to race condition. Therefore page sync was delayed and producers suffered low throughput.

To achieve higher performance we assign a specific executor to pageSyncTimer to avoid racing. And we run a small-scale test on a single modified broker.

Broker: 4C/8G/500G SSD Producer: 200 threads, non-transactional send Consumer 200 threads, transactional receive Message text size: 100-200 bytes randomly AddressFullPolicy: PAGE

Test result：

  | Only Send TPS | Only Receive TPS | Send&Receive TPS -- | -- | -- | -- Original ver | 38k | 33k | 3k/30k Modified ver | 38k | 34k | 30k/12.5k

The chart above shows that on modified broker send TPS improves from “poor” to “extremely fast”, while receive TPS drops from “extremely fast” to “not-bad” under heavy load. Considering consumer systems usually have a long processing chain after receiving messages, we don’t need too fast receive TPS. Instead, we want to guarantee send TPS to cope with traffic peak and lower producer’s delay time. Moreover, send and receive TPS in total raises from 33k to about 43k. From all above this trade-off seems beneficial and acceptable.

Replaces direct jdbc connections with dbcp2 datasource. Adda 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.

@franz1981 an alternative so we don't have to have a copy of CopyOnWriteArrayList, it does mean on add or remove consumer we have to invoke toArray which causes a copy, but this is not on hot path, so i think we should be good, and avoids us having to clone a jvm class.

This is my attempt to address the problem of the auto-creation of queues based on FQQN. The simple scenario seems to work, but some decisions need to be made before I can move forward with this.

1. There is a problem with the RoutingType mismatch. Previously it didn't matter what RoutingType receiver tries to attach to, as the implementation assumed pre-existence of the queue. Now the routing type matters, as we need to create a properly configured queue if it doesn't exist. That's why testQueueConsumerReceiveTopicUsingFQQN test fails currently. To make it pass I would need to subscribe to a topic instead of a queue. I'm not sure but is this a breaking change or not?
2. I'm not sure what is the expected behavior when durability configuration mismatches. The problem is described in a test testAttachToPreConfiguredNonDurableQueueUsingDurableFQQN. Should we reject the attempt to attach when the pre-configured queue is non-durable and attach request has the source with TerminusDurability of UNSETTLED_STATE or CONFIGURATION? And what about the opposite, pre-configured queue is durable and we received source with NONE value for TerminusDurability?

I would greatly appreciate your help. :)

The ThreadLeakCheckRule is used to check thread leaks after each test is finished. However when a test fails, it is not necessary to check leaking threads because the test failure should be fixed anyway. And leaking threads in a failed test may well be a result of the failure (once the test is fixed the thread leak may be gone).

If a failed test also leaks threads, it takes a long time before the thread leak check finishes (60 seconds checking time), thus it takes a long time to finish, especially when tests are run in batches with failures.

So to improve this, it should be reasonable to just enable the thread leaking check for each test passes, and disable the check when a test fails.

I've opened this PR for discussion: I would like to re-introduce ARTEMIS-2336, but I've allowed wildfly or any user that doesn't want/can to use zero copy to be able to use the existing artemis code.

I've opened https://github.com/netty/netty/pull/9592 too to "enhance" ChunkedNioFile in order to solve a bug on our implementation: in the meantime I've "shadowed" my solution on Netty directly into AbsoluteChunkedNioFile to not rely on any specific Netty version.

This PR could make use for InVM connection the same optimization sent on https://github.com/apache/activemq-artemis/pull/2844 while reading file (RandomAccessFile) on ReplicationSyncFileMessage.

Based on discussion from http://activemq.2283324.n4.nabble.com/Improve-paging-performance-when-there-are-lots-of-subscribers-td4751333.html I decided to take the approach suggested by franz which is different than the one before. Now file offset is put in the PagePostion for reading directly from file and the extra index cache layer is removed.

The following changes are made to support Epoll.

• Refactored SharedNioEventLoopGroup into renamed SharedEventLoopGroup to be generic (as so we can re-use for both Nio and Epoll)
• Add support and toggles for Epoll in NettyAcceptor and NettyConnector (with fall back to NIO if cannot load Epoll)
• Removal from code of PartialPooledByteBufAllocator, caused bad address when doing native, and no longer needed - see jira discussion

New Connector Properties:

useEpoll - toggles to use epoll or not, default true (but we failback to nio gracefully) epollRemotingThreads = same behaviour as nioRemotingThreads but for Epoll. useEpollGlobalWorkerPool = same behaviour as useNioGlobalWorkerPool but for Epoll.

New Acceptor Properties:

useEpoll - toggles to use epoll or not, default true (but we failback to nio gracefully) useEpollGlobalWorkerPool = same behaviour as useNioGlobalWorkerPool but for Epoll.

This pull request improves the validation of Fully Qualified Queue Name (FQQN) strings as per issue ARTEMIS-1883 by validating the presence of content in both sides of the "::" separator.

Some LDAP servers (e.g. OpenLDAP) do not support the "persistent search" feature and therefore the existing "listener" feature does not actually fetch updates. This commit implements a "pull" feature controlled by a configurable interval equivalent to what is implemented in the cached LDAP authorization module from ActiveMQ "Classic."

A handful of tests started to fail after the original fix was committed. This commit fixes those failures mainly by using a mock TransactionSynchronizationRegistry.

I changed o.a.a.a.r.ActiveMQRAManagedConnection#checkTransactionActive slightly because getTransactionStatus will never return null unlike getTransaction would. The semantics should still be the same, though.

     When calling Session.recover(), unacknowledged messages must be returned to the queue, that is, ClientSession.rollback (false). If you call ClientSession.rollback (true), the ActiveMQServerMessagePlugin.messageAcknowledged () is called. Which is illogical and misleading. However, this introduces the problem that deliveryCount does not increase on rereads. ut this needs to be fixed elsewhere.