November 2010 - infinispan-issues

[JBoss JIRA] Created: (ISPN-522) InfinispanDirectoryIOTest not closing all test CacheManagers

by Sanne Grinovero (JIRA)

InfinispanDirectoryIOTest not closing all test CacheManagers ------------------------------------------------------------ Key: ISPN-522 URL: https://jira.jboss.org/browse/ISPN-522 Project: Infinispan Issue Type: Bug Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.1.0.CR1 -- 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

13 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-501) chunks might be deleted while Searcher is iterating

by Sanne Grinovero (JIRA)

chunks might be deleted while Searcher is iterating --------------------------------------------------- Key: ISPN-501 URL: https://jira.jboss.org/browse/ISPN-501 Project: Infinispan Issue Type: Bug Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Critical Fix For: 4.1.0.CR1, 5.0.0.BETA1 This one is quite nasty: java.io.IOException: Chunk id = [ 5 ] does not exist for file [ _sc.cfs ] for index [ iname ], file position: [ 88420 ], file size: [ 93015 ] at org.infinispan.lucene.InfinispanIndexIO$InfinispanIndexInput.readBytes(InfinispanIndexIO.java:150) at org.apache.lucene.store.IndexInput.readBytes(IndexInput.java:61) at org.apache.lucene.index.CompoundFileReader$CSIndexInput.readInternal(CompoundFileReader.java:247) at org.apache.lucene.store.BufferedIndexInput.readBytes(BufferedIndexInput.java:136) at org.apache.lucene.index.SegmentReader$Norm.bytes(SegmentReader.java:469) at org.apache.lucene.index.SegmentReader.getNorms(SegmentReader.java:1090) at org.apache.lucene.index.SegmentReader.norms(SegmentReader.java:1096) at org.apache.lucene.search.TermQuery$TermWeight.scorer(TermQuery.java:72) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:250) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:175) at org.apache.lucene.search.Searcher.search(Searcher.java:181) at org.infinispan.lucene.profiling.LuceneReaderThread.testLoop(LuceneReaderThread.java:63) at org.infinispan.lucene.profiling.LuceneUserThread.run(LuceneUserThread.java:55) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Easily reproducible by starting "mvn test -Dtest=PerformanceCompareStressTest" with the currently committed parameters (r1925) I'll likely need an AtomicMap or use transactions while reading? -- 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

13 years, 4 months

2
3
0 / 0

[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

13 years, 4 months

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

13 years, 4 months

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

13 years, 4 months

3
11
0 / 0

[JBoss JIRA] Created: (ISPN-799) JoinTask as it invalidates L1 entries should be given precedence in acquiring locks

by Vladimir Blagojevic (JIRA)

JoinTask as it invalidates L1 entries should be given precedence in acquiring locks ------------------------------------------------------------------------------------ Key: ISPN-799 URL: https://jira.jboss.org/browse/ISPN-799 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 4.2.0.CR1 Reporter: Vladimir Blagojevic Assignee: Manik Surtani Fix For: 4.2.0.Final, 5.0.0.Final The SingleJoinTest transaction test failure itself is intermittent due to the way addresses are organised in the hash wheel, so you are correct that it is a timing issue. Anyway, it still is a very real problem. Just to re-iterate and to make sure we are talking about the same thing: 1. View is {A, B, C} 2. K is mapped to {A, B} 3. A tx starts to update K, and is prepared. Locks now held for K on {A, B} 4. D joins. D is placed on the hash wheel between A and B. So the new view is {A, D, B, C} 5. As per the test (artificial, I know, but could still happen), the tx waits for a long time before committing. In the case of the test, artificially waits until D has finished joining before committing, by use of a latch. 6. D never joins as even though it receives the prepare for the tx and could potentially commit itself (as a new owner), it fails as it is unable to invalidate K on B. There are a few solutions here: 1) This is pretty easy to detect. Attempt to acquire the lock with a smaller lock acquisition timeout and if the transaction is still stuck, abort the transaction and proceed with the join. 2) If the blocking node is *not* the transaction originator (as in this case: the tx was started on A), then just force lock removal and tx rollback on B *only*. Let the tx complete on A, since the new joiner will receive the transactional event and will be able to apply it as a new owner. My vote is to go for solution 1 - a bit more crude, but 2 would be very complex to implement. And even then, would only solve for the invalidation being blocked on a node that did not originate the transaction. E.g., the tx originated on A but the lock issue was on B. If, however, the tx originated on B, *and* B no longer owns the entry in question, then 2 is no longer a solution and the only solution would be 1. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
4
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

13 years, 4 months

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

13 years, 5 months

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

13 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-808) Provide programmatic access to RemoteCacheManager configuration data

by Richard Achmatowicz (JIRA)

Provide programmatic access to RemoteCacheManager configuration data -------------------------------------------------------------------- Key: ISPN-808 URL: https://jira.jboss.org/browse/ISPN-808 Project: Infinispan Issue Type: Bug Affects Versions: 4.1.0.Final, 4.2.0.CR2 Reporter: Richard Achmatowicz Assignee: Mircea Markus Fix For: 4.2.0.Final The javadoc for the interface org.infinispan.client.hotrod.RemoteCache incorrectly marks a number of operations as supported, whereas the code throws an UnsupportedOperationException when the se methods are invoked. The methods in question are: void evict() Configuration getConfiguration() void addListener() Set<Object> getListeners() void removeListener() -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2010