Shouldn't operations like this be using the InterruptibleChannel interface to do the work? Isn't this another anti-pattern?
Is this handled by Netty, and is there a way I can change this?
By default we use the netty OioClientSocketChannelFactory which utilizes the old I/O API, to use NIO you can set use-nio to true on the connector. I'm assuming, but don't know for sure, that netty would use InterruptibleChannel under the covers. If i get a chance i'll check the netty source.
So I set
for the client and I can see that it's running the "New /IO client boss" thread,
but it takes up to 10 seconds for the thread to relinquish control and the program to terminate once it's the only thread left running.
If I send an interrupt signal to the daemon thread which starts the connection during the call to HornetQConnectionFactory.createQueueConnection() nothing happens. That Thread and the "New I/O client boss" both wait at least 10 seconds before exiting.
Looking through the Netty code, it just uses the daemon setting of the thread which creates it so I suppose HornetQ doesn't make itself a daemon thread. Looking further Netty uses NIO and has a connection timeout which is configurable. https://issues.jboss.org/browse/NETTY-204.
I'm not sure why, but I don't think HornetQ even provides a way to set the connection timeout and it seems to use the default OS value. There is a Call Timeout.
This is a bit of a problem as some OS set the connection timeout is 2 minutes in some cases.
Is there any way to set the connection timout with either OIO or NIO for HornetQ?
Why don't HornetQ connection threads exit when all other no daemon threads exit?
If you raise a jira then we can expose the netty timeout.