October 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5875) HotRod Client does not handle failover silent when nodes are stopped if using role based authentication

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5875?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5875: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1273137|https://bugzilla.redhat.com/show_bug.cgi?id=1273137] from NEW to ASSIGNED > HotRod Client does not handle failover silent when nodes are stopped if using role based authentication > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-5875 > URL: https://issues.jboss.org/browse/ISPN-5875 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Security > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Critical > Labels: hotrod, hotrod-java-client, security > Fix For: 8.1.0.Beta1, 8.1.0.Final, 8.0.2.Final > > > A HotRod client fail over silent if one instance is shutting down if there is no Security enabled. > With role based authentication the client fail sporadically with a WARN message > {code}WARN: ISPN004005: Error received from the server: java.security.PrivilegedActionException: > org.infinispan.IllegalLifecycleStateException: ISPN000324: Cache 'testCache' is in 'STOPPING' state and this is an invocation not > belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > {code} > and the following Exception: > {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[2825] returned server error (status=0x85): > java.security.PrivilegedActionException: org.infinispan.IllegalLifecycleStateException: ISPN000324: Cache 'testCache' is in 'STOPPING' > state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate > the cache container. > at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:336) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:126) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:112) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:57) > at org.infinispan.client.hotrod.impl.operations.PutIfAbsentOperation.executeOperation(PutIfAbsentOperation.java:36) > at org.infinispan.client.hotrod.impl.operations.PutIfAbsentOperation.executeOperation(PutIfAbsentOperation.java:23) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:52) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.putIfAbsent(RemoteCacheImpl.java:257) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.putIfAbsent(RemoteCacheSupport.java:54) > at HotRodTestClient.updateCache(HotRodTestClient.java:69) > at HotRodTestClient.lambda$queuePut$0(HotRodTestClient.java:88) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5891) IntegrationTest.testConcurrentETagChanges always fails

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5891?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5891: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3786 > IntegrationTest.testConcurrentETagChanges always fails > ------------------------------------------------------ > > Key: ISPN-5891 > URL: https://issues.jboss.org/browse/ISPN-5891 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite - Server > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.1.0.Beta1 > > > The test always fails since the ISPN-5857 fix was integrated. > When executing a {{PUT}} operation, the REST server always looks up the previous value, and if it exists, it executes a {{cache.replace(k, old, new)}} cache operation instead of a regular push. But the cache is configured with {{value-equivalence=AnyEquivalence}}, so the replace fails if the REST server is not the primary owner. > It was successful before the ISPN-5857 fix only because the server was the primary owner of the key, and then only because {{ValueMatcher.equal()}} checks identity first. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5893) ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5893?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5893: ------------------------------- Status: Open (was: New) > ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails > -------------------------------------------------------------------------- > > Key: ISPN-5893 > URL: https://issues.jboss.org/browse/ISPN-5893 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 8.1.0.Beta1 > > > Since the ISPN-5857 fix, ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails. > The problem is that the "k1" key no longer has node 1 as the primary owner. Because replication between the primary (node 2) and the backup (node 1) is asynchronous, a get after a put on node 1 almost never finds the value. > The simple fix would be to swap the roles of node 1 and node 2 in the test. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5893) ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5893?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5893: ------------------------------- Priority: Blocker (was: Major) > ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails > -------------------------------------------------------------------------- > > Key: ISPN-5893 > URL: https://issues.jboss.org/browse/ISPN-5893 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.1.0.Beta1 > > > Since the ISPN-5857 fix, ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails. > The problem is that the "k1" key no longer has node 1 as the primary owner. Because replication between the primary (node 2) and the backup (node 1) is asynchronous, a get after a put on node 1 almost never finds the value. > The simple fix would be to swap the roles of node 1 and node 2 in the test. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5893) ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5893?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5893: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3786 > ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails > -------------------------------------------------------------------------- > > Key: ISPN-5893 > URL: https://issues.jboss.org/browse/ISPN-5893 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.1.0.Beta1 > > > Since the ISPN-5857 fix, ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails. > The problem is that the "k1" key no longer has node 1 as the primary owner. Because replication between the primary (node 2) and the backup (node 1) is asynchronous, a get after a put on node 1 almost never finds the value. > The simple fix would be to swap the roles of node 1 and node 2 in the test. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5889) Merge views not dealt with in Hot Rod server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5889?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5889: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1274155|https://bugzilla.redhat.com/show_bug.cgi?id=1274155] from NEW to ASSIGNED > Merge views not dealt with in Hot Rod server > -------------------------------------------- > > Key: ISPN-5889 > URL: https://issues.jboss.org/browse/ISPN-5889 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.0.1.Final, 8.1.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.1.0.Beta1, 8.1.0.Final > > > Hot Rod server does not deal with merge views, so when members return back to the cluster, the view is not updated. The Hot Rod server view change listener currently only deals with nodes leaving or crashing. This problem is not a big one since it just means that until the next view change happens, clients will work with a reduced view, working in a suboptimal way, but it won't have correctness impact. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5893) ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5893: ---------------------------------- Summary: ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails Key: ISPN-5893 URL: https://issues.jboss.org/browse/ISPN-5893 Project: Infinispan Issue Type: Bug Components: Test Suite - Server Affects Versions: 8.1.0.Alpha2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 8.1.0.Beta1 Since the ISPN-5857 fix, ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails. The problem is that the "k1" key no longer has node 1 as the primary owner. Because replication between the primary (node 2) and the backup (node 1) is asynchronous, a get after a put on node 1 almost never finds the value. The simple fix would be to swap the roles of node 1 and node 2 in the test. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5892) XML configuration should include number of segments for replicated caches

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5892?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5892: ------------------------------- Description: The primary owner of a key is determined based on the segment, so for remote caches it's good to increase the number of segments when there are many nodes in the cluster. Groups configuration may be useful as well. > XML configuration should include number of segments for replicated caches > ------------------------------------------------------------------------- > > Key: ISPN-5892 > URL: https://issues.jboss.org/browse/ISPN-5892 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 8.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta1 > > > The primary owner of a key is determined based on the segment, so for remote caches it's good to increase the number of segments when there are many nodes in the cluster. Groups configuration may be useful as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5892) XML configuration should include number of segments for replicated caches

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5892?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5892: ------------------------------- Status: Open (was: New) > XML configuration should include number of segments for replicated caches > ------------------------------------------------------------------------- > > Key: ISPN-5892 > URL: https://issues.jboss.org/browse/ISPN-5892 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 8.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta1 > > > The primary owner of a key is determined based on the segment, so for remote caches it's good to increase the number of segments when there are many nodes in the cluster. Groups configuration may be useful as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5892) XML configuration should include number of segments for replicated caches

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5892: ---------------------------------- Summary: XML configuration should include number of segments for replicated caches Key: ISPN-5892 URL: https://issues.jboss.org/browse/ISPN-5892 Project: Infinispan Issue Type: Feature Request Components: Core Affects Versions: 8.0.1.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 8.1.0.Beta1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 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 October 2015