November 2014 - infinispan-issues

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3790?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3790: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > 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.Beta1 > > > {{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.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3769) Disallow async marshalling when the replication queue is enabled

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3769?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3769: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Disallow async marshalling when the replication queue is enabled > ---------------------------------------------------------------- > > Key: ISPN-3769 > URL: https://issues.jboss.org/browse/ISPN-3769 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Mircea Markus > Fix For: 7.1.0.Beta1 > > > The rationale is similar to ISPN-2939, the async marshalling option can cause inconsistencies because it can reorder commands. > But the case is stronger when the replication queue is in use, because the {{RpcManager.invokeRemotely()}} call already happens on a the replication queue's background thread. The user thread is already free to do its thing, so there isn't any reason to do the RPC on yet another background thread. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

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 Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3854?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3854: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > 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.Beta1 > > 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.8#6338)

10 years, 1 month

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3843?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3843: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > 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.Beta1 > > > 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.8#6338)

10 years, 1 month

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3835?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3835: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > 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.Beta1 > > > 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.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3906) Do not place ProtobufValueWrapper instances in the cache

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3906?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3906: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Do not place ProtobufValueWrapper instances in the cache > -------------------------------------------------------- > > Key: ISPN-3906 > URL: https://issues.jboss.org/browse/ISPN-3906 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.1.0.Beta1 > > > ProtobufValueWrapper is only needed in order to provide a classbridge so we can integrate with Hibernate Search. Still, we should not need to wrap the protobuf encoded byte array put in the cache with this class. It should only be created as a temporary wrapper just before we feed the data to Hibernate Search. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3905) Murmurhash3 implementation is slow on String keys

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3905?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3905: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Murmurhash3 implementation is slow on String keys > ------------------------------------------------- > > Key: ISPN-3905 > URL: https://issues.jboss.org/browse/ISPN-3905 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.0.Final, 6.0.1.Final > Reporter: Sanne Grinovero > Assignee: Mircea Markus > Priority: Minor > Fix For: 7.1.0.Beta1 > > > String instances are a common choice for being used as key entries, still the getBytes() operation being performed allocates costly buffers, and the computation to get those bytes looks like expensive too. > I suspect there might be good reasons for not using the String's own hashcode directly as an input to Murmurhash? Still that's what other implementations seem to do. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3899?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3899: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > 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.Beta1 > > > 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.8#6338)

10 years, 1 month

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3866?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3866: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > 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.Beta1 > > > 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.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3928) The ClusterRegistry API needs extending to allow put of mortal entries

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3928?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3928: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > The ClusterRegistry API needs extending to allow put of mortal entries > ---------------------------------------------------------------------- > > Key: ISPN-3928 > URL: https://issues.jboss.org/browse/ISPN-3928 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Tristan Tarrant > Fix For: 7.1.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2014