May 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4180) Configuration parsing incorrectly logs that the cache name is ignored

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4180?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4180: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Configuration parsing incorrectly logs that the cache name is ignored > --------------------------------------------------------------------- > > Key: ISPN-4180 > URL: https://issues.jboss.org/browse/ISPN-4180 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Reporter: Jakub Markos > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 7.0.0.Beta1 > > > Here: > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... > If you configure a cache name, you get: > {code} > INFO [org.infinispan.configuration.parsing.Parser70] (ServerService Thread Pool -- 15) ISPN000293: Ignoring XML attribute NAME, please remove from configuration file > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4036) StateConsumerImpl.isKeyUpdated searches for the key in the values collection

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4036?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-4036. -------------------------------- Resolution: Out of Date The method wasn't used, and it was removed completely with the x-site state transfer changes. > StateConsumerImpl.isKeyUpdated searches for the key in the values collection > ---------------------------------------------------------------------------- > > Key: ISPN-4036 > URL: https://issues.jboss.org/browse/ISPN-4036 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Beta1 > > > Introduced by the ISPN-3443 fix. I changed the {{updatedKeys}} HashSet to be an EquivalendConcurrentHashMap, but I forgot to change the {{contains(key)}} call to {{containsKey(key)}}. Since we use the same value for all the keys, it means state transfer might skip more keys than it should have. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4310) StateResponse chunk with lastChunk=true from cancelled ST stops receiving data in next ST

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4310?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4310: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2584 Keep track of the topology id when state transfer was initiated, and reject state response commands with older topology id. We can't use the exact topology id, because a node (other than the coordinator) leaving could increment the topology id without restarting the state transfer. Note that the state transfer topology id is not necessarily the same as the topology id of the {{REBALANCE_START}} command. If a node leaves, causing a {{CH_UPDATE(rebalanceTopologyId + 1)}} command to be sent, other nodes may receive the {{CH_UPDATE}} first and start the state transfer with the higher topology id. > StateResponse chunk with lastChunk=true from cancelled ST stops receiving data in next ST > ----------------------------------------------------------------------------------------- > > Key: ISPN-4310 > URL: https://issues.jboss.org/browse/ISPN-4310 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > > 1. A requests segment from B (there are multiple chunks) > 2. B sends all chunks, but before A receives them, new topology arrives and A cancels the ST. > 3. Another topology comes and A requests this segment again > 4. A receives the old StateResponseCommand with lastChunk=true and thinks that it got all segments, therefore, it discards further chunks. > Result is inconsistent cluster, and after further rebalances completely lost data. > This ought to be rare, but was repeatedly observed when gracefully stopping coordinator on a 32-node cluster full of data. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4036) StateConsumerImpl.isKeyUpdated searches for the key in the values collection

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4036?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4036: ------------------------------- Status: Open (was: Pull Request Sent) > StateConsumerImpl.isKeyUpdated searches for the key in the values collection > ---------------------------------------------------------------------------- > > Key: ISPN-4036 > URL: https://issues.jboss.org/browse/ISPN-4036 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Beta1 > > > Introduced by the ISPN-3443 fix. I changed the {{updatedKeys}} HashSet to be an EquivalendConcurrentHashMap, but I forgot to change the {{contains(key)}} call to {{containsKey(key)}}. Since we use the same value for all the keys, it means state transfer might skip more keys than it should have. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4327) Upgrade to Apache Lucene 4.8.1

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-4327?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-4327: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2583 > Upgrade to Apache Lucene 4.8.1 > ------------------------------ > > Key: ISPN-4327 > URL: https://issues.jboss.org/browse/ISPN-4327 > Project: Infinispan > Issue Type: Component Upgrade > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.Alpha5 > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4327) Upgrade to Apache Lucene 4.8.1

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-4327: ------------------------------------- Summary: Upgrade to Apache Lucene 4.8.1 Key: ISPN-4327 URL: https://issues.jboss.org/browse/ISPN-4327 Project: Infinispan Issue Type: Component Upgrade Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 7.0.0.Alpha5 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4326) Change EntryIterator return type to be CacheEntry

by William Burns (JIRA)

William Burns created ISPN-4326: ----------------------------------- Summary: Change EntryIterator return type to be CacheEntry Key: ISPN-4326 URL: https://issues.jboss.org/browse/ISPN-4326 Project: Infinispan Issue Type: Enhancement Components: Core Reporter: William Burns Assignee: William Burns Fix For: 7.0.0.Alpha5 Currently the entry retriever pieces return a Map.Entry. However end users may need the metadata along with that. We need to change this to return CacheEntry instead so the Metadata is available. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4326) Change EntryIterator return type to be CacheEntry

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4326?page=com.atlassian.jira.plugin.... ] Work on ISPN-4326 started by William Burns. > Change EntryIterator return type to be CacheEntry > ------------------------------------------------- > > Key: ISPN-4326 > URL: https://issues.jboss.org/browse/ISPN-4326 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha5 > > > Currently the entry retriever pieces return a Map.Entry. However end users may need the metadata along with that. We need to change this to return CacheEntry instead so the Metadata is available. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4295) Include Lucene Directory in the released WildFly modules

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4295?page=com.atlassian.jira.plugin.... ] Work on ISPN-4295 stopped by Gustavo Fernandes. > Include Lucene Directory in the released WildFly modules > -------------------------------------------------------- > > Key: ISPN-4295 > URL: https://issues.jboss.org/browse/ISPN-4295 > Project: Infinispan > Issue Type: Feature Request > Components: Build process, Lucene Directory > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta1 > > > The Lucene Directory module for WildFly should be included in the other released WildFly modules, and also we need integration tests for it. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4295) Include Lucene Directory in the released WildFly modules

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4295?page=com.atlassian.jira.plugin.... ] Work on ISPN-4295 started by Gustavo Fernandes. > Include Lucene Directory in the released WildFly modules > -------------------------------------------------------- > > Key: ISPN-4295 > URL: https://issues.jboss.org/browse/ISPN-4295 > Project: Infinispan > Issue Type: Feature Request > Components: Build process, Lucene Directory > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta1 > > > The Lucene Directory module for WildFly should be included in the other released WildFly modules, and also we need integration tests for it. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

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 May 2014