July 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5613) Replication timeouts should show more information of the affected entries

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created ISPN-5613: -------------------------------------- Summary: Replication timeouts should show more information of the affected entries Key: ISPN-5613 URL: https://issues.jboss.org/browse/ISPN-5613 Project: Infinispan Issue Type: Enhancement Components: Core Reporter: Wolf-Dieter Fink Assignee: Dan Berindei Typical timeouts for replication are ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread-595) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for jboss####-##### and ERROR .... Caused by: org.infinispan.util.concurrent.TimeoutException: Node jboss####-##### timed out The issue is that it is not possible to check what key7entry is affected. The cache can become inconsistent between nodes. There should be an information which key is affected. For some operations it is not possible at all as there is no information about the entries (i.e. commit) or the key is binary or custom without a valid toString() method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5612) Make filter by segment more efficient in the Remote iterator

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5612?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-5612: ----------------------------------------- This can be achieved by rebasing the IterationManager on top of the upcoming Distributed Streams > Make filter by segment more efficient in the Remote iterator > ------------------------------------------------------------ > > Key: ISPN-5612 > URL: https://issues.jboss.org/browse/ISPN-5612 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 8.0.0.Beta1 > Reporter: Gustavo Fernandes > Fix For: 8.0.0.CR1 > > > The {{org.infinispan.server.hotrod.iteration.IterationManager}} is based on the EntryRetriever, and segment filtering is currently done via a custom {{KeyValueFilterConverter}}, that needs to be run on all nodes. > In the case where all segments to be filtered on are owned by the server holding the iteration, it should skip iterating on the remote nodes altogether. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5612) Make filter by segment more efficient in the Remote iterator

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-5612: --------------------------------------- Summary: Make filter by segment more efficient in the Remote iterator Key: ISPN-5612 URL: https://issues.jboss.org/browse/ISPN-5612 Project: Infinispan Issue Type: Enhancement Components: Server Affects Versions: 8.0.0.Beta1 Reporter: Gustavo Fernandes Fix For: 8.0.0.CR1 The {{org.infinispan.server.hotrod.iteration.IterationManager}} is based on the EntryRetriever, and segment filtering is currently done via a custom {{KeyValueFilterConverter}}, that needs to be run on all nodes. In the case where all segments to be filtered on are owned by the server holding the iteration, it should skip iterating on the remote nodes altogether. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5611) Make the remote iterator to respect the RequestBalancingStrategy in the Hot Rod client

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-5611: --------------------------------------- Summary: Make the remote iterator to respect the RequestBalancingStrategy in the Hot Rod client Key: ISPN-5611 URL: https://issues.jboss.org/browse/ISPN-5611 Project: Infinispan Issue Type: Enhancement Components: Remote Protocols Affects Versions: 8.0.0.Beta1 Reporter: Gustavo Fernandes Assignee: Gustavo Fernandes Fix For: 8.0.0.CR1 Currently the initial server that will hold the iteration state is automatically chosen based on segment ownership. If data location is known beforehand, it's more efficient to hint the iteration to start on a certain node. The {{FailoverRequestBalancingStrategy}} is a mechanism in place to do that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

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

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/ISPN-5568?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski commented on ISPN-5568: ------------------------------------------ https://issues.jboss.org/browse/WFLY-4942 https://issues.jboss.org/browse/ISPN-5568 https://bugzilla.redhat.com/show_bug.cgi?id=1233968 master: https://github.com/infinispan/infinispan/pull/3590 7.2.x: https://github.com/infinispan/infinispan/pull/3589 5.2.x: https://github.com/infinispan/infinispan/pull/3588 > 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 > > 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.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5293) Create generic execution framework from EntryIterator

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5293?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5293: -------------------------------- Fix Version/s: 8.0.0.Final > Create generic execution framework from EntryIterator > ----------------------------------------------------- > > Key: ISPN-5293 > URL: https://issues.jboss.org/browse/ISPN-5293 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Execution and Map/Reduce > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.Final > > > This framework could be used to power a segment aware map/reduce framework and other events that require execution across the cluster. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5607) NearCache: it is possible to read stale data with a put/remove followed by a get

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5607?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5607: ---------------------------------- Fix Version/s: 7.2.4.Final 8.0.0.Final > NearCache: it is possible to read stale data with a put/remove followed by a get > -------------------------------------------------------------------------------- > > Key: ISPN-5607 > URL: https://issues.jboss.org/browse/ISPN-5607 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final > Environment: one hotrod client with 2 hotrod servers > Reporter: Enrico Olivelli > Priority: Blocker > Fix For: 7.2.4.Final, 8.0.0.Final > > > Writes to the NearCache do not invalidate/update local data on put/remove operations, and so the NearCache (LAZY MODE) is invalidated using an eventlistener in an asynch way. > It is possible for a client to write a value and issue a get on the same key, and the result of the get would not be the latest value but the one which was present before the update operation. > This happens frequently when there is very much traffic on the connection of the listener which receives the events for the NearCache. > It would be better at least to invalidate locally every entry modified from the client itself -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5293) Create generic execution framework from EntryIterator

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5293?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5293: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3569 > Create generic execution framework from EntryIterator > ----------------------------------------------------- > > Key: ISPN-5293 > URL: https://issues.jboss.org/browse/ISPN-5293 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Execution and Map/Reduce > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.Final > > > This framework could be used to power a segment aware map/reduce framework and other events that require execution across the cluster. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3076) Infinispan should enable use of log4j2

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3076?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3076: ---------------------------------- Fix Version/s: 8.0.0.Beta2 > Infinispan should enable use of log4j2 > -------------------------------------- > > Key: ISPN-3076 > URL: https://issues.jboss.org/browse/ISPN-3076 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 5.2.5.Final, 6.0.0.Final > Environment: Any > Reporter: Divya Mehra > Assignee: Tristan Tarrant > Fix For: 8.0.0.Beta2, 8.0.0.Final > > > log4j locks up on a certain amount of load, especially under concurrent access. The recommendation was to move up to log4j2. This can be done by removing > 1 JAR (log4j.jar) and adding 2 JARs (log4j-bridge and log4j-core.jar). > Also refer: https://issues.jboss.org/browse/ISPN-2976 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3076) Infinispan should enable use of log4j2

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3076?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3076: ---------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/3400, https://github.com/infinispan/infinispan/pull/3410, https://github.com/infinispan/infinispan/pull/3587 (was: https://github.com/infinispan/infinispan/pull/3400, https://github.com/infinispan/infinispan/pull/3410) > Infinispan should enable use of log4j2 > -------------------------------------- > > Key: ISPN-3076 > URL: https://issues.jboss.org/browse/ISPN-3076 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 5.2.5.Final, 6.0.0.Final > Environment: Any > Reporter: Divya Mehra > Assignee: Tristan Tarrant > Fix For: 8.0.0.Beta2, 8.0.0.Final > > > log4j locks up on a certain amount of load, especially under concurrent access. The recommendation was to move up to log4j2. This can be done by removing > 1 JAR (log4j.jar) and adding 2 JARs (log4j-bridge and log4j-core.jar). > Also refer: https://issues.jboss.org/browse/ISPN-2976 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 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 July 2015