If replication blocked anything on the journal
the processing from clients would be blocked
and nothing would work.
As part of this fix I am using an executor on ServerSessionPacketHandler
which will also scale better as the reader from Netty would be feed immediately.
Even if there is no address/url configured for the NetworkHealthCheck
an isolated backup will still fail-over potentially causing split-brain.
(cherry picked from commit 5cb5c8a6dc7179078f099d5455343e1f18fd3398)
- NIO/ASYNCIO new TimedBuffer with adapting batch window heuristic
- NIO/ASYNCIO improved TimedBuffer write monitoring with
lightweight concurrent performance counters
- NIO/ASYNCIO journal/paging operations benefit from less buffer copy
- NIO/ASYNCIO any buffer copy is always performed with raw batch copy
using SIMD instrinsics (System::arrayCopy) or memcpy under the hood
- NIO improved clear buffers using SIMD instrinsics (Arrays::fill) and/or memset
- NIO journal operation perform by default TLABs allocation pooling (off heap)
retaining only the last max sized buffer
- NIO improved file copy operations using zero-copy FileChannel::transfertTo
- NIO improved zeroing using pooled single OS page buffer to clean the file
+ pwrite (on Linux)
- NIO deterministic release of unpooled direct buffers to avoid OOM errors
due to slow GC
- Exposed OS PAGE SIZE value using Env class
(cherry picked from commit 21c9ed85cf6b9a53debdd32747bd42b2e733da80)
This is fixing an issue introduced on 4b47461f03a607b9ef517beb2a1666ffae43a2a7 (ARTEMIS-822)
The Transactions were being looked up without the readLock and some of the controls for Read and Write lock
were broken after this.
(cherry picked from commit ddacda50626ef2cd5ccf74a3149eccbbda4a9d84)
This is now considering only threads waiting for the queue to get new tasks as idle.
The thread pool maintained a counter of active threads, but that counter was increased
too late in the beforeExecute method. Submitting a task created a new thread.
If now a second task was submitter before the new thread had started to execute it's task,
the second task was queued without creating a 2nd thread. So the second task was only
executed after the first task had been completed - even if the thread pool's
maximum number of thread had not been reached.
This fix now maintains the delta between the number those threads that are currently waiting
in the queue's poll or take methods as idle threads, and the number of queued tasks.
It creates new threads unless there are enough idle threads to pick up all queued tasks.
This closes#1144
(cherry picked from commit 5a31e7035354516664087a65ac97e1a6f4c13f14)
- user passwords for PropertiesLoginModule stored using PBKDF2 algothrim
by default
- implements cli user command to help create and manage user/roles
- adds a mask cli command to mask passwords
Since we don't need client implementations any longer, given the maturity level of
qpid jms, these classes can go, as a result a lot of the interfaces can be removed.
As part of this I am removing proton-plug, and reorganizing the packages in a way I think it
makes more sense and easier to other developers to understand and maintain it.
https://issues.apache.org/jira/browse/ARTEMIS-751
