March 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7616) Add support to partial re-index in the MassIndexer

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7616?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7616: ------------------------------------ Summary: Add support to partial re-index in the MassIndexer (was: Please add method like MassIndexer.reindex(Object... keys)) > Add support to partial re-index in the MassIndexer > -------------------------------------------------- > > Key: ISPN-7616 > URL: https://issues.jboss.org/browse/ISPN-7616 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Seto Kaiba > > Currently I can re-index by put the entry again. But it will make it replicated again in distributed cache with backups. It is necessary to provide a method to re-index the entry. > Maybe like this: > MassIndexer.reindex(Object key...) > It would be useful for relational model to re-index the parent while change the child when the parent refers to the child by key. In this situation, the parent is not modified at all. So a re-index is needed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7621) as-lucene-directory integration tests need to cleanup the testing database

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7621?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7621: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > as-lucene-directory integration tests need to cleanup the testing database > -------------------------------------------------------------------------- > > Key: ISPN-7621 > URL: https://issues.jboss.org/browse/ISPN-7621 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Query > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 9.0.0.Final, 8.2.7.Final > > > The WildFly configuration used by the {{as-lucene-directory}} integration tests uses a DataSource connection to the H2 testing database which is configured for on-disk persistence in the ~ home path. > This makes subsequent runs of the testsuite fail as there's unexpected data in the database already. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7618) Bounded Off Heap can crash when a single entry size is larger than total size

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7618?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7618: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Final Resolution: Done > Bounded Off Heap can crash when a single entry size is larger than total size > ----------------------------------------------------------------------------- > > Key: ISPN-7618 > URL: https://issues.jboss.org/browse/ISPN-7618 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 9.0.0.Final > > > When looking into https://developer.jboss.org/thread/274297 we noticed sometimes that an indexed cache would cause OFF_HEAP to SEGFAULT. This wasn't identified in current stress tests. Need to confirm the cause. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7625) Make sure to report NoClassDefFoundError rather than hiding them as a ClassNotFoundException

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7625?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7625: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Make sure to report NoClassDefFoundError rather than hiding them as a ClassNotFoundException > -------------------------------------------------------------------------------------------- > > Key: ISPN-7625 > URL: https://issues.jboss.org/browse/ISPN-7625 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 9.0.0.Final, 8.2.7.Final > > > I was having a {{NoClassDefFoundError}} caused by a module misconfiguration, but it turned out very complex to figure out as the only exception reported by Infinispan was about a misleading {{ClassNotFoundException}}. > I'm fixing the common classloading utility to make sure to log the errors appropriately. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7629) Administration console - fatal events have no icon in the right column latest events section

by Roman Macor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7629?page=com.atlassian.jira.plugin.... ] Roman Macor updated ISPN-7629: ------------------------------ Summary: Administration console - fatal events have no icon in the right column latest events section (was: Administration console - fatal events have no icon in the right column latest evetns section) > Administration console - fatal events have no icon in the right column latest events section > -------------------------------------------------------------------------------------------- > > Key: ISPN-7629 > URL: https://issues.jboss.org/browse/ISPN-7629 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Ryan Emerson > Priority: Minor > > Fatal events such as "Lost data" event have no icon displayed in "Latest Grid Events" column on the right. > Note: > Status Events tab displays them correctly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7629) Administration console - fatal events have no icon in the right column latest evetns section

by Roman Macor (JIRA)

Roman Macor created ISPN-7629: --------------------------------- Summary: Administration console - fatal events have no icon in the right column latest evetns section Key: ISPN-7629 URL: https://issues.jboss.org/browse/ISPN-7629 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 9.0.0.CR2 Reporter: Roman Macor Assignee: Ryan Emerson Priority: Minor Fatal events such as "Lost data" event have no icon displayed in "Latest Grid Events" column on the right. Note: Status Events tab displays them correctly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7614) Disabling a store doesn't stop it

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7614?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7614: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/4985 (was: https://github.com/infinispan/infinispan/pull/4972) > Disabling a store doesn't stop it > --------------------------------- > > Key: ISPN-7614 > URL: https://issues.jboss.org/browse/ISPN-7614 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Final > > > When disabling a store via {{PersistenceManager.disableStore(...)}}, the store is removed from the list of loaders/writers, but its {{stop()}} method is not called, so buffers may not be flushed. > {{AsyncCacheWriter}} will also leak the {{AsyncStoreCoordinator}} thread if {{stop()}} is not called, and this thread leak is visible when running {{ClassLoaderManagerDisablingTest}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7628) Administration console - the cluster status doesn't reflect "reload-required" state of its nodes

by Roman Macor (JIRA)

Roman Macor created ISPN-7628: --------------------------------- Summary: Administration console - the cluster status doesn't reflect "reload-required" state of its nodes Key: ISPN-7628 URL: https://issues.jboss.org/browse/ISPN-7628 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 9.0.0.CR2 Reporter: Roman Macor The cluster has "Started" status even though all of its nodes have "reload-required" status. Expected result: The cluster status should also be "reload-required" Another suggestion: "Reload" action should be available from the cluster so that the user doesn't need to perform this action on individual nodes (there could be hundreds of them ) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7622) Hot Rod Rolling Upgrade throws TimeOutException

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7622?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7622: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Final Assignee: Gustavo Fernandes Resolution: Done > Hot Rod Rolling Upgrade throws TimeOutException > ----------------------------------------------- > > Key: ISPN-7622 > URL: https://issues.jboss.org/browse/ISPN-7622 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Final > > > When calling the {{synchonizeData}} operation, it timeouts after some minutes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7586) Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7586?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7586: ------------------------------------ Description: We recommend to do rolling upgrades with the target cluster with a remote-store pointing to the source cluster, in mode ready-only. Clients are switched to point to the target cluster. This cause situations like this in the client: {code:java} client.put("K","value") // will get "V" back client.get("K") // Deletes will not propagate to the source cluster, // the RemoteStore is in 'read-only' mode. client.remove("K") // Returns "V". Although deleted, value will be retrieved // from the remote store cache.get("K") {code} This can break existing applications that expect a consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in read only mode, but at the same time, as the Rolling Upgrade does a put in the target cache reading data from the source cache, it should not trigger a write back to the source cluster. was: We recommend to do rolling upgrades with the target cluster with a remote-store pointing to the source cluster, in mode ready-only. Clients are switched to point to the target cluster. This cause situations like this in the client: {code:java} client.put("K","value") // will get "V" back client.get("K") // Deletes will not propagate to the source cluster, // the RemoteStore is in 'read-only' mode. client.remove("K") // Returns "V". Although deleted, value will be retrieved // from the remote store cache.get("K") {code} This can break existing applications that expect a consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in non-read only mode for clients, but at the same time, as the Rolling Upgrade does a put in the target cache reading data from the source cache, it should not trigger a write back to the source cluster. > Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies > ---------------------------------------------------------------------------------- > > Key: ISPN-7586 > URL: https://issues.jboss.org/browse/ISPN-7586 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > We recommend to do rolling upgrades with the target cluster with a remote-store pointing to the source cluster, in mode ready-only. Clients are switched to point to the target cluster. > This cause situations like this in the client: > {code:java} > client.put("K","value") > // will get "V" back > client.get("K") > // Deletes will not propagate to the source cluster, > // the RemoteStore is in 'read-only' mode. > client.remove("K") > // Returns "V". Although deleted, value will be retrieved > // from the remote store > cache.get("K") > > {code} > This can break existing applications that expect a consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in read only mode, but at the same time, as the Rolling Upgrade does a put in the target cache reading data from the source cache, it should not trigger a write back to the source cluster. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2017