I'm running HornetQ 2.1.2 standalone as a service on Windows Server 2008 by a domain user account.
Aparently M$ have made some changes related to this in recent years, one of which is not to allow interactive services due to some security exploits.
My guess is that this is the cause of my problems because initially I was logging to the console just for debugging convenience and didn't bother stopping it on production. Once I found that this was blocking, I turned console logging off and the problem went away. Recently however I had 2 services running the same client consuming messages remotely from different HornetQ standalone. The sequence of events seem to be:
1. Some network or service related problem occured causing the hornet JMS consumer to throw a JMSException on a receive(200) call.
2. A rollback was attempted causing an IllegalStateException.
3. A new connection attempt was initiated and the createConnection() call blocks for 8 hours.
4. The client service is restarted and everything continues as usual.
My server configuration the default standalone non-clustered with JNDI disabled.
The client uses all default settings.
The stack trace I obtained from jconsole on the JMS thread is:
Total blocked: 125,069 Total waited: 898,727
- locked java.io.BufferedOutputStream@1b4920f8
- locked java.io.PrintStream@5e1387c6
- locked java.io.OutputStreamWriter@5437086a
- locked java.util.logging.ConsoleHandler@69099257
- locked java.lang.Object@5fb57890
- locked java.lang.Object@c1dfe1a
- locked org.hornetq.core.client.impl.ClientSessionFactoryImpl@3f2221f6
- locked org.hornetq.jms.client.HornetQConnectionFactory@76c5a2f7
Can anyone tell me how to stop hornet client calling JUL?
After all, I'm only interested in the exception so I can make another connection attempt.
Can anyone shed any light on this that might help me fix it?
I know I'd much rather not use Windows, but there is no choice and I can't see why logging is required here.