Jimmy Wilson wrote: > Good to know. I hadn't thought of this b/c most everything I've > ever done was with Async. > JBC should throw an InvalidStateException when customers try to do > this (and are using Sync). You think? If you can screw up the > config, we should tell them authoritatively that it's screwed up > during startup (aka fail fast). That's a good idea: If SyncReplTimeout <= LockAcquisitionTimeout && SYNC (INVL or REPL) throw IllegalStateException Manik & the rest, what do you think? JIRA? Jimmy, maybe you could implement this if Manik & the rest are happy with it? > Jimmy > -------- Original Message -------- > Subject: New case comment notification. Case Number 00017543 > Date: Wed, 8 Aug 2007 14:48:02 +0000 (GMT) > From: Galder Zamarreno <gzamarreno(a)jboss.com&gt; > To: jboss-support-cache(a)redhat.com <jboss-support-cache(a)redhat.com&gt; > Galder Zamarreno has added a comment to case 00017543 : "JBoss > cache Write Lock Timeout". Please read the comment below and then > click on the link to respond appropriately. > Comment: > Comments on the information provided so far: > 1.- your SyncReplTimeout and LockAcquisitionTimeout are not set > correctly: > The values of these two properties have to be set accordingly. > SyncReplTimeout > should always be bigger than LockAcquisitionTimeout > If the values are the same or SyncReplTimeout is lower: > Node A sends out a replication. > Node B blocks x seconds waiting for a lock. > Node A times out on the replication and throws and exception. > Node B times out on the lock and throws and exception. > If the SyncReplTimeout is longer, you get: > Node A sends out a replication. > Node B blocks x seconds waiting for a lock. > Node B times out on the lock and throws an TimeoutException. > Exception propagates back to Node A and is rethrown. > Either way both nodes get a TimeoutException, but with the latter > the exception is more > meaningful. With the former we don't know why Node A threw a > TimeoutException -- > maybe the underlying cause was a cluster communication problem > rather than a lock > conflict. > 2.- How many nodes are in the cluster? > 3.- What is the name of the node for which you provided the logs? > is it srv-node1? > 4.- Could you provide server.log files for other nodes if there're > others? > 5.- If this is occurring in production, can you reproduce this > issue outside of production, > i.e. in staging/pre-production environment? > https://na1.salesforce.com/50030000003Pqkq -- Galder Zamarreño Sr. Software Maintenance Engineer JBoss, a division of Red Hat _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev