March 2017 - infinispan-issues - Jboss List Archives

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

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-7625?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-7625: ---------------------------------- Status: Open (was: New) > 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)

9 years

1
0
0 / 0

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

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-7625?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-7625: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4981 > 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)

9 years

1
0
0 / 0

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

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-7621?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-7621: ---------------------------------- Fix Version/s: 8.2.7.Final > 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)

9 years

1
0
0 / 0

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

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-7621?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-7621: ---------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/4976, https://github.com/infinispan/infinispan/pull/4981 (was: https://github.com/infinispan/infinispan/pull/4976) > 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)

9 years

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7618?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7618: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4980 > 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 > > 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)

9 years

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7618?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7618: -------------------------------- Summary: Bounded Off Heap can crash when a single entry size is larger than total size (was: Bounded Off Heap pointers are messed up when a single entry size is larger than total size) > 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 > > 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)

9 years

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7618?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7618: -------------------------------- Status: Open (was: New) > 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 > > 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)

9 years

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 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. 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 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 > > 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. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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 non-read only mode for clients, but at the same time, as the Rolling Upgrade does a put in the target cache from the source cache, it should not trigger a write back to the source cluster. was: We recommend to run the target cluster with a remote-store in mode ready-only during Rolling Upgrades, and point clients from the old cluster to the new one. Clients can see the following situation: {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 transparent and consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in non-read only mode for clients iteration but at the same time it should not allow the Rolling Upgrade itself to cause writes back to the remote store. > 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 > > 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 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)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7626) eventType is null when CacheEventConverter.convert() is called

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-7626?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-7626: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://issues.jboss.org/browse/ISPN-7626 please review > eventType is null when CacheEventConverter.convert() is called > --------------------------------------------------------------- > > Key: ISPN-7626 > URL: https://issues.jboss.org/browse/ISPN-7626 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.0.0.CR3 > Reporter: Vittorio Rigamonti > Assignee: Vittorio Rigamonti > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2017