November 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5968) Cache statistics are not shown for local caches in mgmt console

by Jiří Holuša (JIRA)

Jiří Holuša created ISPN-5968: --------------------------------- Summary: Cache statistics are not shown for local caches in mgmt console Key: ISPN-5968 URL: https://issues.jboss.org/browse/ISPN-5968 Project: Infinispan Issue Type: Bug Components: Console Affects Versions: 8.1.0.Beta1 Reporter: Jiří Holuša Assignee: Vladimir Blagojevic Page: Caches -> select cache container -> select some local cache When you look at the statistics, no numbers are shown, even zeros. When you put some entries to the cache, nothing caches. Note that this work fine when the cache is not local, e.g. distributed, replicated, etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5893?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5893: ----------------------------------------------- Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 1279369|https://bugzilla.redhat.com/show_bug.cgi?id=1279369] from ON_QA to VERIFIED > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3395) ISPN000196: Failed to recover cluster state after the current node became the coordinator

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3395?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3395: ----------------------------------------------- Dmitrii Tikhomirov <dtikhomi(a)redhat.com> changed the Status of [bug 1283465|https://bugzilla.redhat.com/show_bug.cgi?id=1283465] from NEW to ASSIGNED > ISPN000196: Failed to recover cluster state after the current node became the coordinator > ----------------------------------------------------------------------------------------- > > Key: ISPN-3395 > URL: https://issues.jboss.org/browse/ISPN-3395 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.3.0.Final > Reporter: Mayank Agarwal > Fix For: 6.0.2.Final, 7.0.0.Final > > > We are using infinispan 5.3.0.Final in our distributed application. we are testing infinispan in HA scenarios and getting following exception when new node becomes co-ordinator. > ISPN000196: Failed to recover cluster state after the current node became the coordinator > java.lang.NullPointerException: null > at org.infinispan.topology.ClusterTopologyManagerImpl.recoverClusterStatus(ClusterTopologyManagerImpl.java:455) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final] > at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:235) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final] > at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener$1.run(ClusterTopologyManagerImpl.java:647) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final] > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[na:1.6.0_25] > at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) ~[na:1.6.0_25] > at java.util.concurrent.FutureTask.run(Unknown Source) [na:1.6.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [na:1.6.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.6.0_25] > at java.lang.Thread.run(Unknown Source) [na:1.6.0_25] > This is happening because cacheTopology is null at ClusterTopologyManagerImpl.java:455 > at 449: code is checking cacheTopology for null that for loop which is updating cacheStatusMap at 457 should be in that check itself. > Fix: > --- a/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java > +++ b/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java > @@ -448,7 +448,7 @@ public class ClusterTopologyManagerImpl implements ClusterTopologyManager { > // but didn't get a response back yet > if (cacheTopology != null) { > topologyList.add(cacheTopology); > - } > + > > // Add all the members of the topology that have sent responses first > // If we only added the sender, we could end up with a different member order > @@ -457,6 +457,7 @@ public class ClusterTopologyManagerImpl implements ClusterTopologyManager { > cacheStatusMap.get(cacheName).addMember(member); > } > } > + } > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5967) Verify Infinispan 8.1 is binary compatible for Hibernate 2LC

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-5967: -------------------------------------- Summary: Verify Infinispan 8.1 is binary compatible for Hibernate 2LC Key: ISPN-5967 URL: https://issues.jboss.org/browse/ISPN-5967 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Blocker Fix For: 8.1.0.CR1 Make sure Hibernate 2LC testsuite can be run with Infinispan 8.1 just by swapping jars. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5092) CDI fails when both remote and embedded uber-jar are present

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5092?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5092: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1175272|https://bugzilla.redhat.com/show_bug.cgi?id=1175272] from ON_QA to VERIFIED > CDI fails when both remote and embedded uber-jar are present > ------------------------------------------------------------ > > Key: ISPN-5092 > URL: https://issues.jboss.org/browse/ISPN-5092 > Project: Infinispan > Issue Type: Bug > Components: Build process, CDI Integration > Reporter: Vojtech Juranek > Fix For: 7.2.0.CR1 > > > When both uber-jars {{infinispan-remote}} and {{infinispan-embedded}} (e.g. for {{RemoteCacheStore}}), CDI fails with > {noformat} > org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > java.lang.NullPointerException > at org.infinispan.cdi.util.defaultbean.DefaultBeanExtension.afterBeanDiscovery(DefaultBeanExtension.java:345) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267) > at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) > at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137) > at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263) > at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170) > at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51) > at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:245) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:233) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:213) > at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75) > at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:46) > at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:42) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:359) > at org.jboss.weld.bootstrap.api.helpers.ForwardingBootstrap.deployBeans(ForwardingBootstrap.java:70) > at org.jboss.weld.environment.se.Weld.initialize(Weld.java:133) > at org.infinispan.all.remote.RemoteCDIDefaultCacheTest.loadBean(RemoteCDIDefaultCacheTest.java:26) > {noformat} > It's prpbably because CDI stuff is included in both jar and {{exclude}} in {{pom.xml}} doesn't work for uber-jars -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5954) Adjust Embedded and Remote Uber Jar packaging

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5954?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5954: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1279443|https://bugzilla.redhat.com/show_bug.cgi?id=1279443] from ON_QA to VERIFIED > Adjust Embedded and Remote Uber Jar packaging > --------------------------------------------- > > Key: ISPN-5954 > URL: https://issues.jboss.org/browse/ISPN-5954 > Project: Infinispan > Issue Type: Bug > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > > During the tests it turned out that both Remote and Embedded Uber Jars contains some classes which can not be loaded by JVM (because their dependencies are not there). This is not critical, but we should get rid of them -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5966) Management console requires to log in again after page refresh

by Jiří Holuša (JIRA)

Jiří Holuša created ISPN-5966: --------------------------------- Summary: Management console requires to log in again after page refresh Key: ISPN-5966 URL: https://issues.jboss.org/browse/ISPN-5966 Project: Infinispan Issue Type: Bug Components: Console Affects Versions: 8.1.0.Beta1 Reporter: Jiří Holuša Assignee: Vladimir Blagojevic When working with management console, for example when looking at cache statistics, if I want to reload the page to see the newest values, aka doing refresh in browser (F5), the management console redirects me to login page and forces me to log in again. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3395) ISPN000196: Failed to recover cluster state after the current node became the coordinator

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3395?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3395: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1283465, https://bugzilla.redhat.com/show_bug.cgi?id=927615 (was: https://bugzilla.redhat.com/show_bug.cgi?id=927615) > ISPN000196: Failed to recover cluster state after the current node became the coordinator > ----------------------------------------------------------------------------------------- > > Key: ISPN-3395 > URL: https://issues.jboss.org/browse/ISPN-3395 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.3.0.Final > Reporter: Mayank Agarwal > Fix For: 6.0.2.Final, 7.0.0.Final > > > We are using infinispan 5.3.0.Final in our distributed application. we are testing infinispan in HA scenarios and getting following exception when new node becomes co-ordinator. > ISPN000196: Failed to recover cluster state after the current node became the coordinator > java.lang.NullPointerException: null > at org.infinispan.topology.ClusterTopologyManagerImpl.recoverClusterStatus(ClusterTopologyManagerImpl.java:455) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final] > at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:235) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final] > at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener$1.run(ClusterTopologyManagerImpl.java:647) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final] > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[na:1.6.0_25] > at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) ~[na:1.6.0_25] > at java.util.concurrent.FutureTask.run(Unknown Source) [na:1.6.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [na:1.6.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.6.0_25] > at java.lang.Thread.run(Unknown Source) [na:1.6.0_25] > This is happening because cacheTopology is null at ClusterTopologyManagerImpl.java:455 > at 449: code is checking cacheTopology for null that for loop which is updating cacheStatusMap at 457 should be in that check itself. > Fix: > --- a/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java > +++ b/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java > @@ -448,7 +448,7 @@ public class ClusterTopologyManagerImpl implements ClusterTopologyManager { > // but didn't get a response back yet > if (cacheTopology != null) { > topologyList.add(cacheTopology); > - } > + > > // Add all the members of the topology that have sent responses first > // If we only added the sender, we could end up with a different member order > @@ -457,6 +457,7 @@ public class ClusterTopologyManagerImpl implements ClusterTopologyManager { > cacheStatusMap.get(cacheName).addMember(member); > } > } > + } > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5923) Wrong results when applying the <= operator to a string attribute having a null token defined

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5923?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5923: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1254053|https://bugzilla.redhat.com/show_bug.cgi?id=1254053] from MODIFIED to ON_QA > Wrong results when applying the <= operator to a string attribute having a null token defined > --------------------------------------------------------------------------------------------- > > Key: ISPN-5923 > URL: https://issues.jboss.org/browse/ISPN-5923 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 8.0.1.Final, 8.1.0.Alpha2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.1.0.Beta2, 8.0.2.Final > > > The query having("myField").lte("Something") gets translated to lucene as myField:['_null_' TO 'Something'] where _null_ is the defined null token for this field. This query returns wrong results or no results at all, depending on the value of the null token. The issue no longer appears if there is no null token defined; it will get properly translated to myField:[* TO 'Something'] . -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5959) Continuous query does not return existing entries in embedded mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5959?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5959: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1282775|https://bugzilla.redhat.com/show_bug.cgi?id=1282775] from MODIFIED to ON_QA > Continuous query does not return existing entries in embedded mode > ------------------------------------------------------------------- > > Key: ISPN-5959 > URL: https://issues.jboss.org/browse/ISPN-5959 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.Beta1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.1.0.Beta2, 8.0.2.Final > > > CQ in embedded mode does not return any matching entries that exist prior to CQ listener registration. This does not affect remote mode. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 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 November 2015