July 2015 - infinispan-issues - Jboss List Archives

[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 updated ISPN-5568: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3590, https://github.com/infinispan/infinispan/pull/3589, 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)

9 years, 5 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 updated ISPN-5568: ------------------------------------- Status: Open (was: New) > 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)

9 years, 5 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: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1233968|https://bugzilla.redhat.com/show_bug.cgi?id=1233968] from ASSIGNED to POST > 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)

9 years, 5 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5613?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5613: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1243953 > 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 key/entry 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)

9 years, 5 months

1
0
0 / 0

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

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/ISPN-5613?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink updated ISPN-5613: ----------------------------------- Description: 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 key/entry 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. was: 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. > 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 key/entry 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)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5614) Write performance regression after ISPN-5484

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5614?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5614: ------------------------------- Status: Open (was: New) > Write performance regression after ISPN-5484 > -------------------------------------------- > > Key: ISPN-5614 > URL: https://issues.jboss.org/browse/ISPN-5614 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.Beta2 > > > Regression test shows a significant drop in throughput in the replicated and distributed write tests. > This was after adjusting the internal thread pool settings in the JGroups configuration: with the default (min=5, max=20, queue=0), the distributed read test would fail to finish. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5614) Write performance regression after ISPN-5484

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5614: ---------------------------------- Summary: Write performance regression after ISPN-5484 Key: ISPN-5614 URL: https://issues.jboss.org/browse/ISPN-5614 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 8.0.0.Beta1 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 8.0.0.Beta2 Regression test shows a significant drop in throughput in the replicated and distributed write tests. This was after adjusting the internal thread pool settings in the JGroups configuration: with the default (min=5, max=20, queue=0), the distributed read test would fail to finish. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 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: ---------------------------------- Status: Open (was: New) > 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)

9 years, 5 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 reassigned ISPN-5607: ------------------------------------- Assignee: Tristan Tarrant > 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 > Assignee: Tristan Tarrant > 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)

9 years, 5 months

1
0
0 / 0

[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)

9 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2015