User development, A new message was posted in the thread "long live consumer stops working": http://community.jboss.org/message/522325#522325 Author : Simo Nikula Profile : http://community.jboss.org/people/simo.nikula@capgemini.com Message: -------------------------------------------------------------- Hi   I've been studing quite similar issue and there are many things to consider. If you have firewall this may be helpful http://blog.akquinet.de/2009/09/30/using-jboss-messaging-in-a-firewalled-...   I'm also facing network problems that cannot be fixed as temporary problems are typical nature of those networks. In those cases few messages are left in queue every now and then. I'm still searching for proper solution but so far I've analyzed that those problems come like this: - client ping fails (also close fails with message cannot write CLOSING byte) - server sends message without knowledge that client is no more alive - after while server detects that client has not pinged it and logs error message and tries to close socket. These sockets can be detected by e.g. netstat and I run watchdog that restarts server after some amount of those CLOSE_WAIT  (>5) sockets are found.   Message are delivered after server restart and FailoverCompleteTimeout. Basically state is quite manageable but it is not nice to admit that we are restarting both our jboss servers for this cluster about 10 times per day.   Currently I'm testing socket.check_connection true in remoting-bisocket-service. Having slow connection (512 kb) between client and servers  makes testing easier than at redhat where this problem has not been able to be reproduced. client.FailoverCommandCenter  can be usually activated by doing 2MB  upload.   Simo -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/522325#522325