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(a)jboss.com>
> To: jboss-support-cache(a)redhat.com <jboss-support-cache(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat