January 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2689) Support storage of indexes of Apache Lucene 4

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2689?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-2689: --------------------------------------- James, I've sent a pull request as a form of preview of my code for this: https://github.com/infinispan/infinispan/pull/1619 If you could help battle-test that with your systems, that would be very useful feedback. If we're quick enough we can merge it before 5.2 Final by marking it as experimental. > Support storage of indexes of Apache Lucene 4 > --------------------------------------------- > > Key: ISPN-2689 > URL: https://issues.jboss.org/browse/ISPN-2689 > Project: Infinispan > Issue Type: Feature Request > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 5.2.0.Final > > Attachments: ISPN-2689-hack-main.diff, ISPN-2689-hack-test.diff > > > The current Lucene Directory supports Lucene version from 2.9 to 3.6, > but Lucene 4 made consistent changes which might need a new module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2689) Support storage of indexes of Apache Lucene 4

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2689?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-2689: ---------------------------------- Fix Version/s: 5.2.0.Final (was: 6.0.0.Final) (was: 6.0.0.Beta1) > Support storage of indexes of Apache Lucene 4 > --------------------------------------------- > > Key: ISPN-2689 > URL: https://issues.jboss.org/browse/ISPN-2689 > Project: Infinispan > Issue Type: Feature Request > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 5.2.0.Final > > Attachments: ISPN-2689-hack-main.diff, ISPN-2689-hack-test.diff > > > The current Lucene Directory supports Lucene version from 2.9 to 3.6, > but Lucene 4 made consistent changes which might need a new module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2729) [FineGrainedAtomicMap] Class Cast Exception in Clustered + Repeatable Read + Write Skew

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2729?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-2729: ----------------------------------- Hi Galder, I only extended the tests ClusteredAPITest and FineGrainedAtomicMapAPITest and I changed the configuration to Repeatable Read + Write Skew. If this combination is not supported, an exception should be thrown (in my opinion). The use case we have is Hibernate OGM + Infinispan. In more detail, a java application developed on top of Hibernate OGM. Hibernate OGM is configured to persist the java objects in Infinispan. Sanne worked in this with Sérgio, so he may have more details. > [FineGrainedAtomicMap] Class Cast Exception in Clustered + Repeatable Read + Write Skew > --------------------------------------------------------------------------------------- > > Key: ISPN-2729 > URL: https://issues.jboss.org/browse/ISPN-2729 > Project: Infinispan > Issue Type: Bug > Components: Core API, Fine-grained API, Locking and Concurrency > Environment: Mac OSx 10.5, Java 1.6 sun-jdk, maven 3.0.4 > Reporter: Pedro Ruivo > Assignee: Galder Zamarreño > Labels: atomic_map, clustered, write-skew > Fix For: 5.2.0.Final > > > Test case available in here [1] > When a transaction commits, the write skew check performs the validation by casting the cache entry to a ClusteredRepeatableReadEntry. However, the entry is a DeltaAwareCacheEntry. > This happens when you have operations over a map inside a transaction. > The tests failing are: > WriteSkewFineGrainedAtomicMapAPITest.testSizeOnCache() > WriteSkewFineGrainedAtomicMapAPITest.testCreateMapInTx() > [1]https://github.com/pruivo/infinispan/commits/t_atomic_map_issue -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2693) ByteArrayKey should print out its hashCode

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2693?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2693: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1618 > ByteArrayKey should print out its hashCode > ------------------------------------------ > > Key: ISPN-2693 > URL: https://issues.jboss.org/browse/ISPN-2693 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 5.2.0.Final > > > When a ByteArrayKey is printed out, the format is {{ByteArrayKey{data=ByteArray{size=..., hashCode=..., array=...}}}} > However, ByteArray computes hashCode using array.hashCode() instead of Arrays.hashCode(array) and, therefore, two equal ByteArrayKeys have different hashCode when printed out. > Another way to fix that could be using Arrays.hashCode(array) in Util.printArray() (although I am not sure whether this could break anything). > As the result is pretty unexpected, I consider this a bug rather than a feature request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2726) Sporadic NPE in KeyAffinityServiceImpl

by Thomas Fromm (JIRA)

[ https://issues.jboss.org/browse/ISPN-2726?page=com.atlassian.jira.plugin.... ] Thomas Fromm commented on ISPN-2726: ------------------------------------ It could be possible, that this appeared during rehash. After several hours of stress testing during night some nodes left and get merged later. At next morning one of the 8 nodes had this problem. > Sporadic NPE in KeyAffinityServiceImpl > -------------------------------------- > > Key: ISPN-2726 > URL: https://issues.jboss.org/browse/ISPN-2726 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.0.CR1 > Reporter: Thomas Fromm > Assignee: Galder Zamarreño > Fix For: 5.2.0.Final > > > The NPE appears not often, unfortunality with enabled TRACE logging, it never appears :-( I'll keep trying to get TRACEs. > Exception in thread "pool-70-thread-1" java.lang.NullPointerException > at org.infinispan.affinity.KeyAffinityServiceImpl.getAddressForKey(KeyAffinityServiceImpl.java:347) > at org.infinispan.affinity.KeyAffinityServiceImpl.access$700(KeyAffinityServiceImpl.java:59) > at org.infinispan.affinity.KeyAffinityServiceImpl$KeyGeneratorWorker.generateKeys(KeyAffinityServiceImpl.java:270) > at org.infinispan.affinity.KeyAffinityServiceImpl$KeyGeneratorWorker.run(KeyAffinityServiceImpl.java:242) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2737) Thread naming anomaly when reporting lock timeout

by Michal Linhard (JIRA)

[ https://issues.jboss.org/browse/ISPN-2737?page=com.atlassian.jira.plugin.... ] Michal Linhard commented on ISPN-2737: -------------------------------------- So this is an error that happened on node01 in MemcachedServerWorker during replication of PutKeyValueCommand(key=memcachedCache#key763328) to node03. The PutKeyValueCommand on remote node03 fails, the exception is returned to node01 with stacktrace from node03. Shouldn't we do more informative logging in the MemcachedServerWorker i.e. the cache where the request originates ? Like having local stack trace + remote stacktrace in causing exception... ? > Thread naming anomaly when reporting lock timeout > ------------------------------------------------- > > Key: ISPN-2737 > URL: https://issues.jboss.org/browse/ISPN-2737 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency > Affects Versions: 5.2.0.CR1 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Minor > > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... > {code} > 11:47:30,859 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (MemcachedServerWorker-277) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [3 seconds] on key [memcachedCache#key763328] for requestor [Thread[OOB-127,null,5,Thread Pools]]! Lock held by [Thread[OOB-150,null,5,Thread Pools]] > at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:217) [infinispan-core-5.2.0.CR1-redhat-1.jar:5.2.0.CR1-redhat-1] > at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLockNoCheck(LockManagerImpl.java:200) [infinispan-core-5.2.0.CR1-redhat-1.jar:5.2.0.CR1-redhat-1] > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockKey(AbstractLockingInterceptor.java:114) [infinispan-core-5.2.0.CR1-redhat-1.jar:5.2.0.CR1-redhat-1] > .... > at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.2.5.Final-redhat-1.jar:3.2.5.Final-redhat-1] > at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.2.5.Final-redhat-1.jar:3.2.5.Final-redhat-1] > at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2640) [jgroups-3.2.5.Final-redhat-1.jar:3.2.5.Final-redhat-1] > at org.jgroups.protocols.TP.passMessageUp(TP.java:1287) [jgroups-3.2.5.Final-redhat-1.jar:3.2.5.Final-redhat-1] > at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1850) [jgroups-3.2.5.Final-redhat-1.jar:3.2.5.Final-redhat-1] > at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1823) [jgroups-3.2.5.Final-redhat-1.jar:3.2.5.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_38] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_38] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38] > {code} > note the thread name "MemcachedServerWorker" in an operation coming from the JGroups stack... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2693) ByteArrayKey should print out its hashCode

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2693?page=com.atlassian.jira.plugin.... ] Work on ISPN-2693 started by Galder Zamarreño. > ByteArrayKey should print out its hashCode > ------------------------------------------ > > Key: ISPN-2693 > URL: https://issues.jboss.org/browse/ISPN-2693 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 5.2.0.Final > > > When a ByteArrayKey is printed out, the format is {{ByteArrayKey{data=ByteArray{size=..., hashCode=..., array=...}}}} > However, ByteArray computes hashCode using array.hashCode() instead of Arrays.hashCode(array) and, therefore, two equal ByteArrayKeys have different hashCode when printed out. > Another way to fix that could be using Arrays.hashCode(array) in Util.printArray() (although I am not sure whether this could break anything). > As the result is pretty unexpected, I consider this a bug rather than a feature request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2726) Sporadic NPE in KeyAffinityServiceImpl

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2726?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2726: ---------------------------------------- Hmmm, odd. Having looked around no other call to getConsistentHash() expects some kind of null return, so it must be due to some race condition. Could you tell us more about the circumstances under which this exception appears? Maybe the call is happening during rehashing? If the issue is related to rehashing, we could maybe halt KeyAffinityServiceImpl generating keys while rehashing is on-going. > Sporadic NPE in KeyAffinityServiceImpl > -------------------------------------- > > Key: ISPN-2726 > URL: https://issues.jboss.org/browse/ISPN-2726 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.0.CR1 > Reporter: Thomas Fromm > Assignee: Galder Zamarreño > Fix For: 5.2.0.Final > > > The NPE appears not often, unfortunality with enabled TRACE logging, it never appears :-( I'll keep trying to get TRACEs. > Exception in thread "pool-70-thread-1" java.lang.NullPointerException > at org.infinispan.affinity.KeyAffinityServiceImpl.getAddressForKey(KeyAffinityServiceImpl.java:347) > at org.infinispan.affinity.KeyAffinityServiceImpl.access$700(KeyAffinityServiceImpl.java:59) > at org.infinispan.affinity.KeyAffinityServiceImpl$KeyGeneratorWorker.generateKeys(KeyAffinityServiceImpl.java:270) > at org.infinispan.affinity.KeyAffinityServiceImpl$KeyGeneratorWorker.run(KeyAffinityServiceImpl.java:242) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2662) Invalid formatting character in TxCompletionNotificationCommand

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2662?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2662: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1615 > Invalid formatting character in TxCompletionNotificationCommand > --------------------------------------------------------------- > > Key: ISPN-2662 > URL: https://issues.jboss.org/browse/ISPN-2662 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Adrian Nistor > Priority: Minor > Fix For: 5.2.0.Final > > > Trace logging reveals that in {{org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand.forwardCommandRemotely}} is a typo - {{%w}} instead of {{%s}} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2729) [FineGrainedAtomicMap] Class Cast Exception in Clustered + Repeatable Read + Write Skew

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2729?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2729: ---------------------------------------- Pedro, where are these tests coming from? Do you have a particular use case for this? There's currently no support for versioned delta-aware cache entries. Given that concurrent version updates could be possible within fine grained maps, it'd need some careful thought and testing. For 5.2, we could add a message/error to indicate the unsupported nature of this combination of settings. > [FineGrainedAtomicMap] Class Cast Exception in Clustered + Repeatable Read + Write Skew > --------------------------------------------------------------------------------------- > > Key: ISPN-2729 > URL: https://issues.jboss.org/browse/ISPN-2729 > Project: Infinispan > Issue Type: Bug > Components: Core API, Fine-grained API, Locking and Concurrency > Environment: Mac OSx 10.5, Java 1.6 sun-jdk, maven 3.0.4 > Reporter: Pedro Ruivo > Assignee: Galder Zamarreño > Labels: atomic_map, clustered, write-skew > Fix For: 5.2.0.Final > > > Test case available in here [1] > When a transaction commits, the write skew check performs the validation by casting the cache entry to a ClusteredRepeatableReadEntry. However, the entry is a DeltaAwareCacheEntry. > This happens when you have operations over a map inside a transaction. > The tests failing are: > WriteSkewFineGrainedAtomicMapAPITest.testSizeOnCache() > WriteSkewFineGrainedAtomicMapAPITest.testCreateMapInTx() > [1]https://github.com/pruivo/infinispan/commits/t_atomic_map_issue -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2013