I haven't done any real testing regarding performance but I don't think the parameter would impact the performance greatly?
The Broker that has the lock can just continue working with the kahadb (as if there was no slave). And the Slave is polling the the kahadb more often (more requests to the shared Filesystem) but those requests shouldn't eat a lot of bandwidth. It will only check whether the file is still locked. But performance impact will be very different from system to system so I guess you should test it on a setup for which you want to know the impact. Anywasy for testing I do recommend to chose an appropriate loglevel otherwise you will get a lot of entries like " INFO | Database /opt/amq/data/kahadb/lock is locked... waiting 0 seconds for the database to be unlocked. Reason: java.io.IOException: File '/opt/amq/data/kahadb/lock' could not be locked.". So make sure you don't log INFO messages :-). If I find the time to do some testing, I'll post the results. -- View this message in context: http://activemq.2283324.n4.nabble.com/10-seconds-wait-time-for-kahadb-lock-tp4488418p4498208.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
