October 2010 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-613) Update JBoss Marshalling to 1.2.3.GA

by David Lloyd (JIRA)

Update JBoss Marshalling to 1.2.3.GA ------------------------------------ Key: ISPN-613 URL: https://jira.jboss.org/browse/ISPN-613 Project: Infinispan Issue Type: Task Reporter: David Lloyd Assignee: Manik Surtani Priority: Critical Fix For: 4.1.0.Final JBMAR 1.2.2.GA contains a bug that causes unmarshalling to fail when a TreeMap or TreeSet is serialized with a comparator under the River protocol. Please update to 1.2.3.GA, which includes a fix for this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-246) Create a tree module lifecycle to pass Externalizers

by Galder Zamarreno (JIRA)

Create a tree module lifecycle to pass Externalizers ---------------------------------------------------- Key: ISPN-246 URL: https://jira.jboss.org/jira/browse/ISPN-246 Project: Infinispan Issue Type: Task Components: Marshalling, Tree API Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Create a module lifecycle for the tree module (ISPN-245) so that we can provide Infinispan with the tree specific Externalizers (ISPN-244) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
9
0 / 0

[JBoss JIRA] Created: (ISPN-425) Stale data read when L1 invalidation happens while UnionConsistentHash is in use

by Galder Zamarreno (JIRA)

Stale data read when L1 invalidation happens while UnionConsistentHash is in use -------------------------------------------------------------------------------- Key: ISPN-425 URL: https://jira.jboss.org/jira/browse/ISPN-425 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.1.0.BETA1 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.CR1 See below: ----- "Manik Surtani" <manik(a)jboss.org> wrote: > On 3 May 2010, at 08:51, Galder Zamarreno wrote: > > > Resending without log until the message is approved. > > > > -- > > Galder Zamarreño > > Sr. Software Engineer > > Infinispan, JBoss Cache > > > > ----- Forwarded Message ----- > > From: galder(a)redhat.com > > To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org> > > Sent: Friday, April 30, 2010 6:30:05 PM GMT +01:00 Amsterdam / > Berlin / Bern / Rome / Stockholm / Vienna > > Subject: Stale data read when L1 invalidation happens while > UnionConsistentHash is in use > > > > Hi, > > > > I've spent all day chasing down a random Hot Rod testsuite failure > related to distribution. This is the last hurdle to close > https://jira.jboss.org/jira/browse/ISPN-411. In > HotRodDistributionTest, which is still to be committed, I test adding > a new node, doing a put on this node, and then doing a get in a > different node and making sure that I get what was put. The test > randomly fails saying that the get returns the old value. The failure > is nothing to do with Hot Rod itself but rather a race condition where > union consistent hash is used. Let me explain: > > > > 1. An earlier operation had set > "k-testDistributedPutWithTopologyChanges" key to > "v5-testDistributedPutWithTopologyChanges". > > 2. Start a new hot rod server in eq-7969. > > 2. eq-7969 node calls a put on that key with > "v6-testDistributedPutWithTopologyChanges". Recipients for the put > are: eq-7969 and eq-61332. > > 3. eq-7969 sends an invalidate L1 to all, including eq-13415 > > 4. eq-13415 should invalidate > "k-testDistributedPutWithTopologyChanges" but it doesn't, since it > considers that "k-testDistributedPutWithTopologyChanges" is local to > eq-13415: > > > > 2010-04-30 18:02:19,907 6046 TRACE > [org.infinispan.distribution.DefaultConsistentHash] > (OOB-2,Infinispan-Cluster,eq-13415:) Hash code for key > CacheKey{data=ByteArray{size=39, hashCode=17b1683, array=[107, 45, > 116, 101, 115, 116, 68, 105, 115, 116, ..]}} is 344897059 > > 2010-04-30 18:02:19,907 6046 TRACE > [org.infinispan.distribution.DefaultConsistentHash] > (OOB-2,Infinispan-Cluster,eq-13415:) Candidates for key > CacheKey{data=ByteArray{size=39, hashCode=17b1683, array=[107, 45, > 116, 101, 115, 116, 68, 105, 115, 116, ..]}} are {5458=eq-7969, > 6831=eq-61332} > > 2010-04-30 18:02:19,907 6046 TRACE > [org.infinispan.distribution.DistributionManagerImpl] > (OOB-2,Infinispan-Cluster,eq-13415:) Is local > CacheKey{data=ByteArray{size=39, hashCode=17b1683, array=[107, 45, > 116, 101, 115, 116, 68, 105, 115, 116, ..]}} to eq-13415 query returns > true and consistentHash is > org.infinispan.distribution.UnionConsistentHash@10747b4 > > > > This is a log with log messages that I added to debug it. The key > factor here is that UnionConsistentHash is in use, probably due to > rehashing not having fully finished. > > > > 5. The end result is that a read of > "k-testDistributedPutWithTopologyChanges" in eq-13415 returns > "v5-testDistributedPutWithTopologyChanges". > > > > I thought that maybe we could be more conservative here and if > rehashing is in progress (or UnionConsistentHash is in use) invalidate > regardless. Assuming that a put always follows an invalidation in > distribution and not viceversa, that would be fine. The only downside > is that you'd be invalidating too much but put would replace the data > in the node where invalidation should not have happened but it did, so > not a problem. > > > > Thoughts? Alternatively, maybe I need to shape my test so that I > wait for rehashing to finish, but the problem would still be there. > > Yes, this seems to be a bug with concurrent rehashing and invalidation > rather than HotRod. > > Could you modify your test to so the following: > > 1. start 2 caches C1 and C2. > 2. put a key K such that K maps on to C1 and C2 > 3. add a new node, C3. K should now map to C1 and C3. > 4. Modify the value on C1 *before* rehashing completes. > 5. See if we see the stale value on C2. > > To do this you would need a custom object for K that hashes the way > you would expect (this could be hardcoded) and a value which blocks > when serializing so we can control how long rehashing takes. Since logical addresses are used underneath and these change from one run to the other, I'm not sure how I can generate such key programatically. It's even more complicated to figure out a key that will later, when C3 starts, map to it. Without having these addresses locked somehow, or their hash codes, I can't see how this is doable. IOW, to be able to do this, I need to mock these addresses into giving fixed as hash codes. I'll dig further into this. > > I never promised the test would be simple! :) > > Cheers > Manik > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
11
0 / 0

[JBoss JIRA] Created: (ISPN-244) Enable external user/framework defined Externalizers

by Galder Zamarreno (JIRA)

Enable external user/framework defined Externalizers ---------------------------------------------------- Key: ISPN-244 URL: https://jira.jboss.org/jira/browse/ISPN-244 Project: Infinispan Issue Type: Feature Request Components: RPC Reporter: Galder Zamarreno Fix For: 4.1.0.BETA1 Create an internal magic number (i.e. -1 or 255) for user defined externalizers. This is done to avoid users using our number space. So, internally: <magic_number> <stream> Users: <magic_number><user defined magic number (int)> <stream> Mandate unsigned ints so that we can optimise by sending them as variable lenght Internal frameworks could use high enough numbers for example up to 2 bytes: 5000, 7000, 20000 1 byte: 128 2 bytes: 32767 3 bytes: ... GlobalConfiguration.registerMarshallable(Class type, Externalizer ext, int id); Maybe CacheManager better? CacheManager.registerMarshallable(Class type, Externalizer ext, int id); Future improvement, maybe generate ids automatically for user defined classes? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
13
0 / 0

[JBoss JIRA] Created: (ISPN-558) XAResource implementation in ISPN to become fully stateless

by Mircea Markus (JIRA)

XAResource implementation in ISPN to become fully stateless ----------------------------------------------------------- Key: ISPN-558 URL: https://jira.jboss.org/browse/ISPN-558 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.0.0.Final This is needed as XAResource.prepare/commit/rollback might be called even if XAResource is currently associated to a transaction. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
7
0 / 0

[JBoss JIRA] Created: (ISPN-736) Shipped jgroups files should be shipped in root of jar

by Galder Zamarreño (JIRA)

Shipped jgroups files should be shipped in root of jar ------------------------------------------------------ Key: ISPN-736 URL: https://jira.jboss.org/browse/ISPN-736 Project: Infinispan Issue Type: Task Components: Configuration, RPC Affects Versions: 4.2.0.ALPHA4 Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.BETA1, 5.0.0.Final 4.0.0.FINAL and 4.1.0.FINAL are shipping jgroups-*.xml files under config-samples/ directory. Instead, these files should be located on root so that people can apply configurations such as: <transport clusterName="infinispan-cluster" distributedSyncTimeout="50000" nodeName="Jalapeno"> <properties> <property name="configurationFile" value="jgroups-udp.xml"/> </properties> </transport> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-734) Support of atomic accesses to collection values.

by Tobias Sarnowski (JIRA)

Support of atomic accesses to collection values. ------------------------------------------------ Key: ISPN-734 URL: https://jira.jboss.org/browse/ISPN-734 Project: Infinispan Issue Type: Feature Request Reporter: Tobias Sarnowski Assignee: Manik Surtani Redis supports atomic access to values of type list and set. It would be great to have a similar functionality in infinispan. It enables infinispan to replace some database architectures completly. http://code.google.com/p/redis/ "Redis is an advanced key-value store. It is similar to memcached but the dataset is not volatile, and values can be strings, exactly like in memcached, but also lists, sets, and ordered sets. All this data types can be manipulated with atomic operations to push/pop elements, add/remove elements, perform server side union, intersection, difference between sets, and so forth." I think sorting is not interesting but the atomic collection accesses are. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (ISPN-710) verify compatibility between 4.2 and jgroups 2.11

by Mircea Markus (JIRA)

verify compatibility between 4.2 and jgroups 2.11 -------------------------------------------------- Key: ISPN-710 URL: https://jira.jboss.org/browse/ISPN-710 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 4.2.0.Final This is needed because 2.11 might replace 2.10 in AS at some point. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-735) Bug in the cache event notifications {CacheStarted, CacheStopped, ViewChanged}

by Thomas Fuller (JIRA)

Bug in the cache event notifications {CacheStarted, CacheStopped, ViewChanged} ------------------------------------------------------------------------------ Key: ISPN-735 URL: https://jira.jboss.org/browse/ISPN-735 Project: Infinispan Issue Type: Bug Components: Listeners Affects Versions: 4.1.0.Final Reporter: Thomas Fuller Assignee: Manik Surtani I am currently working on adding some functionality to the Grails Infinispan Plugin, which relies on Infinispan-4.1.0.FINAL (Radegast). This particular functionality is expressed as a mixin and will allow the developer to use a closure to receive event notifications from the cache -- for example: agentCache.onCacheEntryLoaded { log.info ("=====> Cache entry loaded: $it") } I have a basic unit test for each of the events detailed in the Listener documentation here: http://docs.jboss.org/infinispan/4.0/apidocs/org/infinispan/notifications... however the following three annotations are not being registered (whereas all the others are): import org.infinispan.notifications.cachemanagerlistener.annotation.CacheStarted import org.infinispan.notifications.cachemanagerlistener.annotation.CacheStopped import org.infinispan.notifications.cachemanagerlistener.annotation.ViewChanged Instead I'm receiving a message like the following when my test application starts: cachelistener.CacheNotifierImpl Attempted to register listener of class class com.coherentlogic.grails.infinispan.listeners.CacheStoppedListener, but no valid,public methods annotated with method-level event annotations found! Ignoring listener. and likewise my unit tests are also failing. Here's an example of one of the listener implementations which works: @Listener class CacheEntryCreatedListener { private def closure @CacheEntryCreated public void cacheEntryCreated (cacheEntryCreatedEvent) { closure?.call (cacheEntryCreatedEvent) } } Here's an example of one of the listener implementations which does not work: @Listener class CacheStoppedListener { private def closure @CacheStopped public void cacheStopped (cacheStoppedEvent) { closure?.call (cacheStoppedEvent) } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
7
0 / 0

[JBoss JIRA] Created: (ISPN-715) Eager locking a single node should only acquire a single lock

by Erik Salter (JIRA)

Eager locking a single node should only acquire a single lock ------------------------------------------------------------- Key: ISPN-715 URL: https://jira.jboss.org/browse/ISPN-715 Project: Infinispan Issue Type: Feature Request Reporter: Erik Salter Assignee: Manik Surtani The new eager/explicit lock for a single node feature in 4.2.0 can be further optimized. Right now, a local lock and a lock on the node where the key is hashed is acquired. To increase throughput and minimize deadlock occurrences, we should only acquire the one lock (on the node). (Obviously, if the key is hashed to the local node, the local lock and the node lock are one in the same). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2010