March 2015 - infinispan-issues - Jboss List Archives

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

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5300?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5300: -------------------------------- Status: Open (was: New) > 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 Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5300?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5300: -------------------------------- Fix Version/s: 7.1.2.Final > 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 Adrian Nistor (JIRA)

Adrian Nistor created ISPN-5300: ----------------------------------- Summary: 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 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-5283) Hot Rod client does not update the cluster view for the client after a complete shutdown of all servers

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5283?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5283: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1200360, https://bugzilla.redhat.com/show_bug.cgi?id=1201626 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1200360) > Hot Rod client does not update the cluster view for the client after a complete shutdown of all servers > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-5283 > URL: https://issues.jboss.org/browse/ISPN-5283 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.2.Final, 7.1.1.Final > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Fix For: 7.2.0.Beta1, 7.2.0.Final > > > If a Hot Rod client is connected to two (or more) servers and these servers are stopped the client will not continue to work until this last server is back online. > But even if the client is able to continue, the client will not receive updated cluster topology. > Therefor there is no loadbalacing and failover after this point until the client is restarted. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5234) Implement single cluster view page (P1)

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-5234?page=com.atlassian.jira.plugin.... ] Tomas Sykora commented on ISPN-5234: ------------------------------------ Hey [~vblagojevic], I have great news for you. I've managed to finish rough proposal of working filtering sliders on cluster view page before leaving to PTO. A few notes: 1) Rough proposal :-) don't consider it finished, I have to pack my skies :) 2) Filtered caches are shown BELOW the full list of all caches for now. This approach demonstrates new functionality and will be changed during polishing when I want to implement it to work with main cache array. 3) That "value-skipping" in slider can be set up. This is just impl. detail and we will discuss it. Try out how it works please. 4) For now it is needed to press Apply Filters button -- then you should see filtering happen. If you do it with pre-set filters, all caches should be shown. When you move values, caches will disappear (caches from RESULT tmp array) 5) Caches have by default Average replication time between 8 - 13 ms... try that particular slider. Other values are 0 because no putting is happening (by default) 6) Feel free to comment directly to my commit in my origin branch, links are below. I consider this to be quite good baseline and we will polish it. https://github.com/tsykora/infinispan-management-console/commits/nouislid... https://github.com/tsykora/infinispan-management-console/commit/9d58929b1... > Implement single cluster view page (P1) > --------------------------------------- > > Key: ISPN-5234 > URL: https://issues.jboss.org/browse/ISPN-5234 > Project: Infinispan > Issue Type: Task > Components: JMX, reporting and management > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 8.0.0.Final > > > In our admin console current single cluster view page does not contain the following functionality that should be implemented: > * -Zoom in/out- > * Node availability/detail > * Filter by metrics (node view) > * Filter by metrics (cache view) > * Search node (search as you type) > * Search cache (search as you type) > * -Cluster switcher- > * Cluster status view -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5299) Provide resetStatistics operation and timeSinceReset attribute on CacheContainerStats

by Martin Gencur (JIRA)

Martin Gencur created ISPN-5299: ----------------------------------- Summary: Provide resetStatistics operation and timeSinceReset attribute on CacheContainerStats Key: ISPN-5299 URL: https://issues.jboss.org/browse/ISPN-5299 Project: Infinispan Issue Type: Feature Request Reporter: Martin Gencur The operation and attribute are currently missing. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5295) Remote cache entries with sub-second lifetime never expire

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-5295?page=com.atlassian.jira.plugin.... ] Ion Savin commented on ISPN-5295: --------------------------------- Open another issue for MILLISECOND precision over hotrod https://issues.jboss.org/browse/ISPN-5298 > Remote cache entries with sub-second lifetime never expire > ---------------------------------------------------------- > > Key: ISPN-5295 > URL: https://issues.jboss.org/browse/ISPN-5295 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 7.2.0.Alpha1 > Reporter: Ion Savin > > remoteCache.put("key", "value", 999, TimeUnit.MILLISECOND) > Expected: the entry expires after 999 millis > Actual: the entry never expires > HotRod lifespan is specified with second granularity but during conversion the subsecond part is truncated: > remoteCache.put("key", "value", 1999, TimeUnit.MILLISECOND) > Expected: after 1998 millis the entry is still present > Actual: after 1000 millis the entry is expired -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5298) HotRod millisecond precision for lifespan/maxidle

by Ion Savin (JIRA)

Ion Savin created ISPN-5298: ------------------------------- Summary: HotRod millisecond precision for lifespan/maxidle Key: ISPN-5298 URL: https://issues.jboss.org/browse/ISPN-5298 Project: Infinispan Issue Type: Feature Request Components: Remote Protocols Affects Versions: 7.2.0.Alpha1 Reporter: Ion Savin Currently lifespan/maxidle precision is SECONDS. JSR-107 requires MILLISECONDS precision. -- 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: ---------------------------------------- Yeah, the best is to guard here. Apart from ignoring topology updates with no segment and/or owners, we can add some warning messages in both the client and server when this happens and see if we get more information of where this is coming from. > 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: ----------------------------------- Status: Open (was: New) > 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2015