November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4895) Rolling upgrade source migrators should use the distributed iterator to collect keys

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4895?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4895: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Rolling upgrade source migrators should use the distributed iterator to collect keys > ------------------------------------------------------------------------------------ > > Key: ISPN-4895 > URL: https://issues.jboss.org/browse/ISPN-4895 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 7.0.0.CR2 > Reporter: Tristan Tarrant > Assignee: William Burns > Fix For: 7.1.0.Beta1 > > > currently the rolling upgrade migrators iterate all entries in the cache using org.infinispan.tasks.GlobalKeySetTask<K, V> and invoking cache.keySet(). This needs to be done more efficiently using the distributed iterators -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4935) Quickstarts: Remote query not working

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4935?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4935: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Quickstarts: Remote query not working > ------------------------------------- > > Key: ISPN-4935 > URL: https://issues.jboss.org/browse/ISPN-4935 > Project: Infinispan > Issue Type: Bug > Components: Demos and Tutorials > Affects Versions: 7.0.0.CR2 > Reporter: Jiří Holuša > Assignee: Adrian Nistor > Fix For: 7.1.0.Beta1 > > > When testing remote query quickstarts I found out it's not working anymore. > After setting up the server (as wrote in README file), building it (mvn clean package) and running it (mvn exec:java) I get following exception: > Caused by: java.lang.NoSuchMethodException: org.infinispan.query.remote.ProtobufMetadataManager.registerProtofile([B) > at java.lang.Class.getMethod(Class.java:1665) > at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:268) > I think this is related to https://issues.jboss.org/browse/ISPN-3480 -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4924) CacheEntryEvent isOriginLocal is not correct in many circumstances

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4924?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4924: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > CacheEntryEvent isOriginLocal is not correct in many circumstances > ------------------------------------------------------------------ > > Key: ISPN-4924 > URL: https://issues.jboss.org/browse/ISPN-4924 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.CR2 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.1.0.Beta1 > > > Origin local flag was messed up when nontx DIST was rewritten to have the primary owner send updates to the backup nodes. This in turn affected REPL when it was changed to be implemented on top of DIST. I believe that tx is unaffected. Also new cluster listeners don't put the flag properly for DIST caches if the originator is not also the primary owner. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5021: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Nodes that finish the rebalance later can see outdated values > ------------------------------------------------------------- > > Key: ISPN-5021 > URL: https://issues.jboss.org/browse/ISPN-5021 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 7.1.0.Beta1 > > > Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...] > If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help. > I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance: start a rebalance with read_ch=old, write_ch=old+new, when the new owners have all the data install read_ch=new, write_ch=old+new, and finally read_ch=new, write_ch=new. Old cache entries are removed during the 2nd topology update, and further writes should be ignored, in order for this to work. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5019: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > After coordinator change, cache topologies should be installed in parallel > -------------------------------------------------------------------------- > > Key: ISPN-5019 > URL: https://issues.jboss.org/browse/ISPN-5019 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Beta1 > > > When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches. > We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5010) Improve remote listener performance

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5010?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5010: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Improve remote listener performance > ----------------------------------- > > Key: ISPN-5010 > URL: https://issues.jboss.org/browse/ISPN-5010 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 7.0.2.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > We've run some performance tests and we've noticed remote listeners have a too negative effect on get/put/remove operations, particularly as number of listeners added by clients increase. This JIRA encompasses different pieces of work to improve this: > * Make server-side clustered listener async. By doing so, the operations are detached from the actual server-side listener part when the notification is sent to clients. Async listener executor is configured with 1 thread, so order is still maintained. > * Batching at the server-side clustered listener side. Instead of sending each event as it comes, apply time/size based batching to reduce number of system calls to flush sockets to clients. > * Further improvements might come from bundling listeners added by same client, but this is more complicated to achieve, since only those listeners that have similar characteristics can be bundled, e.g. have same filter/converter settings. Also, whether to use a single connection for all listeners or maintain separate ones still would need to be decided. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5029) Infinispan 7.0.2 not fully backwards compatible with 6.0.x

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5029?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5029: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Infinispan 7.0.2 not fully backwards compatible with 6.0.x > ---------------------------------------------------------- > > Key: ISPN-5029 > URL: https://issues.jboss.org/browse/ISPN-5029 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.0.2.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 7.1.0.Beta1, 7.1.0.Final, 7.0.3.Final > > > Using Hibernate 4.3.x with Infinispan 7 throws: > {code} > Caused by: java.lang.IncompatibleClassChangeError: Found class org.infinispan.commons.util.FileLookup, but interface was expected > at org.hibernate.cache.infinispan.InfinispanRegionFactory.createCacheManager(InfinispanRegionFactory.java:406) > at org.hibernate.cache.infinispan.InfinispanRegionFactory.start(InfinispanRegionFactory.java:323) > ... 141 more > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4927) Bulk Ops in HotRod should use new implementations of keySet and entrySet

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4927?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4927: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1159559|https://bugzilla.redhat.com/show_bug.cgi?id=1159559] from ON_QA to VERIFIED > Bulk Ops in HotRod should use new implementations of keySet and entrySet > ------------------------------------------------------------------------ > > Key: ISPN-4927 > URL: https://issues.jboss.org/browse/ISPN-4927 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 7.0.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4949) Split brain: inconsistent data after merge

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4949: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.1.0.Alpha1 Resolution: Done > Split brain: inconsistent data after merge > ------------------------------------------ > > Key: ISPN-4949 > URL: https://issues.jboss.org/browse/ISPN-4949 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 7.0.0.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Alpha1 > > > 1) cluster A, B, C, D splits into 2 parts: > A, B (coord A) finds this out immediately and enters degraded mode with CH [A, B, C, D] > C, D (coord D) first detects that B is lost, gets view A, C, D and starts rebalance with CH [A, C, D]. Segment X is primary owned by C (it had backup on B but this got lost) > 2) D detects that A was lost as well, therefore enters degraded mode with CH [A, C, D] > 3) C inserts entry into X: all owners (only C) is present, therefore the modification is allowed > 4) cluster is merged and coordinator finds out that the max stable topology has CH [A, B, C, D] (it is the older of the two partitions' topologies, got from A, B) - logs 'No active or unavailable partitions, so all the partitions must be in degraded mode' (yes, all partitions are in degraded mode, but write has happened in the meantime) > 5) The old CH is broadcast in newest topology, no rebalance happens > 6) Inconsistency: read in X may miss the update -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4979) CacheStatusResponse map uses too much memory

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4979?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4979: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.1.0.Alpha1 Resolution: Done > CacheStatusResponse map uses too much memory > -------------------------------------------- > > Key: ISPN-4979 > URL: https://issues.jboss.org/browse/ISPN-4979 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Final > Reporter: Dan Berindei > Assignee: William Burns > Priority: Critical > Fix For: 7.1.0.Alpha1, 7.1.0.Final > > > When the cluster is large and there are a log of caches, the {{CacheStatusResponse}} map on the new coordinator can get quite large. One of the problems that seems to be that the addresses in {{DefaultConsistentHash}} are duplicated on serialization, so the deserialized version occupies more memory. > We need to investigate why the objects are not "shared" by the River marshaller, and maybe work around the problem by de-duplicating the addresses in the externalizer. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2014