October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3672) Remote Query test failure in case of clustered hotrod server configured with Infinispan directory_provider

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3672?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3672: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1025318 > Remote Query test failure in case of clustered hotrod server configured with Infinispan directory_provider > ---------------------------------------------------------------------------------------------------------- > > Key: ISPN-3672 > URL: https://issues.jboss.org/browse/ISPN-3672 > Project: Infinispan > Issue Type: Bug > Components: Querying > Reporter: Anna Manukyan > Assignee: Sanne Grinovero > Attachments: MultiHotRodServerIspnDirQueryTest.java, MultiHotRodServerIspnDirReplQueryTest.java, MultiHotRodServerQueryTest.java > > > I've added new tests, where the cache configuration is following: > 2 clustered HotRod Servers configured with indexing enabled caches and using Infinispan as a directory_provider. > When the test is putting some data into the caches and then perform query on it, the query doesn't return any results. Even sometimes when getting the entry using key from the first cache, the entry is null. > The failing tests are MultiHotRodServerIspnDirReplQueryTest and MultiHotRodServerIspnDirQueryTest which are extended from MultiHotRodServerQueryTest. > In the first case the ISPN directory related caches are replicated, in the second case the caches are local. > You can find the test attached. > Also, if I'm trying to add the following line to the cache configuration: > {code} > .addProperty("default.indexmanager", "org.infinispan.query.indexmanager.InfinispanIndexManager") > {code} > then, I'm getting the following exception: > {code} > org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[2] returned server error (status=0x85): org.infinispan.commons.CacheException: java.lang.NoSuchMethodError: org.apache.avro.io.BinaryEncoder: method <init>()V not found > at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143) > at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:213) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) > at org.infinispan.client.hotrod.query.MultiHotRodServerQueryTest.testAttributeQuery(MultiHotRodServerQueryTest.java:68) > {code} -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3672) Remote Query test failure in case of clustered hotrod server configured with Infinispan directory_provider

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-3672?page=com.atlassian.jira.plugin.... ] Anna Manukyan updated ISPN-3672: -------------------------------- Attachment: MultiHotRodServerIspnDirQueryTest.java MultiHotRodServerIspnDirReplQueryTest.java MultiHotRodServerQueryTest.java > Remote Query test failure in case of clustered hotrod server configured with Infinispan directory_provider > ---------------------------------------------------------------------------------------------------------- > > Key: ISPN-3672 > URL: https://issues.jboss.org/browse/ISPN-3672 > Project: Infinispan > Issue Type: Bug > Components: Querying > Reporter: Anna Manukyan > Assignee: Sanne Grinovero > Attachments: MultiHotRodServerIspnDirQueryTest.java, MultiHotRodServerIspnDirReplQueryTest.java, MultiHotRodServerQueryTest.java > > > I've added new tests, where the cache configuration is following: > 2 clustered HotRod Servers configured with indexing enabled caches and using Infinispan as a directory_provider. > When the test is putting some data into the caches and then perform query on it, the query doesn't return any results. Even sometimes when getting the entry using key from the first cache, the entry is null. > The failing tests are MultiHotRodServerIspnDirReplQueryTest and MultiHotRodServerIspnDirQueryTest which are extended from MultiHotRodServerQueryTest. > In the first case the ISPN directory related caches are replicated, in the second case the caches are local. > You can find the test attached. > Also, if I'm trying to add the following line to the cache configuration: > {code} > .addProperty("default.indexmanager", "org.infinispan.query.indexmanager.InfinispanIndexManager") > {code} > then, I'm getting the following exception: > {code} > org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[2] returned server error (status=0x85): org.infinispan.commons.CacheException: java.lang.NoSuchMethodError: org.apache.avro.io.BinaryEncoder: method <init>()V not found > at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143) > at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:213) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) > at org.infinispan.client.hotrod.query.MultiHotRodServerQueryTest.testAttributeQuery(MultiHotRodServerQueryTest.java:68) > {code} -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3672) Remote Query test failure in case of clustered hotrod server configured with Infinispan directory_provider

by Anna Manukyan (JIRA)

Anna Manukyan created ISPN-3672: ----------------------------------- Summary: Remote Query test failure in case of clustered hotrod server configured with Infinispan directory_provider Key: ISPN-3672 URL: https://issues.jboss.org/browse/ISPN-3672 Project: Infinispan Issue Type: Bug Components: Querying Reporter: Anna Manukyan Assignee: Sanne Grinovero I've added new tests, where the cache configuration is following: 2 clustered HotRod Servers configured with indexing enabled caches and using Infinispan as a directory_provider. When the test is putting some data into the caches and then perform query on it, the query doesn't return any results. Even sometimes when getting the entry using key from the first cache, the entry is null. The failing tests are MultiHotRodServerIspnDirReplQueryTest and MultiHotRodServerIspnDirQueryTest which are extended from MultiHotRodServerQueryTest. In the first case the ISPN directory related caches are replicated, in the second case the caches are local. You can find the test attached. Also, if I'm trying to add the following line to the cache configuration: {code} .addProperty("default.indexmanager", "org.infinispan.query.indexmanager.InfinispanIndexManager") {code} then, I'm getting the following exception: {code} org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[2] returned server error (status=0x85): org.infinispan.commons.CacheException: java.lang.NoSuchMethodError: org.apache.avro.io.BinaryEncoder: method <init>()V not found at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143) at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99) at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:213) at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) at org.infinispan.client.hotrod.query.MultiHotRodServerQueryTest.testAttributeQuery(MultiHotRodServerQueryTest.java:68) {code} -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2475) When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2475?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2475: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1025258 > When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners > ----------------------------------------------------------------------------------- > > Key: ISPN-2475 > URL: https://issues.jboss.org/browse/ISPN-2475 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.0.FINAL, 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: William Burns > Fix For: 6.1.0.Final > > > Copied from the parent: > {quote} > [...] we can keep track of the consistent hashes in the last 10 minutes (or whatever the L1 lifespan is) and the time of the last invalidation sent for each key. When we need to send a new invalidation, we add the owners in all the consistent hashes since the last invalidation to the invalidation command recipients. > {quote} -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2475) When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2475?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2475: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1025258|https://bugzilla.redhat.com/show_bug.cgi?id=1025258] When L1.onRehash is enabled (by default) and the node loses ownership of some keys, it does not remove them immediately but keeps them in L1. New owners should record this node in L1ManagerImpl.requestors in order to send L1 invalidation when the key is overwritten. However, this is not implemented. The result is that node may read outdated entry (the cluster is not consistent). There's a comment about the intended behaviour in StateConsumerImpl, line 385. > When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners > ----------------------------------------------------------------------------------- > > Key: ISPN-2475 > URL: https://issues.jboss.org/browse/ISPN-2475 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.0.FINAL, 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: William Burns > Fix For: 6.1.0.Final > > > Copied from the parent: > {quote} > [...] we can keep track of the consistent hashes in the last 10 minutes (or whatever the L1 lifespan is) and the time of the last invalidation sent for each key. When we need to send a new invalidation, we add the owners in all the consistent hashes since the last invalidation to the invalidation command recipients. > {quote} -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2475) When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-2475?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-2475: ------------------------------ Affects Version/s: 6.0.0.CR1 > When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners > ----------------------------------------------------------------------------------- > > Key: ISPN-2475 > URL: https://issues.jboss.org/browse/ISPN-2475 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.0.FINAL, 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: William Burns > Fix For: 6.1.0.Final > > > Copied from the parent: > {quote} > [...] we can keep track of the consistent hashes in the last 10 minutes (or whatever the L1 lifespan is) and the time of the last invalidation sent for each key. When we need to send a new invalidation, we add the owners in all the consistent hashes since the last invalidation to the invalidation command recipients. > {quote} -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3668) Lucene index performance regression test

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3668?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3668: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Lucene index performance regression test > ---------------------------------------- > > Key: ISPN-3668 > URL: https://issues.jboss.org/browse/ISPN-3668 > Project: Infinispan > Issue Type: Feature Request > Components: Lucene Directory > Reporter: Michal Linhard > Assignee: Michal Linhard > Priority: Minor > Fix For: 6.0.0.CR2 > > > Based on discussion for https://github.com/infinispan/infinispan/pull/2144 > I'm gonna create a performance regression test, that runs PerformanceCompareStressTest periodically. For this I need the main method to be a bit more parametrized and I need an easily parsable output. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3668) Lucene index performance regression test

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3668?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3668: ---------------------------------- Fix Version/s: 6.0.0.CR2 > Lucene index performance regression test > ---------------------------------------- > > Key: ISPN-3668 > URL: https://issues.jboss.org/browse/ISPN-3668 > Project: Infinispan > Issue Type: Feature Request > Components: Lucene Directory > Reporter: Michal Linhard > Assignee: Michal Linhard > Priority: Minor > Fix For: 6.0.0.CR2 > > > Based on discussion for https://github.com/infinispan/infinispan/pull/2144 > I'm gonna create a performance regression test, that runs PerformanceCompareStressTest periodically. For this I need the main method to be a bit more parametrized and I need an easily parsable output. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3668) Lucene index performance regression test

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3668?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-3668: --------------------------------------- {quote}I'd say v3 is enough for now.{quote} +1 > Lucene index performance regression test > ---------------------------------------- > > Key: ISPN-3668 > URL: https://issues.jboss.org/browse/ISPN-3668 > Project: Infinispan > Issue Type: Feature Request > Components: Lucene Directory > Reporter: Michal Linhard > Assignee: Michal Linhard > Priority: Minor > Fix For: 6.0.0.CR2 > > > Based on discussion for https://github.com/infinispan/infinispan/pull/2144 > I'm gonna create a performance regression test, that runs PerformanceCompareStressTest periodically. For this I need the main method to be a bit more parametrized and I need an easily parsable output. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3617) Inconsistent L1 in non-tx distributed cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3617: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1017796|https://bugzilla.redhat.com/show_bug.cgi?id=1017796] from POST to ON_QA > Inconsistent L1 in non-tx distributed cache > ------------------------------------------- > > Key: ISPN-3617 > URL: https://issues.jboss.org/browse/ISPN-3617 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.7.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.CR2, 6.0.0.Final > > > When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation. -- 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

10 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013