DelegatingSession class wraps ClientSessionImpl and attempts to close
session should it not be closed by the user. It does this by
implementing finalize. However, the order in which finalize runs can be
difficult to predict as compilers, and JIT compilers are able to
optimize early.
The current DelegatingSession was causing problems of finalize getting
called early (before consumers, producers were finished with the
session). This was causing tests to fail on the IBM JDK (which
optimizes early). The same happens on OpenJDK if the GC is forced.
Its now possible to also add the broker name to jmx tree avoiding clashes when multiple brokers are in a single vm. This is now the default but the old way can be used with some configuration
https://issues.apache.org/jira/browse/ARTEMIS-311
The old property-file based security manager shouldn't be used anymore. Instead
use the JAAS InVMLoginModule for in-vm tests, embedded use-cases, etc. and use
the other JAAS login modules for normal server use-cases.
The failback process needs to be deterministic rather than relying on various
incarnations of Thread.sleep() at crucial points. Important aspects of this
change include:
1) Make the initial replication synchronization process block at the very
last step and wait for a response from the replica to ensure the replica has
as the necessary data. This is a critical piece of knowledge during the
failback process because it allows the soon-to-become-backup server to know
for sure when it can shut itself down and allow the soon-to-become-live
server to take over. Also, introduce a new configuration element called
"initial-replication-sync-timeout" to conrol how long this blocking will occur.
2) Set the state of the server as 'LIVE' only after the server is fully
started. This is necessary because once the soon-to-be-backup server shuts
down it needs to know that the soon-to-be-live server has started fully before
it restarts itself as the new backup. If the soon-to-be-backup server restarts
before the soon-to-be-live is fully started then it won't actually become a
backup server but instead will become a live server which will break the
failback process.
3) Wait to receive the announcement of a backup server before failing-back.