Cache Loader migration code
by Manik Surtani
Guys,
Does this still need to live in 2.1.0? Can I delete it from here?
It is still in the 2.0.0 src tree.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
18 years, 10 months
Naming JBoss Cache 2.1
by Manik Surtani
So we've had Wasabi (1.3.0), Jalapeno (1.4.0), Cayenne (1.4.1) and
most recently Habanero (2.0.0). We need a new name for upcoming
2.1.0 - I'm leaning towards Chipotle. Any other suggestions? :-)
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
18 years, 10 months
Re: [Fwd: New case comment notification. Case Number 00017543]
by Galder Zamarreno
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
18 years, 10 months