[infinispan-dev] Fwd: CloudCacheStore Bug

[Manik Surtani]

That is strange since there is no correlation between eviction and the synchronicity of cache stores.  Have you got a reproducible test for this?

Cheers
Manik

On 3 Feb 2010, at 18:37, Philippe Van Dyck wrote:

> Thanks Manik,
> 
> I have a another problem with eviction, it seems to destroy cache entries, only when I use async.
> 
> Of course, all updates are transactional.
> 
> Where should I search for clues ? Any idea ?
> 
> Here is my config:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> 
> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xmlns="urn:infinispan:config:4.0">
> 	<global>
> 		<transport
> 			transportClass="org.infinispan.remoting.transport.jgroups.JGroupsTransport">
> 			<properties>
> 				<property name="configurationFile" value="jgroups.xml" />
> 			</properties>
> 		</transport>
> 
> 	</global>
> 
> 	<namedCache name="qi4j">
> 		<transaction
> 			transactionManagerLookupClass="org.infinispan.transaction.lookup.DummyTransactionManagerLookup" />
> 		<clustering mode="distribution">
> 			<l1 enabled="true" lifespan="100000" />
> 			<hash numOwners="1" rehashRpcTimeout="120000" />
> 		</clustering>
> 
> 		<loaders passivation="false" shared="true" preload="false">
> 
> 			<loader class="org.infinispan.loaders.file.FileCacheStore"
> 				fetchPersistentState="false" ignoreModifications="false"
> 				purgeOnStartup="true">
> 				<properties>
> 					<property name="location" value="/tmp" />
> 				</properties>
> 				<async enabled="true" threadPoolSize="3" />
> 			</loader>
> 
> 			</loaders>
> 		
> 		<deadlockDetection enabled="true" spinDuration="1000"></deadlockDetection>
> 
> 		<eviction strategy="FIFO" wakeUpInterval="1000" maxEntries="10" />
> 
> 		<unsafe unreliableReturnValues="true" />
> 
> 	</namedCache>
> </infinispan>
> 
> 
> phil
> 
> 
> 
> On Wed, Feb 3, 2010 at 6:42 PM, Manik Surtani <manik at jboss.org> wrote:
> Ugh, good point.  I thought the unit tests would have trapped a dumb-ass mistake like this.
> 
> The reason for transforming the name of the bucket is that we usually use hashcodes as the bucket name, which can take Integer.MIN_VALUE to Integer.MAX_VALUE.  These are then translated into Strings, and this becomes the name of the storage unit, e.g., 12345.bucket in the FileCacheStore.  Now filesystems are happy to accept a -12345.bucket but certain cloud storage providers barf when encountering the '-' character.  Hence the transformation to A12345.bucket in some cases.
> 
> Cheers
> Manik
> 
> PS: pushing up a new snapshot as I type, containing this fix + lower verbosity on eviction-related lock timeouts.
> 
> On 3 Feb 2010, at 17:16, Philippe Van Dyck wrote:
> 
>> And BTW, why do it ?
>> 
>> p
>> 
>> ---------- Forwarded message ----------
>> From: Philippe Van Dyck <pvdyck at gmail.com>
>> Date: Wed, Feb 3, 2010 at 6:15 PM
>> Subject: CloudCacheStore Bug
>> To: infinispan -Dev List <infinispan-dev at lists.jboss.org>
>> 
>> 
>> Hi all,
>> 
>> there is a bug in CloudCacheStore that makes me feel like I am the only one using it ;-)
>> 
>> in CR4 : if you change the "-" sign to "A" in getBucketName ... you need to do the opposite somewhere (or call it every time) ;-)
>> 
>> WDYT ?
>> 
>> p
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> 
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100204/0ee2fbf9/attachment-0002.html