August 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5515) Purge store if there is another node already running

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5515?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5515: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Purge store if there is another node already running > ---------------------------------------------------- > > Key: ISPN-5515 > URL: https://issues.jboss.org/browse/ISPN-5515 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Loaders and Stores > Affects Versions: 7.2.2.Final, 8.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Final > > > Preloading happens before communicating with other nodes that might already have the cache running. When joining the existing members, the cache then waits to receive the first CH in which it is a member, and then deletes only the entries in the segments that it doesn't own in that CH. > The intention of this was to remove as little as possible from the existing data, e.g. if the first node to start up is not the one that was stopped last. But the preloaded entries are not replicated to the other nodes, so this can lead to inconsistencies. > It would be better to delay preloading until we know we are the first node to start up, but failing that we could clear the data container and the store before receiving the initial state. > Note that this will only allow preloading data from one node. Restoring data from more nodes is harder to do, and we will implement it as part of graceful restart. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5514) Add test to verify entries are present when utilizing an AsyncStore

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5514?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5514: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Add test to verify entries are present when utilizing an AsyncStore > ------------------------------------------------------------------- > > Key: ISPN-5514 > URL: https://issues.jboss.org/browse/ISPN-5514 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: William Burns > Fix For: 8.1.0.Final > > > The AsyncStore can keep entries in memory where they don't exist in the data container or the underlying store. We should verify the various methods of the CacheLoader/AdvancedCacheLoader all work properly when utilizing an AsyncStore. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5513) State Transfer can miss entries that are concurrently activated

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5513?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5513: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > State Transfer can miss entries that are concurrently activated > --------------------------------------------------------------- > > Key: ISPN-5513 > URL: https://issues.jboss.org/browse/ISPN-5513 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 8.0.0.Alpha1 > Reporter: William Burns > Fix For: 8.1.0.Final > > > Currently the OutboundTransferTask iterates upon the data container and then runs process for the state loader. However if an entry is activated during or after the data container iteration it is possible this entry is then not seen and subsequently is not present in the store when it is processed. > EntryRetriever had this same issue and it was required to register a cache listener to listen for activations and then replay the data after finishing with the store. > This can cause duplicate values as well, however replacing the same exact value is fine and if a non ST write occurs the state is ignored anyways. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5510) Provide better Hot Rod client socket timeout and retry defaults

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5510?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5510: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Provide better Hot Rod client socket timeout and retry defaults > --------------------------------------------------------------- > > Key: ISPN-5510 > URL: https://issues.jboss.org/browse/ISPN-5510 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.1.0.Final > > > The current defaults are: > * Socket timeout = 60 seconds > * Max retries = 10 > As a result of these defaults, if the server hangs an operation, it'd take 10 minutes (60 second timeout x 10 retries) for the operation to finally return an exception to the client, which is way too much. > So, these default value should change to be more aggressive: 30 second socket timeout and 3 max retries. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5636) Test server modules against WildFly 10 Alpha

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5636?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5636: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Test server modules against WildFly 10 Alpha > -------------------------------------------- > > Key: ISPN-5636 > URL: https://issues.jboss.org/browse/ISPN-5636 > Project: Infinispan > Issue Type: Component Upgrade > Components: WildFly modules > Affects Versions: 8.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5628) Add documentation for Distributed Streams

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5628?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5628: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Add documentation for Distributed Streams > ----------------------------------------- > > Key: ISPN-5628 > URL: https://issues.jboss.org/browse/ISPN-5628 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Reporter: William Burns > Assignee: William Burns > Fix For: 8.1.0.Final > > > ISPN-5293 added in distributed streams. We need to document this both in the Developer Guide. > We should also document deprecation of Entry retriever and point to distributed streams in upgrade guide. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5623) Retried prepare commands do not wait for backup locks

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5623?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5623: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Retried prepare commands do not wait for backup locks > ----------------------------------------------------- > > Key: ISPN-5623 > URL: https://issues.jboss.org/browse/ISPN-5623 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final, 8.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 8.1.0.Final > > Attachments: OptimisticPrimaryOwnerCrashDuringPrepareTest.java > > > When the primary owner crashes during prepare, the prepare command is retried on the new primary owner. But because the transaction topology id stays the same, the new primary owner does not check for backup locks owned by other transactions from the previous topology. > That makes it possible for the retried prepare command to lock a key that was already locked by another transaction on the primary owner. > This wasn't a problem before the ISPN-4546 fix, because a primary owner crash would have forced the transaction to roll back. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5629) AvgAccumulator should handle NaN and other non-numbers

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5629?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5629: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > AvgAccumulator should handle NaN and other non-numbers > ------------------------------------------------------ > > Key: ISPN-5629 > URL: https://issues.jboss.org/browse/ISPN-5629 > Project: Infinispan > Issue Type: Bug > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.1.0.Final > > > The handling should be similar to java.util.DoubleSummaryStatistics -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5615) Transfer sections from the Hibernate Search reference documentation about the Lucene Directory Provider

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5615?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5615: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Transfer sections from the Hibernate Search reference documentation about the Lucene Directory Provider > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-5615 > URL: https://issues.jboss.org/browse/ISPN-5615 > Project: Infinispan > Issue Type: Task > Components: Documentation-Query > Reporter: Sanne Grinovero > Fix For: 8.1.0.Final > > > The general introduction to Infinispan should stay in the Hibernate Search documentation > - http://docs.jboss.org/hibernate/search/5.3/reference/en-US/html_single/#i... > But configuration options and tuning recommendations whould be transferred to the Infinispan reference documentation as the exact properties and their effect would depend on the Infinispan version being used (most of section 3.3.1.3. Infinispan Configuration) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5617) Clearly define which cachestores are shared and which are non-shared

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5617?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5617: ------------------------------ Fix Version/s: 8.1.0.Final (was: 8.0.0.Final) > Clearly define which cachestores are shared and which are non-shared > -------------------------------------------------------------------- > > Key: ISPN-5617 > URL: https://issues.jboss.org/browse/ISPN-5617 > Project: Infinispan > Issue Type: Task > Reporter: Tristan Tarrant > Fix For: 8.1.0.Final > > > Cache stores should explicitly declare if they work in shared or non-shared mode, so that unsupported configurations cannot be started. > See http://lists.jboss.org/pipermail/infinispan-dev/2015-July/016076.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2015