1 of 1 people found this helpful
We do not recommend you use Network Attached Storage (NAS), e.g. NFS mounts to store any shared journal (NFS is slow).
Aside from the fact that NFS is slow, we've also seen locking issues as well.
Thanks for the quick and helpful reply Justin.
Could you specify a bit more about what these "locking issues" actually are? Is it the same exact problem that ActiveMQ is describing? I'm currently using a NFSv3 shared directory between my live and backup HornetQ servers, and I have not yet encountered any locking issues in my testing of HornetQ. I'd like to be able to recreate some of these locking problems for testing purposes; if you could provide some details on when and where exactly the problem occurs, that would be very helpful.
It's hard to be specific about the locking issue because I received the report from a colleague. I believe the problem was that the back-up node didn't recognize the lock that the live node had on the journal which caused the back-up to start up completely and then there were two nodes performing IO on the journal which of course caused a big mess. I'm not sure which version of NFS was involved.
I believe NFS was tested early in HornetQ's development cycle and the results of those tests prompted the documentation excerpted above.
We do not have ongoing tests of HornetQ and NFS so maybe things have changed for the better in later versions, but we haven't taken any special steps to work around the problems (real or perceived) with NFS which I believe was your original question.
Thanks Justin. Does HornetQ have any alternatives besides file locking? Can the backup server ping the live server to see if it's still alive?
Does HornetQ have any alternatives besides file locking?
I'm not aware of any alternative.