April 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5352) Improve scalability of DSL based filters by using the publish/subscribe feature of org.infinispan.objectfilter.Matcher

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5352?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5352: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3351 > Improve scalability of DSL based filters by using the publish/subscribe feature of org.infinispan.objectfilter.Matcher > ----------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5352 > URL: https://issues.jboss.org/browse/ISPN-5352 > Project: Infinispan > Issue Type: Bug > Components: Listeners > Affects Versions: 7.2.0.Beta2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.CR1, 7.2.0.Final > > > org.infinispan.objectfilter.Matcher is able to index multiple filters and use a publish/subscribe model that is more efficient than using the org.infinispan.objectfilter.ObjectFilter which would execute each filter serially. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5350) Use DSL based filters with Hot Rod event listeners

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5350?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5350: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3351 > Use DSL based filters with Hot Rod event listeners > -------------------------------------------------- > > Key: ISPN-5350 > URL: https://issues.jboss.org/browse/ISPN-5350 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 7.2.0.Beta2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.CR1, 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5159) Make concurrent startup smooth

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5159?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-5159: ----------------------------------- [~dan.berindei] setting up JGroups in such a way that it will block until all nodes can see each other etc. is one way to solve it, but I don't think that it's very convenient to users (ideally they should not need to touch JGroups configuration at all, IMO). My suggestion was to allow cache merges for certain caches: the contents of certain internal caches can be merged/reinitialized again, and empty application caches can be merged trivially. > Make concurrent startup smooth > ------------------------------ > > Key: ISPN-5159 > URL: https://issues.jboss.org/browse/ISPN-5159 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.1.0.Beta1 > Reporter: Radim Vansa > Assignee: Dan Berindei > > When starting many instances in parallel, it often happens that the node does not detect its neighborhood very well and this results in many subclusters, merging views etc. > Merging two available partitions has undefined results (AFAIK). While we can expect that there are no requests to the cluster from the application ^1^, Infinispan itself uses some caches to store internal information (HotRod routing, Protobuf etc...). It would be better if the available-available merge would provide hooks for rebuilding this info. > ^1^) Being able to start the cluster with reads/writes disabled and enable them only when the cache has expected number of members would be convenient, too. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5350) Use DSL based filters with Hot Rod event listeners

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5350?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5350: -------------------------------- Issue Type: Enhancement (was: Bug) Fix Version/s: 7.2.0.CR1 7.2.0.Final Affects Version/s: 7.2.0.Beta2 Component/s: Remote Protocols > Use DSL based filters with Hot Rod event listeners > -------------------------------------------------- > > Key: ISPN-5350 > URL: https://issues.jboss.org/browse/ISPN-5350 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 7.2.0.Beta2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.CR1, 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5351) read()ing protected Attributes should support user-supplied copying methods

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5351: ------------------------------------- Summary: read()ing protected Attributes should support user-supplied copying methods Key: ISPN-5351 URL: https://issues.jboss.org/browse/ISPN-5351 Project: Infinispan Issue Type: Bug Reporter: Tristan Tarrant Cloning a configuration attribute sometimes is not enough. For example when dealing with collections and immutable types we need to overcome the following: Caused by: java.lang.UnsupportedOperationException at org.infinispan.commons.util.Immutables$ImmutableTypedProperties.put(Immutables.java:622) at org.infinispan.configuration.cache.IndexingConfigurationBuilder.setProperty(IndexingConfigurationBuilder.java:130) at org.infinispan.configuration.cache.IndexingConfigurationBuilder.addProperty(IndexingConfigurationBuilder.java:107) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5350) Use DSL based filters with Hot Rod event listeners

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-5350: ----------------------------------- Summary: Use DSL based filters with Hot Rod event listeners Key: ISPN-5350 URL: https://issues.jboss.org/browse/ISPN-5350 Project: Infinispan Issue Type: Bug Reporter: Adrian Nistor -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5350) Use DSL based filters with Hot Rod event listeners

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5350?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned ISPN-5350: ----------------------------------- Assignee: Adrian Nistor > Use DSL based filters with Hot Rod event listeners > -------------------------------------------------- > > Key: ISPN-5350 > URL: https://issues.jboss.org/browse/ISPN-5350 > Project: Infinispan > Issue Type: Bug > Reporter: Adrian Nistor > Assignee: Adrian Nistor > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5350) Use DSL based filters with Hot Rod event listeners

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5350?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5350: -------------------------------- Status: Open (was: New) > Use DSL based filters with Hot Rod event listeners > -------------------------------------------------- > > Key: ISPN-5350 > URL: https://issues.jboss.org/browse/ISPN-5350 > Project: Infinispan > Issue Type: Bug > Reporter: Adrian Nistor > Assignee: Adrian Nistor > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5274) Inconsistent data after transaction rollback (with success on originator)

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5274?page=com.atlassian.jira.plugin.... ] Work on ISPN-5274 started by Dan Berindei. ------------------------------------------ > Inconsistent data after transaction rollback (with success on originator) > ------------------------------------------------------------------------- > > Key: ISPN-5274 > URL: https://issues.jboss.org/browse/ISPN-5274 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Matej Čimbora > Assignee: Dan Berindei > > Scenario > Nodes edg-perf[10-13], partition handling on > 1.Transaction is started on edg-perf10 > {code} > 10:24:48,228 TRACE [org.infinispan.transaction.xa.TransactionXaAdapter] (DefaultStressor-6) start called on tx GlobalTransaction:<edg-perf10-20667>:38910:local > {code} > 2. Value of key_000000000000065B is updated within the transaction > {code} > 10:24:48,405 TRACE [org.radargun.service.InfinispanOperations$Cache] (DefaultStressor-6) PUT cache=testCache key=key_000000000000065B value=[6 #15: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, 3147, ] > {code} > 3. Transaction is successfully prepared on edg-perf11 & edg-perf12 > {code} > 10:24:48,559 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-6) Responses: [sender=edg-perf11-61837, received=true, suspected=false] > [sender=edg-perf12-7305, received=true, suspected=false] > {code} > 4. Transaction commit is issued > {code} > 10:24:48,562 TRACE [org.infinispan.transaction.TransactionCoordinator] (DefaultStressor-6) Committing transaction GlobalTransaction:<edg-perf10-20667>:38910:local > {code} > 5. Other participating nodes (edg-perf11 & edg-perf12) are suspected... > {code} > 10:24:52,705 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (DefaultStressor-6) Target node edg-perf11-61837 left during remote call, ignoring > 10:24:52,716 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (DefaultStressor-6) Target node edg-perf12-7305 left during remote call, ignoring > {code} > ... as they received a new view (without edg-perf10) meanwhile. > {code} > 10:24:48,547 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,edg-perf12-7305) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf12-7305|20] (3) [edg-perf12-7305, edg-perf11-61837, edg-perf13-25187], 2 subgroups: [edg-perf13-25187|8] (1) [edg-perf13-25187], [edg-perf13-25187|19] (1) [edg-perf13-25187] > {code} > Still, the transaction is commited on edg-perf10 & updated entry is stored locally > {code} > 10:24:52,894 TRACE [org.infinispan.statetransfer.CommitManager] (DefaultStressor-6) Trying to commit. Key=key_000000000000065B. Operation Flag=null, L1 invalidation=false > 10:24:52,896 TRACE [org.infinispan.statetransfer.CommitManager] (DefaultStressor-6) Committing key=key_000000000000065B. It is a L1 invalidation or a normal put and no tracking is enabled! > 10:24:52,908 TRACE [org.infinispan.container.DefaultDataContainer] (DefaultStressor-6) Creating new ICE for writing. Existing=ImmortalCacheEntry{key=key_000000000000065B, value=[6 #14: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, ]}, metadata=EmbeddedMetadata{version=null}, new value=[6 #15: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, 3147, ] > {code} > 6. Other nodes rollback the transaction > {code} > 10:24:50,376 DEBUG [org.infinispan.transaction.TransactionTable] (transport-thread-10) Rolling back transaction GlobalTransaction:<edg-perf10-20667>:38910:remote because originator edg-perf10-20667 left the cluster > {code} > 7. edg-perf10 receives a new view, containing nodes edg-perf[10,11,13]. Incoming state transfer overwrites the updated value > {code} > 10:25:09,614 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,edg-perf10-20667) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf10-20667|22] (3) [edg-perf10-20667, edg-perf11-61837, edg-perf13-25187], 4 subgroups: [edg-perf10-20667|15] (2) [edg-perf10-20667, edg-perf11-61837], [edg-perf10-20667|19] (3) [edg-perf10-20667, edg-perf12-7305, edg-perf11-61837], [edg-perf10-20667|18] (1) [edg-perf10-20667], [edg-perf10-20667|21] (2) [edg-perf10-20667, edg-perf13-25187] > {code} > 8. get operation returns outdated value > {code} > 10:26:21,020 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (DefaultStressor-6) Response(s) to ClusteredGetCommand{key=key_000000000000065B, flags=null} is {edg-perf12-7305=SuccessfulResponse{responseValue=ImmortalCacheValue {value=[6 #14: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, ]}} } > {code} > From client perspective, this behavior is not transparent. Provided the transaction ended up successfully, presence of the updated entry can be assumed. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 6 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5019: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3362 > 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.2.0.CR1 > > > 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.11#6341)

10 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2015