November 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5907) Clear the cache stores between tests

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5907?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5907: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Clear the cache stores between tests > ------------------------------------ > > Key: ISPN-5907 > URL: https://issues.jboss.org/browse/ISPN-5907 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta2 > > > The fact that entries accumulate in the cache store slows down StateTransferDistCacheLoaderSharedTest. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5908) Stop applying state when a cache is stopping

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5908?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5908: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Stop applying state when a cache is stopping > -------------------------------------------- > > Key: ISPN-5908 > URL: https://issues.jboss.org/browse/ISPN-5908 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta2 > > > Trying to apply state after the cache was stopped only fills the logs with error messages, and slows down the test suite (especially with TRACE enabled). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5909) Speed up StateTransferLargeObjectTest

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5909?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5909: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Speed up StateTransferLargeObjectTest > ------------------------------------- > > Key: ISPN-5909 > URL: https://issues.jboss.org/browse/ISPN-5909 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Affects Versions: 8.1.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta2 > > > The test queries the caches twice at the end, once to check the value types and then again to check the actual values. The second check should be sufficient. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4356) Solr analysis cannot be used in OSGi due to Hibernate Search not being able to find Solr on classpath

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-4356?page=com.atlassian.jira.plugin.... ] Sanne Grinovero resolved ISPN-4356. ----------------------------------- Resolution: Out of Date I'm going to assume this is out of date. Please reopen if we any test proves me wrong. > Solr analysis cannot be used in OSGi due to Hibernate Search not being able to find Solr on classpath > ----------------------------------------------------------------------------------------------------- > > Key: ISPN-4356 > URL: https://issues.jboss.org/browse/ISPN-4356 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 7.0.0.Alpha4 > Reporter: Martin Gencur > Assignee: Gustavo Fernandes > > Stacktrace I got while running org.infinispan.query.analysis.SolrAnalyzerTest in Karaf : > {code} > org.hibernate.search.SearchException: Use of @AnalyzerDef while Solr is not present in the classpath. Add apache-solr-analyzer.jar > at org.hibernate.search.impl.ConfigContext.buildAnalyzer(ConfigContext.java:226) > at org.hibernate.search.impl.ConfigContext.initLazyAnalyzers(ConfigContext.java:204) > at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:389) > at org.hibernate.search.spi.SearchFactoryBuilder.buildIncrementalSearchFactory(SearchFactoryBuilder.java:166) > at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:146) > at org.hibernate.search.impl.MutableSearchFactory.addClasses(MutableSearchFactory.java:251) > at org.infinispan.query.backend.QueryInterceptor.enableClassesIncrementally(QueryInterceptor.java:272) > at org.infinispan.query.backend.QueryInterceptor.updateKnownTypesIfNeeded(QueryInterceptor.java:313) > at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:518) > at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:161) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPutKeyValueCommand(OptimisticLockingInterceptor.java:99) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) > at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:271) > at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:195) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148) > at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:111) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:74) > at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1429) > at org.infinispan.cache.impl.CacheImpl.putInternal(CacheImpl.java:907) > at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:899) > at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1474) > at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:232) > at org.infinispan.query.analysis.SolrAnalyzerTest.testAnalyzerDef(SolrAnalyzerTest.java:56) > at org.infinispan.it.osgi.query.blackbox.SolrAnalyzerTest.testAnalyzerDef(SolrAnalyzerTest.java:40) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17] > at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17] > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)[111:org.ops4j.pax.tipi.junit:4.11.0.1] > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67) > at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)[111:org.ops4j.pax.tipi.junit:4.11.0.1] > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)[111:org.ops4j.pax.tipi.junit:4.11.0.1] > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)[111:org.ops4j.pax.tipi.junit:4.11.0.1] > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)[111:org.ops4j.pax.tipi.junit:4.11.0.1] > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)[111:org.ops4j.pax.tipi.junit:4.11.0.1] > at org.junit.runners.ParentRunner.run(ParentRunner.java:309)[111:org.ops4j.pax.tipi.junit:4.11.0.1] > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:125) > at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:98) > at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:74) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17] > at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17] > at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17] > at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17] > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)[:1.7.0_17] > at sun.rmi.transport.Transport$1.run(Transport.java:177)[:1.7.0_17] > at sun.rmi.transport.Transport$1.run(Transport.java:174)[:1.7.0_17] > at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_17] > at sun.rmi.transport.Transport.serviceCall(Transport.java:173)[:1.7.0_17] > at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)[:1.7.0_17] > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)[:1.7.0_17] > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)[:1.7.0_17] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_17] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_17] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_17] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-825) Consider staggering remote get requests when using DIST

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-825?page=com.atlassian.jira.plugin.s... ] Dan Berindei updated ISPN-825: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3848 > Consider staggering remote get requests when using DIST > ------------------------------------------------------- > > Key: ISPN-825 > URL: https://issues.jboss.org/browse/ISPN-825 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 4.1.0.Final > Reporter: Manik Surtani > Assignee: William Burns > Priority: Critical > Labels: optimization, performance > > In DIST mode, when a request is made on a key that is not mapped locally, a remote get is sent to all data owners of that key and the first response is used. This can add unnecessary load on the network as all nodes still eventually respond, and if values are large this can cause a lot of unnecessary network traffic. > The purpose of broadcasting to all data owners is so that (1) if one is down, another could still respond (2) if one is overloaded, others may respond faster. > A solution around this could be based on either (or both) of: > * Provide a configurable stagger timeout, e.g. 100ms. E.g., RPC to (random) Owner1. Wait for timeout t. If no response, RPC to Owner2. etc. > * Always broadcast to a (configurable) subset of owners, e.g., always 2 even if numOwners is 5. > Needs careful thought and design. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5984) Use Message.setFlag(short) to avoid creating a temporary array

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5984?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5984: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.1.0.Final Resolution: Done > Use Message.setFlag(short) to avoid creating a temporary array > -------------------------------------------------------------- > > Key: ISPN-5984 > URL: https://issues.jboss.org/browse/ISPN-5984 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.1.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Labels: performance > Fix For: 8.1.0.Beta2, 8.1.0.Final > > > {{Message.setFlag(Message.Flag...)}} creates a temporary array on each invocation, and {{Message.setFlag(short)}} avoids it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5982) Custom audit logger is ignored in server mode

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-5982?page=com.atlassian.jira.plugin.... ] Vojtech Juranek updated ISPN-5982: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3847 > Custom audit logger is ignored in server mode > --------------------------------------------- > > Key: ISPN-5982 > URL: https://issues.jboss.org/browse/ISPN-5982 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > > When custom audit logger is configured for cache container in server mode (e.g. sniplet bellow), it's ignored and default logger is still used > {noformat} > <authorization audit-logger="org.infinispan.server.test.security.log.TestAuditLogger"> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5982) Custom audit logger is ignored in server mode

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-5982?page=com.atlassian.jira.plugin.... ] Vojtech Juranek reassigned ISPN-5982: ------------------------------------- Assignee: Vojtech Juranek > Custom audit logger is ignored in server mode > --------------------------------------------- > > Key: ISPN-5982 > URL: https://issues.jboss.org/browse/ISPN-5982 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > > When custom audit logger is configured for cache container in server mode (e.g. sniplet bellow), it's ignored and default logger is still used > {noformat} > <authorization audit-logger="org.infinispan.server.test.security.log.TestAuditLogger"> > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5982) Custom audit logger is ignored in server mode

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-5982?page=com.atlassian.jira.plugin.... ] Vojtech Juranek updated ISPN-5982: ---------------------------------- Status: Open (was: New) > Custom audit logger is ignored in server mode > --------------------------------------------- > > Key: ISPN-5982 > URL: https://issues.jboss.org/browse/ISPN-5982 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > > When custom audit logger is configured for cache container in server mode (e.g. sniplet bellow), it's ignored and default logger is still used > {noformat} > <authorization audit-logger="org.infinispan.server.test.security.log.TestAuditLogger"> > {noformat} -- 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 ASSIGNED to POST > 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2015