Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <29099049.post@talk.nabble.com>
Date: Wed, 7 Jul 2010 10:39:03 -0700 (PDT)
From: Joe Fernandez <joe.fernandez@ttmsolutions.com>
To: users@activemq.apache.org
Subject: Re: ActiveMQ Master Slave setup with Veritas CFS
In-Reply-To: <29098175.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <29098175.post@talk.nabble.com>


IMHO, things should remain as is. If the broker is not being granted access
to the lock, it will never be able to go to the next step of trying to
acquire the lock. 

Joe
http://www.ttmsolutions.com
ActiveMQ reference guide at
http://bit.ly/AMQRefGuide
 

emilyj wrote:
> 
> There is an issue with setting up ActiveMQ as master and slave with
> Veritas 5.0MP3.
> 
> 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
> team):
> 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 
> pid=-4196140
> 
> 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:
> AMQPersistenceAdapter(/TM/activemq-data)
> ERROR BrokerService                  - Failed to start ActiveMQ JMS
> Message Broker. Reason: java.io.IOException: Permission denied
> java.io.IOException: Permission denied
> 	at sun.nio.ch.FileChannelImpl.lock0(Native Method)
> 	at sun.nio.ch.FileChannelImpl.tryLock(Unknown Source)
> 	at java.nio.channels.FileChannel.tryLock(Unknown Source)
> 	at
> org.apache.activemq.store.amq.AMQPersistenceAdapter.doLock(AMQPersistenceAdapter.java:1045)
> 	at
> org.apache.activemq.store.amq.AMQPersistenceAdapter.lock(AMQPersistenceAdapter.java:1009)
> 	at
> org.apache.activemq.store.amq.AMQPersistenceAdapter.start(AMQPersistenceAdapter.java:174)
> 	at org.apache.activemq.broker.BrokerService.start(BrokerService.java:458)
> 
> 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: http://old.nabble.com/ActiveMQ-Master-Slave-setup-with-Veritas-CFS-tp29098175p29099049.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.