Stopping the server should be able to handle exceptions thrown by
individual components. Before this patch the stop method would throw
any raised exception and exit. This can lead to partial shutdowns of
the server resulting in leaking threads. This patch catches any
component exceptions and logs an appropriate error message, allowing the
server to properly shutdown.
Previously we were using a long regular expression to detect whether or not a
given host was IPv6. However, this was brittle and hard to read. Since we are
already shipping Google Guava in the distribution it made sense to use the
Guava method com.google.common.net.InetAddresses#isInetAddress rather than
the regular expression.
In ServiceUtils, loads services from an AccessController.doPriviledged
block and use the ServiceUtils's own classloader instead of the TCCL
(that may be different depending on who's requesting a managed
connection factory first)
JIRA: https://issues.apache.org/jira/browse/ARTEMIS-294
Ive renamed the current isSameHost method to isSameparams as thats what it checked and added a new method for isSameHost that checks the appropriate params for the connector. Ive changed ClientSessionFactoryImp to use this to correct the behaviour.
https://issues.apache.org/jira/browse/ARTEMIS-292
When server sends disconnect to the client, the ClientSession schedules
a close task on it's ordered executor. Once the close method starts
it's waits to check to see if all jobs in it's executor has completed.
To do this it adds a job to it's ordered executor, once it is run it
knows there is nothing more to do and thus is ready to close. However,
this causes a deadlock as both jobs are running in the ordered executor
and thus are both waiting on each other. The close eventually timesout
which is why we see the logs as reported in the JIRA.
This commit runs the close method in it's own ordered executor, thus
preventing the two jobs blocking each other.