September 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5758) HotRod client try to unmarhall an object on get() no matter whether the put() use a byte[] or not

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created ISPN-5758: -------------------------------------- Summary: HotRod client try to unmarhall an object on get() no matter whether the put() use a byte[] or not Key: ISPN-5758 URL: https://issues.jboss.org/browse/ISPN-5758 Project: Infinispan Issue Type: Bug Components: hot, Marshalling Affects Versions: 8.0.1.Final Reporter: Wolf-Dieter Fink Assignee: Galder Zamarreño Attachments: reproducer.zip If a client put an object as byte[] into the cache, which is a self serialized class, the get will return the original class (if it is in the class path) instead of the byte[]. This is incompatible to ISPN5 here the byte[] is returned in any case. It seems this in unintentional due to the smart 'compatibility' mode at client side https://github.com/infinispan/infinispan/blob/master/client/hotrod-client... The client should be able to get the same class type back -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5568) KeyAffinityService race condition on view change

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5568?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5568: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1233968|https://bugzilla.redhat.com/show_bug.cgi?id=1233968] from MODIFIED to ON_QA > KeyAffinityService race condition on view change > ------------------------------------------------ > > Key: ISPN-5568 > URL: https://issues.jboss.org/browse/ISPN-5568 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.11.Final > Reporter: Dennis Reed > Assignee: Bartosz Baranowski > Fix For: 8.0.0.Beta2, 5.2.14.Final, 7.2.4.Final > > > KeyAffinityService#getKeyForAddress runs in a tight loop looking for keys: > {noformat} > queue = address2key.get(address) > while (result == null) > result = queue.poll() > {noformat} > KeyAffinityService#handleViewChange clears and resets the queue list on membership change: > {noformat} > address2key.clear() > for each address > map.put(address, new queue) > {noformat} > If a view change comes in after getKeyForAddress gets the queue, and the queue is empty, it will get stuck in a tight loop looking at the wrong queue forever while new keys are added to the new queue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4810) Local Transactional Cache loses data when eviction is enabled and there are multiple readers and one writer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4810?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4810: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1202354|https://bugzilla.redhat.com/show_bug.cgi?id=1202354] from MODIFIED to ON_QA > Local Transactional Cache loses data when eviction is enabled and there are multiple readers and one writer > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-4810 > URL: https://issues.jboss.org/browse/ISPN-4810 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.2.Final > Environment: Windows 7 x64 (NTFS) > Oracle JDK1.7.0_40 > Apache Maven 3.0.5 > Reporter: Horia Chiorean > Assignee: William Burns > Labels: modeshape > Fix For: 7.2.0.Beta1, 5.2.12.Final, 5.2.13.Final > > Attachments: ispn_concurrent.zip > > > Using Infinispan 6.0.2 and a local, transactional cache backed by a <singleFile> store, with eviction enabled and a small {{max-entries}} setting, we have the following scenario: > * the main thread (i.e. the "writer") starts a transaction, adds a batch of strings into the cache and also appends the same strings into a List cache entry and then commits the transaction > * after the above has finished (i.e. after tx.commit) it fires a number of reader threads where each reader thread > ** checks that the string entries were added into the cache and > ** checks that the entries were correctly appended to the List entry > * the above steps are repeated a number of times > On any given run, based on timing, we're seeing that at some point (after some time) some of the reader threads will not see the latest version of the List entry (i.e. will not see the latest elements that were added into the list) but rather an old, stale List (sort of a "lost update" scenario). > If we either: > * disable eviction or > * set the {{max-entries}} to a large enough value (which I suspect has the same effect - not evicting anything) the problem doesn't show up. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3797) DataContainer should interact atomically with Persistence

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3797?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3797: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1202354|https://bugzilla.redhat.com/show_bug.cgi?id=1202354] from MODIFIED to ON_QA > DataContainer should interact atomically with Persistence > --------------------------------------------------------- > > Key: ISPN-3797 > URL: https://issues.jboss.org/browse/ISPN-3797 > Project: Infinispan > Issue Type: Enhancement > Components: Eviction, Loaders and Stores > Affects Versions: 6.0.0.Final, 5.2.10.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha3, 7.0.0.Final, 5.2.11.Final > > > DataContainer should handle atomically all the interactions with the Persistence. This includes all the eviction/passivation. > Main points: > * In DataContainer load/store will avoid any lose of data during concurrent operations > * Take advantage of CHMv8 > * CacheLoader and Writer Interceptors are no longer needed. > Check the mailling list for more info. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5526) Replication: The DELTA_WRITE flag should force a remote get during state transfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5526?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5526: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1228780|https://bugzilla.redhat.com/show_bug.cgi?id=1228780] from MODIFIED to ON_QA > Replication: The DELTA_WRITE flag should force a remote get during state transfer > --------------------------------------------------------------------------------- > > Key: ISPN-5526 > URL: https://issues.jboss.org/browse/ISPN-5526 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.10.Final > Reporter: Dennis Reed > Assignee: Ryan Emerson > Priority: Critical > Fix For: 5.2.13.Final > > > Same issue as ISPN-3184, but for repl caches in Infinispan 5.2.x. > (ISPN-3184 only fixed dist caches, since repl uses the same code in 5.3+). > AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work. > If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5756) Improve EmbeddedCacheManager.removeCache() method

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5756?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5756: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3712 > Improve EmbeddedCacheManager.removeCache() method > ------------------------------------------------- > > Key: ISPN-5756 > URL: https://issues.jboss.org/browse/ISPN-5756 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.0.1.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 8.1.0.Alpha1 > > > We have the following issues with the method > 1) It is not consistent in all the nodes > 2) Removing the cache remotely and locally can be done in parallel > 3) When passivation is enabled, it passivates the entries and then clear the cache store. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5754) Add sample with Apache Flink to infinispan-hadoop

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5754?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5754: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Add sample with Apache Flink to infinispan-hadoop > ------------------------------------------------- > > Key: ISPN-5754 > URL: https://issues.jboss.org/browse/ISPN-5754 > Project: Infinispan > Issue Type: Task > Components: Hadoop Integration > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5757) Clustered statistics for transactions

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5757: ------------------------------------- Summary: Clustered statistics for transactions Key: ISPN-5757 URL: https://issues.jboss.org/browse/ISPN-5757 Project: Infinispan Issue Type: Enhancement Components: JMX, reporting and management, Transactions Affects Versions: 8.0.1.Final Reporter: Tristan Tarrant Assignee: Vladimir Blagojevic Fix For: 8.1.0.Final We want to return clustered statistics for transactions commits, rollbacks and prepares. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5755) HotRod returns local statistics instead of clustered

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5755?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-5755: --------------------------------------- For backwards compatibility this should temporarily return both stats until 9.0 > HotRod returns local statistics instead of clustered > ---------------------------------------------------- > > Key: ISPN-5755 > URL: https://issues.jboss.org/browse/ISPN-5755 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.0.1.Final > Reporter: Tristan Tarrant > Assignee: Vladimir Blagojevic > Fix For: 8.1.0.Final > > > The HotRod statistics currently returns only the local statistics, but that is quite meaningless for a client. It should really return the clustered stats instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5756) Improve EmbeddedCacheManager.removeCache() method

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5756?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5756: ------------------------------ Status: Open (was: New) > Improve EmbeddedCacheManager.removeCache() method > ------------------------------------------------- > > Key: ISPN-5756 > URL: https://issues.jboss.org/browse/ISPN-5756 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.0.1.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 8.1.0.Alpha1 > > > We have the following issues with the method > 1) It is not consistent in all the nodes > 2) Removing the cache remotely and locally can be done in parallel > 3) When passivation is enabled, it passivates the entries and then clear the cache store. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2015