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

[Manik Surtani]

Yes, I think this is a good idea - a ConfigurationException could be  
thrown.

On 9 Aug 2007, at 16:59, Galder Zamarreno wrote:

> 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
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat