I have seen a CI test failing once because the protocol was not loaded,
then I saw it failing all the time on my IDE.
This will ensure the protocol is always loaded.
This test was flaky from day one. You would need a reliable way to measure the storage time (RECORD_TIME). If you get GC or any other event happening during storage you will get a failure.
In the JAAS login module for Kubernetes, the current implementation is
loading only a single CA from the bundle that is given by OpenShift,
which in turn leads to an issue where the broker don't find a proper
PKIX path.
This is fixing the issue by loading every certificates from the bundle.
Messages that are in-flight on a link when the federation consumer is closed
due to removal of local demand might get enqueued on the local broker but the
disposition might not get sent to the remote leading to a release of the message
back to the source queue leading to a duplicate being left on the remote. The
AMQP receiver links need to be drained and any pending settlements need to be
sent before the link can be allowed to be detached.
This test was invalid from day one but we would accept eventual failures back then.
As we now want to be more strict about failures it is time for this test to go.
We would need to implement XA and a more complex test for this. as of now the test is invalid and it needs to go.
To be honest I am not 100% sure this will fix the issue I saw, but it will certainly help me diagnose future failures,
by making sure the server is stopped and assigning a proper ID on each server.
For future record I am seeing the following exception occasionally on a CI:
Caused by: org.apache.zookeeper.server.quorum.QuorumPeerConfig$ConfigException: Client and election port must be different! Please update the configuration file on server.14
at org.apache.zookeeper.server.quorum.QuorumPeer$QuorumServer.initializeWithAddressString(QuorumPeer.java:366)
* Ensure that the temproray large message content can only be read by the
user associated with the process.
* Fixing initial ARTEMIS-5172 PR which wasn't removing rw permissions.
Issue: https://issues.apache.org/jira/browse/ARTEMIS-5172
Signed-off-by: Emmanuel Hugonnet <ehugonne@redhat.com>