[JBoss JIRA] (ISPN-2792) Allow logging at TRACE level for a single test in the test suite
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2792?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2792:
-------------------------------------
{quote}There are some threads that don't follow this rule, e.g. the HotRod worker threads, but it should be useful in most cases.{quote}
Would be nice to have these logging the test name as well.
What advantage would this have over the grepping the logs for a single test?
> Allow logging at TRACE level for a single test in the test suite
> ----------------------------------------------------------------
>
> Key: ISPN-2792
> URL: https://issues.jboss.org/browse/ISPN-2792
> Project: Infinispan
> Issue Type: Enhancement
> Components: Test Suite
> Affects Versions: 5.2.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 5.2.1, 5.3.0.Alpha1
>
>
> Log4J has support for [filters|http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/spi/...] that can allow or disallow log messages based on their properties, e.g. the thread name.
> Since the names of most threads in the test suite include the test name, we should create a filter that only allows a log message if the thread name matches a regular expression.
> There are some threads that don't follow this rule, e.g. the HotRod worker threads, but it should be useful in most cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2787) NPE after ReplaceCommand
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2787?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2787:
--------------------------------
Fix Version/s: 5.2.1
> NPE after ReplaceCommand
> ------------------------
>
> Key: ISPN-2787
> URL: https://issues.jboss.org/browse/ISPN-2787
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Final
> Reporter: Michal Linhard
> Assignee: Mircea Markus
> Fix For: 5.2.1, 5.3.0.Final
>
>
> (from https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR...)
> {code}
> 05:11:10,804 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/].[Resteasy]] (http-/172.18.1.7:8080-15) Servlet.service() for servlet Resteasy threw exception: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:351) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:220) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:196) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:551) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:513) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.1.Final-redhat-2.jar:1.0.1.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38]
> Caused by: java.lang.NullPointerException
> at org.infinispan.CacheImpl.replaceInternal(CacheImpl.java:828) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.CacheImpl.replace(CacheImpl.java:822) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.CacheImpl.replace(CacheImpl.java:817) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.AbstractDelegatingCache.replace(AbstractDelegatingCache.java:153) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.rest.Server.putOrReplace(Server.scala:186) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server.org$infinispan$rest$Server$$putInCache(Server.scala:157) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server$$anonfun$putEntry$1.apply(Server.scala:133) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server$$anonfun$putEntry$1.apply(Server.scala:120) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server.protectCacheNotFound(Server.scala:254) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server.putEntry(Server.scala:120) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) [:1.6.0_38]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_38]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:536) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> ... 18 more
> {code}
> Seems like the NPE is caused by ReplaceCommand.perform returning null:
> https://github.com/infinispan/infinispan/blob/5.2.0.Final/core/src/main/j...
> Made possible here:
> https://github.com/infinispan/infinispan/blob/5.2.0.Final/core/src/main/j...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2790) ReplCommandForwardingTest fails most of the time in CI
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2790?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2790:
------------------------------------
I have some tests in CloudBees with a timeout of 10 seconds, but even that doesn't seem to be enough. NodeA, the first one to start, manages to start and install the initial view in 1.5 seconds, but for NodeB and NodeC it takes > 8 seconds just to configure (!) the JGroups stack.
{noformat}
08:44:13,654 INFO (testng-ReplCommandForwardingTest:___defaultcache) [JGroupsTransport] ISPN000078: Starting JGroups Channel
08:44:14,360 DEBUG (testng-ReplCommandForwardingTest:___defaultcache) [Configurator] set property TCP.diagnostics_addr to default value /224.0.75.75
08:44:15,046 DEBUG (testng-ReplCommandForwardingTest:___defaultcache) [JGroupsTransport] New view accepted: [NodeA-34712|0] [NodeA-34712]
{noformat}
{noformat}
08:44:15,586 INFO (testng-ReplCommandForwardingTest:___defaultcache) [JGroupsTransport] ISPN000078: Starting JGroups Channel
08:44:24,497 DEBUG (testng-ReplCommandForwardingTest:___defaultcache) [Configurator] set property TCP.diagnostics_addr to default value /224.0.75.75
08:44:25,533 DEBUG (testng-ReplCommandForwardingTest:___defaultcache) [GMS] sending JOIN(NodeB-8398) to NodeA-34712
08:44:25,919 DEBUG (Incoming-1,ISPN,NodeA-34712:) [JGroupsTransport] New view accepted: [NodeA-34712|1] [NodeA-34712, NodeB-8398]
{noformat}
{noformat}
08:44:28,739 INFO (testng-ReplCommandForwardingTest:___defaultcache) [JGroupsTransport] ISPN000078: Starting JGroups Channel
08:44:35,919 DEBUG (testng-ReplCommandForwardingTest:___defaultcache) [Configurator] set property TCP.diagnostics_addr to default value /224.0.75.75
08:44:38,152 DEBUG (testng-ReplCommandForwardingTest:___defaultcache) [GMS] sending JOIN(NodeC-2025) to NodeA-34712
08:44:39,581 DEBUG (Incoming-3,ISPN,NodeA-34712:) [JGroupsTransport] New view accepted: [NodeA-34712|2] [NodeA-34712, NodeB-8398, NodeC-2025]
{noformat}
I had another run with {{-verbose:gc}} and there isn't any sign of GC activity during that period.
> ReplCommandForwardingTest fails most of the time in CI
> ------------------------------------------------------
>
> Key: ISPN-2790
> URL: https://issues.jboss.org/browse/ISPN-2790
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 5.2.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 5.2.1, 5.3.0.Alpha1
>
>
> ReplCommandForwardingTest seems to fail every single time in CloudBees.
> As I have never seen it fail on my machine, I'm assuming this is a timing issue and I'm going to increase the timeouts in the test.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2788) NullPointerException appears in case passing null as an exclusion list to LuceneCacheLoader.loadAllKeys()
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2788?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-2788:
---------------------------------------
thanks. I'll fix it after someone merges https://github.com/infinispan/infinispan/pull/1619
> NullPointerException appears in case passing null as an exclusion list to LuceneCacheLoader.loadAllKeys()
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2788
> URL: https://issues.jboss.org/browse/ISPN-2788
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Fix For: 5.3.0.Alpha1
>
>
> NullPointerException is thrown in case of passing null as a keyExclusionList to LuceneCacheLoader.loadAllKeys() method.
> The log is:
> {code}
> java.lang.NullPointerException
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadSomeKeys(DirectoryLoaderAdaptor.java:108)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadAllKeys(DirectoryLoaderAdaptor.java:174)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.loadAllKeys(LuceneCacheLoader.java:126)
> at org.infinispan.lucene.cacheloader.LuceneCacheLoaderTest.testLoadAllKeysWithNullExclusion(LuceneCacheLoaderTest.java:263)
> 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:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2783) Query on Invalidation cache fails in case of non-InfinispanDirectoryProvider
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2783?page=com.atlassian.jira.plugin.... ]
Anna Manukyan commented on ISPN-2783:
-------------------------------------
Ok, then lets wait until it would be decided whether the Invalidation mode is supported in the next release or no.
> Query on Invalidation cache fails in case of non-InfinispanDirectoryProvider
> ----------------------------------------------------------------------------
>
> Key: ISPN-2783
> URL: https://issues.jboss.org/browse/ISPN-2783
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Fix For: 5.2.1, 5.3.0.Final
>
> Attachments: ClusteredInvalidationCacheTest.java
>
>
> Assume that node1 contains entries, node2 doesn't. And assume, that the cache on both nodes is configured as:
> {code}
> ConfigurationBuilder cacheCfg = getDefaultClusteredCacheConfig(CacheMode.INVALIDATION_SYNC, false);
> cacheCfg.indexing()
> .enable()
> .indexLocalOnly(true)
> .addProperty("default.directory_provider", "ram")
> .addProperty("lucene_version", "LUCENE_CURRENT") ;
>
> List<Cache<String, Person>> caches = createClusteredCaches(2, cacheCfg);
> {code}
> If I'm running the query on node1, then the query proceeds properly.
> If I'm running the query on node2, then I'm getting the following exception:
> {code}
> org.hibernate.search.SearchException: There are no mapped entities. Don't forget to add @Indexed to at least one class.
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:534)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:511)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.queryEntityInfos(HSQueryImpl.java:249)
> at org.infinispan.query.impl.CacheQueryImpl.list(CacheQueryImpl.java:170)
> at org.infinispan.query.blackbox.ClusteredInvalidationCacheTest.testSimple(ClusteredInvalidationCacheTest.java:119)
> {code}
> You can find the test attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2788) NullPointerException appears in case passing null as an exclusion list to LuceneCacheLoader.loadAllKeys()
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2788?page=com.atlassian.jira.plugin.... ]
Anna Manukyan edited comment on ISPN-2788 at 2/5/13 3:50 AM:
-------------------------------------------------------------
My code is the following:
{code}
File rootDir = createRootDir(); //Creating root directory of the index
EmbeddedCacheManager cacheManager = null;
createIndex(rootDir, indexName, elementCount, true); //Manually writes some data to the index with number of elementCount
//to index with name indexName - as is done in
//org.infinispan.lucene.cacheloader.IndexCacheLoaderTest
ConfigurationBuilder builder = new ConfigurationBuilder();
builder
.loaders()
.addLoader()
.cacheLoader( new LuceneCacheLoader() )
.addProperty(LuceneCacheLoaderConfig.LOCATION_OPTION, rootDir.getAbsolutePath())
.addProperty(LuceneCacheLoaderConfig.AUTO_CHUNK_SIZE_OPTION, "1024");
EmbeddedCacheManager cacheManager = TestCacheManagerFactory.createCacheManager(builder);
LuceneCacheLoader cacheLoader = (LuceneCacheLoader) TestingUtil.extractComponent(cacheManager.getCache(),
CacheLoaderManager.class).getCacheLoader();
Set keyList = cacheLoader.loadAllKeys(null); // <<<----- This is the line which throws the NullPointerException.
{code}
According to JavaDoc, if null is passed as a parameter to loadAllKeys() method, then it should load all keys without exclusions, but instead it throws NullPointerException.
was (Author: amanukyan):
My code is the following:
{code}
File rootDir = createRootDir(); //Creating root directory of the index
EmbeddedCacheManager cacheManager = null;
createIndex(rootDir, indexName, elementCount, true); //Manually writes some data to the index with number of elementCount to index with name indexName - as is done in org.infinispan.lucene.cacheloader.IndexCacheLoaderTest
ConfigurationBuilder builder = new ConfigurationBuilder();
builder
.loaders()
.addLoader()
.cacheLoader( new LuceneCacheLoader() )
.addProperty(LuceneCacheLoaderConfig.LOCATION_OPTION, rootDir.getAbsolutePath())
.addProperty(LuceneCacheLoaderConfig.AUTO_CHUNK_SIZE_OPTION, "1024");
EmbeddedCacheManager cacheManager = TestCacheManagerFactory.createCacheManager(builder);
LuceneCacheLoader cacheLoader = (LuceneCacheLoader) TestingUtil.extractComponent(cacheManager.getCache(),
CacheLoaderManager.class).getCacheLoader();
Set keyList = cacheLoader.loadAllKeys(null); // <<<----- This is the line which throws the NullPointerException.
{code}
According to JavaDoc, if null is passed as a parameter to loadAllKeys() method, then it should load all keys without exclusions, but instead it throws NullPointerException.
> NullPointerException appears in case passing null as an exclusion list to LuceneCacheLoader.loadAllKeys()
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2788
> URL: https://issues.jboss.org/browse/ISPN-2788
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Fix For: 5.3.0.Alpha1
>
>
> NullPointerException is thrown in case of passing null as a keyExclusionList to LuceneCacheLoader.loadAllKeys() method.
> The log is:
> {code}
> java.lang.NullPointerException
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadSomeKeys(DirectoryLoaderAdaptor.java:108)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadAllKeys(DirectoryLoaderAdaptor.java:174)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.loadAllKeys(LuceneCacheLoader.java:126)
> at org.infinispan.lucene.cacheloader.LuceneCacheLoaderTest.testLoadAllKeysWithNullExclusion(LuceneCacheLoaderTest.java:263)
> 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:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2788) NullPointerException appears in case passing null as an exclusion list to LuceneCacheLoader.loadAllKeys()
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2788?page=com.atlassian.jira.plugin.... ]
Anna Manukyan commented on ISPN-2788:
-------------------------------------
My code is the following:
{code}
File rootDir = createRootDir(); //Creating root directory of the index
EmbeddedCacheManager cacheManager = null;
createIndex(rootDir, indexName, elementCount, true); //Manually writes some data to the index with number of elementCount to index with name indexName - as is done in org.infinispan.lucene.cacheloader.IndexCacheLoaderTest
ConfigurationBuilder builder = new ConfigurationBuilder();
builder
.loaders()
.addLoader()
.cacheLoader( new LuceneCacheLoader() )
.addProperty(LuceneCacheLoaderConfig.LOCATION_OPTION, rootDir.getAbsolutePath())
.addProperty(LuceneCacheLoaderConfig.AUTO_CHUNK_SIZE_OPTION, "1024");
EmbeddedCacheManager cacheManager = TestCacheManagerFactory.createCacheManager(builder);
LuceneCacheLoader cacheLoader = (LuceneCacheLoader) TestingUtil.extractComponent(cacheManager.getCache(),
CacheLoaderManager.class).getCacheLoader();
Set keyList = cacheLoader.loadAllKeys(null); // <<<----- This is the line which throws the NullPointerException.
{code}
According to JavaDoc, if null is passed as a parameter to loadAllKeys() method, then it should load all keys without exclusions, but instead it throws NullPointerException.
> NullPointerException appears in case passing null as an exclusion list to LuceneCacheLoader.loadAllKeys()
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2788
> URL: https://issues.jboss.org/browse/ISPN-2788
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Fix For: 5.3.0.Alpha1
>
>
> NullPointerException is thrown in case of passing null as a keyExclusionList to LuceneCacheLoader.loadAllKeys() method.
> The log is:
> {code}
> java.lang.NullPointerException
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadSomeKeys(DirectoryLoaderAdaptor.java:108)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadAllKeys(DirectoryLoaderAdaptor.java:174)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.loadAllKeys(LuceneCacheLoader.java:126)
> at org.infinispan.lucene.cacheloader.LuceneCacheLoaderTest.testLoadAllKeysWithNullExclusion(LuceneCacheLoaderTest.java:263)
> 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:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2794) undeploy of infinispan.war doesn't stop DefaultCacheManager
by Michal Linhard (JIRA)
Michal Linhard created ISPN-2794:
------------------------------------
Summary: undeploy of infinispan.war doesn't stop DefaultCacheManager
Key: ISPN-2794
URL: https://issues.jboss.org/browse/ISPN-2794
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 5.2.0.Final
Reporter: Michal Linhard
Assignee: Tristan Tarrant
1.deploy infinispan.war
2.undeploy
3.deploy, and you'll get:
{code}
09:41:43,436 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/infinispan]] (MSC service thread 1-1) Servlet /infinispan threw load() exception: org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager"
at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:101) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:95) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:63) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:705) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:300) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:139) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
at org.infinispan.rest.StartupListener.init(StartupListener.scala:57) [classes:]
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:89) [jboss-as-web-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
{code}
The problem is that DefaultCacheManager created in ManagerInstance.instance still lives after undeploy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months