November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-3743) Silence "IllegalStateException: Default cache is in 'STOPPING' state" exceptions

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3743?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3743: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Silence "IllegalStateException: Default cache is in 'STOPPING' state" exceptions > -------------------------------------------------------------------------------- > > Key: ISPN-3743 > URL: https://issues.jboss.org/browse/ISPN-3743 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Labels: testsuite_stability > Fix For: 7.1.0.Alpha1 > > > When a cache in STOPPING state receives a command, the exception is propagated all the way to the caller: > {noformat} > 09:33:02,005 ERROR (testng-NonTxPutIfAbsentDuringLeaveStressTest:) [UnitTestTestNGListener] Test testNodeLeavingDuringPutIfAbsent(org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest) failed. > java.util.concurrent.ExecutionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeC-25987, see cause for remote stack trace > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeC-25987, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41) > Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeD-57301, see cause for remote stack trace > at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41) > Caused by: java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:93) > {noformat} > This causes random failures in NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent. > The originator should either ignore the IllegalStateException or wait for a new cache topology and retry the operation, just like it should for SuspectExceptions (ISPN-2577). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3795: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > QueryInterceptor incorrectly relies on the return value of a RemoveCommand > -------------------------------------------------------------------------- > > Key: ISPN-3795 > URL: https://issues.jboss.org/browse/ISPN-3795 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Fix For: 7.1.0.Alpha1 > > > QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index. > But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index. > QueryInterceptor should probably use the previous value from the context entries to update the index instead. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3790) Document the rules for handling null values in the Equivalence interface

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3790?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3790: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Document the rules for handling null values in the Equivalence interface > ------------------------------------------------------------------------ > > Key: ISPN-3790 > URL: https://issues.jboss.org/browse/ISPN-3790 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Mircea Markus > Fix For: 7.1.0.Alpha1 > > > {{AnyEquivalence.equals(null, null)}} returns false, and {{ByteArrayEquivalence.equals(null, null)}} returns true. > I think ByteArrayEquivalence is correct, and the {{Equivalence.equals()}} javadoc should specify that two {{null}} values should be equal. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3823) Migrators should not pollute each other with their "global" key entries

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3823?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3823: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Migrators should not pollute each other with their "global" key entries > ----------------------------------------------------------------------- > > Key: ISPN-3823 > URL: https://issues.jboss.org/browse/ISPN-3823 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Tristan Tarrant > Fix For: 7.1.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3824) Upgrade to JBoss Transactions 4.17.20

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3824?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3824: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Upgrade to JBoss Transactions 4.17.20 > ------------------------------------- > > Key: ISPN-3824 > URL: https://issues.jboss.org/browse/ISPN-3824 > Project: Infinispan > Issue Type: Component Upgrade > Components: Transactions > Reporter: Sanne Grinovero > Assignee: Mircea Markus > Fix For: 7.1.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3835) Index Update command is processed before the registry listener is triggered

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3835?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3835: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Index Update command is processed before the registry listener is triggered > --------------------------------------------------------------------------- > > Key: ISPN-3835 > URL: https://issues.jboss.org/browse/ISPN-3835 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 6.0.0.Final > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Priority: Critical > Labels: 64QueryBlockers > Fix For: 7.1.0.Alpha1 > > > When using the InfinispanIndexManager backend the master node might receive an index update command about an index which it hasn't defined yet. > Index definitions are triggered by the type registry, which in turn is driven by the ClusterRegistry and an event listener on the ClusterRegistry. It looks like slaves are sending update requests before the master has processed the configuration event. > This leads to index update commands to be lost (with a stacktrace logged) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3843) Remove broadcast/unicast optimization in JGroupsTransport

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3843?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3843: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Remove broadcast/unicast optimization in JGroupsTransport > --------------------------------------------------------- > > Key: ISPN-3843 > URL: https://issues.jboss.org/browse/ISPN-3843 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Fix For: 7.1.0.Alpha1 > > > The broadcast/unicast optimization in JGroupsTransport can break the message ordering for regular messages, because NAKACK[2] and UNICAST[2|3] have their own ordering. > We should test if this optimization really brings any performance benefits and eliminate it, at least for asynchronous commands. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3854) Tests from org.infinispan.eviction package fail randomly with Oracle JDK and constantly with IBM JDK6

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3854?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3854: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Tests from org.infinispan.eviction package fail randomly with Oracle JDK and constantly with IBM JDK6 > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-3854 > URL: https://issues.jboss.org/browse/ISPN-3854 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Alpha2, 7.0.0.Alpha3, 7.0.0.Alpha4 > Reporter: Vitalii Chepeliuk > Assignee: Pedro Ruivo > Priority: Critical > Labels: testsuite_stability > Fix For: 7.0.0.Alpha1, 7.1.0.Alpha1 > > Attachments: EvictionWithPassivationAndConcurrentOperationsTest.log.zip, ManualEvictionWithPassivationAndConcurrentOperationsInPrimaryOwnerTest.log.zip > > > Following tests fail randomly on JDK7 > org.infinispan.eviction.ManualEvictionWithPassivationAndConcurrentOperationsInPrimaryOwnerTest.testScenario6 > org.infinispan.eviction.EvictionWithPassivationAndConcurrentOperationsTest.testScenario6 > OracleJDK7 > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... > IBM7 > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... > OpenJDK7 > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... > And bunch of tests fail on IBM6 > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... > and here > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... > Add windows runs > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3899) XAResourceRecovery implementation needed for transaction recovery in library mode

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3899?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3899: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > XAResourceRecovery implementation needed for transaction recovery in library mode > --------------------------------------------------------------------------------- > > Key: ISPN-3899 > URL: https://issues.jboss.org/browse/ISPN-3899 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Reporter: Galder Zamarreño > Assignee: Ion Savin > Fix For: 7.1.0.Alpha1 > > > According to [~pferraro], an implementation of XAResourceRecovery needs to be added to Infinispan and plugged into XAResourceRecoveryRegistry in order to get recovery of XA transactions working as expected. > This is already done in Server/AS/Wildfly in org.jboss.as.clustering.infinispan.subsystem.CacheService class. > A similar thing should happen when Infinispan is used in embedded/library mode. > [~isavin], since you are going to work on the transaction changes in 7.0, maybe you can take this on too? It'd be interesting to add a test to start with which shows that XA transaction recovery is not working as expected as a result of not having this. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3866) Parser60.parseStore() ignores store configurations if they are not a SingleFileStore or a ClusterLoader

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3866?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3866: ----------------------------------- Fix Version/s: 7.1.0.Alpha1 (was: 7.0.0.Final) > Parser60.parseStore() ignores store configurations if they are not a SingleFileStore or a ClusterLoader > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-3866 > URL: https://issues.jboss.org/browse/ISPN-3866 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 6.0.1.Final > Reporter: Guillermo GARCIA OCHOA > Priority: Critical > Fix For: 7.1.0.Alpha1 > > > The {{Parser60.parseStore()}} methods ignores all store definition that is not a {{SingleFileStore}} or a {{ClusterLoader}} > {code:java} > private void parseStore(final XMLExtendedStreamReader reader, final ConfigurationBuilderHolder holder) throws XMLStreamException { > ConfigurationBuilder builder = holder.getCurrentConfigurationBuilder(); > CacheLoader store = null; > Boolean fetchPersistentState = null; > Boolean ignoreModifications = null; > Boolean purgeOnStartup = null; > Boolean preload = null; > Boolean shared = null; > // Here it reads the attributes that the AbstractStoreConfiguration defines > for (int i = 0; i < reader.getAttributeCount(); i++) { > ParseUtils.requireNoNamespaceAttribute(reader, i); > String value = replaceProperties(reader.getAttributeValue(i)); > Attribute attribute = Attribute.forName(reader.getAttributeLocalName(i)); > ... > } > // Then it will use the read attributes (and parse the childrens tags) > // if and only if the configure store is a SingleFileStore or ClusterLoader > if (store != null) { > if (store instanceof SingleFileStore) { > ... > parseStoreChildren(reader, sfs); > } else if (store instanceof ClusterLoader) { > ... > parseLoaderChildren(reader, cscb); > } > } > } > {code} > This means that there is no way to set a configuration to my custom cache store with the default parser {{Parser60}}. > If there is another way to what I'm asking for, please let me know because in the documentation only refers to the {{SingleFileStore}} implementation. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2014