January 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2150) Data Rehash Event: getMembersAtStart/End returns empty set

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2150?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-2150: ------------------------------------- In 5.2 getMembersAtStart/End returns null because these are no longer set. They should return the members collection from the corresponding CH. Very easy to fix. > Data Rehash Event: getMembersAtStart/End returns empty set > ---------------------------------------------------------- > > Key: ISPN-2150 > URL: https://issues.jboss.org/browse/ISPN-2150 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, Listeners, State transfer > Affects Versions: 5.1.5.FINAL > Environment: 5.2.0-SNAPSHOT master branch > Reporter: Pedro Ruivo > Assignee: Adrian Nistor > Labels: DataRehash, DateRehashEvent, Listener > Fix For: 5.3.0.Final > > > When the event is trigger the getMembersAtStart/End() returns an empty set. > A test case can be found in here [1] and you can integrate it in the master if you want. =) > Cheers > [1] https://github.com/pruivo/infinispan/blob/data_rehash_event/core/src/test... -- 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-2724) L1 is not used for write-operations (for node affine keys)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2724?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2724: -------------------------------- Fix Version/s: 5.2.1 5.3.0.Final > L1 is not used for write-operations (for node affine keys) > ---------------------------------------------------------- > > Key: ISPN-2724 > URL: https://issues.jboss.org/browse/ISPN-2724 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.2.0.CR1 > Reporter: Thomas Fromm > Assignee: Vladimir Blagojevic > Fix For: 5.2.1, 5.3.0.Final > > Attachments: L1WriteTest.java > > > I need to make sure, that a key written on a node is present in L1, even when the owner is a different node. > Attached an example which shows the expected behaviour. -- 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-2513) org.infinispan.tx.StaleLockRecoveryTest.testStaleLock fails randomly

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2513?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2513: ----------------------------------- Fix Version/s: 5.3.0.Final (was: 5.2.0.Final) > org.infinispan.tx.StaleLockRecoveryTest.testStaleLock fails randomly > -------------------------------------------------------------------- > > Key: ISPN-2513 > URL: https://issues.jboss.org/browse/ISPN-2513 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Anna Manukyan > Assignee: Manik Surtani > Labels: testsuite_stability > Fix For: 5.3.0.Final > > > The test fails randomly during Infinispan testsuite run on IBM-JDK7. > You can find the logs here: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > The bug doesn't appear when the test is run separately. -- 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-2536) Hotrod client doesn't query two servers by RoundRobin (distributed mode)

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2536?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-2536. ------------------------------------ Resolution: Rejected For performance reasons, with distributed caches we make a conscious decision to always go to the main owner, so no round robin is used. Key performance gain comes with async set ups where directing requests to main owner allows for replication to be async and only go to a different owner upon failover or exceptional conditional, making the chances of not finding up-to-date information slimmer. > Hotrod client doesn't query two servers by RoundRobin (distributed mode) > ------------------------------------------------------------------------ > > Key: ISPN-2536 > URL: https://issues.jboss.org/browse/ISPN-2536 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.Beta4 > Reporter: Astaldo Guy > Assignee: Galder Zamarreño > Priority: Critical > > I am in the process of doing a PoC on Infinispan. > I want to configure two nodes in a cluster, containing different key/value pairs. > Now a client connects to the cloud and queries multiple keys. > The problem is, that the client only asks on that node, that it first connects. > It seems, that I cant get the client to ask the second noce, if the first does not has a value for this key. > In the forum post is a zip with an eclipse/maven project to reproduce that error. -- 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-2708) Configuration of infinispan/global/serialization does not work as documented

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2708?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2708: ----------------------------------- Fix Version/s: 5.2.0.Final > Configuration of infinispan/global/serialization does not work as documented > ---------------------------------------------------------------------------- > > Key: ISPN-2708 > URL: https://issues.jboss.org/browse/ISPN-2708 > Project: Infinispan > Issue Type: Feature Request > Components: Marshalling > Affects Versions: 5.2.0.CR1 > Reporter: Robert Stupp > Assignee: Galder Zamarreño > Fix For: 5.2.0.Final > > > The definition of element {{marshallerClass}} in {{infinispan-config-5.2.xsd}} says: ??Fully qualified name of the marshaller to use. It must implement org.infinispan.marshall.StreamingMarshaller??. > But if I add a custom marshaller class Infinispan will not start because of a *ClassCastException cannot be cast to org.infinispan.marshall.VersionAwareMarshaller*: > {noformat} > Caused by: org.infinispan.config.ConfigurationException: org.infinispan.CacheException: Unable to construct a GlobalComponentRegistry! > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:379) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > at com.hrs.frw.commons.cache.infinispan.InfinispanCacheFactoryImpl.afterPropertiesSet(InfinispanCacheFactoryImpl.java:159) [frw-thirdparty-infinispan-dev-SNAPSHOT.jar:20920] > at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514) [spring-beans-3.1.1.RELEASE.jar:3.1.1.RELEASE] > at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452) [spring-beans-3.1.1.RELEASE.jar:3.1.1.RELEASE] > ... 23 more > Caused by: org.infinispan.CacheException: Unable to construct a GlobalComponentRegistry! > at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:146) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:375) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > ... 26 more > Caused by: java.lang.ClassCastException: com.....MarshallerImpl cannot be cast to org.infinispan.marshall.VersionAwareMarshaller > at org.infinispan.factories.MarshallerFactory.construct(MarshallerFactory.java:48) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:290) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:246) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:86) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:811) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:220) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:175) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:295) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:272) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:140) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1] > ... 27 more > {noformat} -- 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-2699) Failed ping on startup can leave socket dirty

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2699?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2699: ----------------------------------- Fix Version/s: 5.2.0.Final (was: 5.3.0.Final) > Failed ping on startup can leave socket dirty > --------------------------------------------- > > Key: ISPN-2699 > URL: https://issues.jboss.org/browse/ISPN-2699 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > Fix For: 5.2.0.Final > > > Ping on startup in TransportObjectFactory.makeObject does not check the return value of ping operation, neither the tcpTransport.isValid(). > Therefore, if a HotRodClientException is thrown when the response header is read from socket, the socket is left in a dirty state. > In our case this resulted in reading response to previous request (the request was written but the response was not read due to some timeout and then, when another request was executed it read the response to the first request). This caused {{ISPN004004: Invalid message id. Expected 2930 and received 212}} -- 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: ----------------------------------- Fix Version/s: 5.2.0.Final (was: 5.3.0.Final) > 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-2712) Initial state transfer doesn't appear to all be persisted when using eviction in a replicated cluster

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2712?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-2712: ------------------------------------- It seems that CacheStoreInterceptor does not write the entry in store if the cache operation is transactional and local mode is forced. I doubt this works as intended, it is most likely an old bug but it was probably never observed because people rarely force CACHE_MODE_LOCAL. State transfer forces CACHE_MODE_LOCAL but was not transactional in 5.1 so it worked. In 5.2 it is transactional and hits this issue. Unfortunately our state transfer functional tests do not use eviction so the data is always found in the DataContainer and never looked up in the (empty) store, so the problem was well hidden. I've already created a fix that solves the CacheStoreInterceptor issue. Will have a PR on Monday. > Initial state transfer doesn't appear to all be persisted when using eviction in a replicated cluster > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-2712 > URL: https://issues.jboss.org/browse/ISPN-2712 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.CR1 > Reporter: Randall Hauch > Assignee: Adrian Nistor > Priority: Critical > Fix For: 5.2.0.Final > > Attachments: ispn_eviction_log.txt, spectrum-repository-infinispan.xml > > > Using a clustered cache with 2 nodes, where the cache in each node is configured identically with replication, eviction and (non-shared) file cache store. (See attached configuration.) > The first (coordinator) process in the cluster is started and populated with 293 entries. Then the first process continually adds a few entries every 5 seconds. After a short delay, the second process is started, at which point it joins the cluster and starts the state-transfer process; logging shows in the first process that all 293 entries are transferred to the new cluster member, and the second log shows that they are all received. The second process then attempts to look for a specific entry that was created during initial population in the first process. This fails to find the existing entry. > By enabling trace logging and "IDE breakpoint output messages" around state transfer, it's visible that from the 293 keys, only 218 are placed into the cache, the others being lost. > (This problem was originally discovered when clustering ModeShape, which behaves roughly in the manner described above. The initial entries that are populated upon initialization are content created when a new repository is started. The second process looks for this content, and if it finds the content it knows not to create all of this initial content. However, if it doesn't find it, it thinks the repository has not yet been initialized and that it should create the initial content. The problem described by this bug then manifests itself in ModeShape through dozens of exceptions because the repository has been corrupted. See MODE-1745 for details on this problem. ModeShape's corresponding known issue for this issue, ISPN-2712, is MODE-1754.) > The eviction is configured like this: > {code:xml} > <eviction strategy="LIRS" maxEntries="1000"/> > {code} > The attached log file is from the second process (the "receiver" node) and it contains the following key points: > * line 40 - the total number of keys & entries to be transferred = 293 > * line 1352 and from there onwards 1358 / 1364 / i + 6 - the data container's size stops growing at 218, while the other entries are being sent. This means that in effect, they are ignored. > * line 1797 - the loop from {{org.infinispan.statetransfer.StateConsumerImpl#doApplyState}} finishes > Disabling eviction fixes the problem and all 293 nodes are placed in Node2's cache. > (I initially marked this as CRITICAL priority, though it is a blocker for our use of Infinispan 5.2.) -- 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-2756) Enabling/disabling RpcManager statistics via JMX doesn't work

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2756?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2756: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated. Thanks! > Enabling/disabling RpcManager statistics via JMX doesn't work > ------------------------------------------------------------- > > Key: ISPN-2756 > URL: https://issues.jboss.org/browse/ISPN-2756 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 5.2.0.Final > > > The test RpcManagerMBeanTest.testEnableJmxStats tries to write to the "StatisticsEnabled" attribute but fails. The operation doesn't throw an exception, but it does log this WARN message: > {noformat} > 10:43:42,079 WARN (testng-RpcManagerMBeanTest:) [ResourceDMBean] ISPN000043: Exception while writing value for attribute statisticsEnabled > java.lang.NullPointerException > at org.infinispan.jmx.ResourceDMBean$InvokableSetterBasedMBeanAttributeInfo.invoke(ResourceDMBean.java:391) > at org.infinispan.jmx.ResourceDMBean.setNamedAttribute(ResourceDMBean.java:325) > at org.infinispan.jmx.ResourceDMBean.setAttribute(ResourceDMBean.java:212) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.setAttribute(DefaultMBeanServerInterceptor.java:746) > at com.sun.jmx.mbeanserver.JmxMBeanServer.setAttribute(JmxMBeanServer.java:729) > at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:134) > {noformat} > Because statistics are still enabled, the test then fails with an assertion error: > {noformat} > 10:43:42,464 ERROR (testng-RpcManagerMBeanTest:) [UnitTestTestNGListener] Test testEnableJmxStats(org.infinispan.jmx.RpcManagerMBeanTest) failed. > java.lang.AssertionError: expected [-1] but found [1] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:494) > at org.testng.Assert.assertEquals(Assert.java:123) > at org.testng.Assert.assertEquals(Assert.java:165) > at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:138) > {noformat} -- 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-2763) Verify cache used for index storage is not defining any expiry

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2763: ------------------------------------- Summary: Verify cache used for index storage is not defining any expiry Key: ISPN-2763 URL: https://issues.jboss.org/browse/ISPN-2763 Project: Infinispan Issue Type: Feature Request Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 5.2.0.Final Apparently we don't fail fast if Expiry is enabled on the chache used to store a Lucene Directory. I think the Directory implementation should check for this and fail eagerly with an appropriate error message. https://forum.hibernate.org/posting.php?mode=reply&f=9&t=1025238 -- 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