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
17 years, 3 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
17 years, 3 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
17 years, 3 months