activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From emilyj <>
Subject ActiveMQ Master Slave setup with Veritas CFS
Date Wed, 07 Jul 2010 16:08:21 GMT

There is an issue with setting up ActiveMQ as master and slave with Veritas

I have 2 instances of ActiveMq sharing one disk.  The master obtains a lock
to the shared directory and the slave throws an exception because it cannot
obtain a lock.  In Veritas 5.0MP1, this was not the case.

As it turns out, Veritas has changed their code (from their engineering
5.0MP1 on the node that is trying to aquire a write lock on a file that is
already held:
6583:   fcntl(3, F_SETLK64, 0xFFBFF838)                 Err#11 EAGAIN
6583:           typ=F_WRLCK  whence=SEEK_SET start=0     len=1024  sys=3 

And on 5.0MP3:
2272:   fcntl(3, F_SETLK64, 0x08047924)                 Err#13 EACCES
2272:           typ=F_WRLCK  whence=SEEK_SET start=4398046511104
len=-75781618446368768 sys=4276761489 pid=41

EAGAIN makes ActiveMQ retry the lock where as ECCES throws an exception:
INFO  BrokerService                  - Using Persistence Adapter:
ERROR BrokerService                  - Failed to start ActiveMQ JMS Message
Broker. Reason: Permission denied Permission denied
	at Method)
	at Source)
	at java.nio.channels.FileChannel.tryLock(Unknown Source)

I have since downgraded back to 5.0MP1.  I was just putting this out there
so others are aware and to see if the ActiveMQ team should consider handling
both return codes EACCES and EAGAIN when trying to lock an object.

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message