[jbosscache-dev] Re: [Fwd: New case comment notification. Case Number 00017543]

Galder Zamarreno galder.zamarreno at redhat.com
Thu Aug 9 11:59:53 EDT 2007


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 at jboss.com>
> To: jboss-support-cache at redhat.com <jboss-support-cache at redhat.com>
> 
> 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



More information about the jbosscache-dev mailing list