March 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5230) CacheNotifierImpl should use a TypeConverter to unbox the key and value when RemoteValueWrapperInterceptor is used

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5230?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned ISPN-5230: ----------------------------------- Assignee: Adrian Nistor > CacheNotifierImpl should use a TypeConverter to unbox the key and value when RemoteValueWrapperInterceptor is used > ------------------------------------------------------------------------------------------------------------------ > > Key: ISPN-5230 > URL: https://issues.jboss.org/browse/ISPN-5230 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.1.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5230) CacheNotifierImpl should use a TypeConverter to unbox the key and value when RemoteValueWrapperInterceptor is used

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5230?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5230: -------------------------------- Status: Open (was: New) > CacheNotifierImpl should use a TypeConverter to unbox the key and value when RemoteValueWrapperInterceptor is used > ------------------------------------------------------------------------------------------------------------------ > > Key: ISPN-5230 > URL: https://issues.jboss.org/browse/ISPN-5230 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.1.0.Final > Reporter: Adrian Nistor > Fix For: 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5305) Pessimistic locking: transactions with more than one affected keys should replicate lock commands to all backups

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5305: ---------------------------------- Summary: Pessimistic locking: transactions with more than one affected keys should replicate lock commands to all backups Key: ISPN-5305 URL: https://issues.jboss.org/browse/ISPN-5305 Project: Infinispan Issue Type: Bug Components: Core Reporter: Dan Berindei Assignee: Dan Berindei Pessimistic locking includes an optimization to not replicate the lock command to the backups if the transaction only affects a single key and the originator is the primary owner. However, the implementation is incorrect, and it checks each modification individually and it doesn't check if the transaction has more than one modification commands. We should also make sure that when a second modification is added, we replicate the lock command for the first modification to its backup owners. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5208) Avoid invalid topology

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5208?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-5208: ---------------------------------------- @Takayoshi, I've created a PR in which we avoid installing empty views for Hot Rod 2.x and 1.x protocols, and we print some WARN messages to get more information about this one. If you want to get some targeted TRACE messages, I'd suggest you enable it for "org.infinispan.server.hotrod.Encoder2x" and "org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory" classes. > Avoid invalid topology > ---------------------- > > Key: ISPN-5208 > URL: https://issues.jboss.org/browse/ISPN-5208 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Takayoshi Kimura > Assignee: Galder Zamarreño > Labels: jdg641 > Fix For: 7.2.0.Final > > > We've seen some invalid topology propagated to client and it causes ArrayIndexOutOfBoundsException: > {noformat} > Caused by: java.lang.ArrayIndexOutOfBoundsException: 0 > at org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy.getServerByIndex(RoundRobinBalancingStrategy.java:68) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy.nextServer(RoundRobinBalancingStrategy.java:44) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.nextServer(TcpTransportFactory.java:220) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:194) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.getTransport(FaultTolerantPingOperation.java:27) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:48) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:535) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.RemoteCacheManager.ping(RemoteCacheManager.java:635) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:616) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:527) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:523) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > {noformat} > {noformat} > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 > at org.infinispan.client.hotrod.impl.consistenthash.SegmentConsistentHash.getServer(SegmentConsistentHash.java:33) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:204) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.getTransport(AbstractKeyOperation.java:40) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:48) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) > at sample.Main.main(Main.java:16) > {noformat} > It happens on both Hot Rod 2 and 1.3 clients. > It's really hard to reproduce this state and we don't have a consistent way to reproduce it. However when this happens there is always view change happening so it's related to view change. > Judging from the stack trace, the client receives numOwners=0 or numSegments=0 topology from the server. > Also we are unable to find to recover this situation. Rebooting random nodes don't help and keep getting this exceptions on client side. > Until we can find the root cause, I think it's better to add a guard to avoid this kind invalid topology stored in the server side and propagated to the clients. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5208) Avoid invalid topology

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5208?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5208: ----------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/3312 (was: https://github.com/infinispan/infinispan/pull/3311) > Avoid invalid topology > ---------------------- > > Key: ISPN-5208 > URL: https://issues.jboss.org/browse/ISPN-5208 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Takayoshi Kimura > Assignee: Galder Zamarreño > Labels: jdg641 > Fix For: 7.2.0.Final > > > We've seen some invalid topology propagated to client and it causes ArrayIndexOutOfBoundsException: > {noformat} > Caused by: java.lang.ArrayIndexOutOfBoundsException: 0 > at org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy.getServerByIndex(RoundRobinBalancingStrategy.java:68) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy.nextServer(RoundRobinBalancingStrategy.java:44) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.nextServer(TcpTransportFactory.java:220) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:194) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.getTransport(FaultTolerantPingOperation.java:27) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:48) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:535) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.RemoteCacheManager.ping(RemoteCacheManager.java:635) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:616) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:527) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:523) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4] > {noformat} > {noformat} > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 > at org.infinispan.client.hotrod.impl.consistenthash.SegmentConsistentHash.getServer(SegmentConsistentHash.java:33) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:204) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.getTransport(AbstractKeyOperation.java:40) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:48) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) > at sample.Main.main(Main.java:16) > {noformat} > It happens on both Hot Rod 2 and 1.3 clients. > It's really hard to reproduce this state and we don't have a consistent way to reproduce it. However when this happens there is always view change happening so it's related to view change. > Judging from the stack trace, the client receives numOwners=0 or numSegments=0 topology from the server. > Also we are unable to find to recover this situation. Rebooting random nodes don't help and keep getting this exceptions on client side. > Until we can find the root cause, I think it's better to add a guard to avoid this kind invalid topology stored in the server side and propagated to the clients. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5301) Make CompositeNotifyingFuture more generic

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5301?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5301: -------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Gustavo Fernandes Fix Version/s: 7.2.0.Beta1 Resolution: Done Integrated in master. Thanks [~gustavonalle]! > Make CompositeNotifyingFuture more generic > ------------------------------------------ > > Key: ISPN-5301 > URL: https://issues.jboss.org/browse/ISPN-5301 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 7.2.0.Alpha1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.2.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5300) CacheEventFilterAsKeyValueFilter must pass the value and metadata as 'new' to the underlying CacheEventFilter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5300?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5300: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1202413|https://bugzilla.redhat.com/show_bug.cgi?id=1202413] from NEW to POST > CacheEventFilterAsKeyValueFilter must pass the value and metadata as 'new' to the underlying CacheEventFilter > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5300 > URL: https://issues.jboss.org/browse/ISPN-5300 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.Beta1, 7.2.0.Final, 7.1.2.Final > > > Current implementetion passes the value as old value to the wrapped filter. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5300) CacheEventFilterAsKeyValueFilter must pass the value and metadata as 'new' to the underlying CacheEventFilter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5300?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5300: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1202409|https://bugzilla.redhat.com/show_bug.cgi?id=1202409] from NEW to POST > CacheEventFilterAsKeyValueFilter must pass the value and metadata as 'new' to the underlying CacheEventFilter > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5300 > URL: https://issues.jboss.org/browse/ISPN-5300 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.Beta1, 7.2.0.Final, 7.1.2.Final > > > Current implementetion passes the value as old value to the wrapped filter. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5300) CacheEventFilterAsKeyValueFilter must pass the value and metadata as 'new' to the underlying CacheEventFilter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5300?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5300: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1202409 > CacheEventFilterAsKeyValueFilter must pass the value and metadata as 'new' to the underlying CacheEventFilter > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5300 > URL: https://issues.jboss.org/browse/ISPN-5300 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.Beta1, 7.2.0.Final, 7.1.2.Final > > > Current implementetion passes the value as old value to the wrapped filter. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5300) CacheEventFilterAsKeyValueFilter must pass the value and metadata as 'new' to the underlying CacheEventFilter

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5300?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-5300: ------------------------------------- 7.2.0.Beta1 has been integrated. > CacheEventFilterAsKeyValueFilter must pass the value and metadata as 'new' to the underlying CacheEventFilter > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5300 > URL: https://issues.jboss.org/browse/ISPN-5300 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.Beta1, 7.2.0.Final, 7.1.2.Final > > > Current implementetion passes the value as old value to the wrapped filter. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2015