[JBoss JIRA] (ISPN-4311) Security tests, Windows, access denied (java.security.SecurityPermission setPolicy)
by Tomas Sykora (JIRA)
Tomas Sykora created ISPN-4311:
----------------------------------
Summary: Security tests, Windows, access denied (java.security.SecurityPermission setPolicy)
Key: ISPN-4311
URL: https://issues.jboss.org/browse/ISPN-4311
Project: Infinispan
Issue Type: Bug
Components: Security
Affects Versions: 7.0.0.Alpha4
Reporter: Tomas Sykora
Assignee: Tristan Tarrant
A pile of Security tests has problems with denied access when running the test suite on Windows environment.
Stacktrace
java.security.AccessControlException: access denied (javax.security.auth.AuthPermission doAs)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at java.security.AccessController.checkPermission(AccessController.java:549)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at javax.security.auth.Subject.doAs(Subject.java:326)
at org.infinispan.security.QueryAuthorizationTest.createCacheManager(QueryAuthorizationTest.java:44)
at org.infinispan.test.SingleCacheManagerTest.setup(SingleCacheManagerTest.java:31)
at org.infinispan.test.SingleCacheManagerTest.createBeforeClass(SingleCacheManagerTest.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138)
at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:175)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:107)
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:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
*Affected tests:*
org.infinispan.security.ExecutionAuthorizationTest.testExecMapReduce
org.infinispan.security.QueryAuthorizationTest.createBeforeClass
org.infinispan.security.ExecutionAuthorizationTest.testExecDistExec
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 1 month
[JBoss JIRA] (ISPN-4310) StateResponse chunk with lastChunk=true from cancelled ST stops receiving data in next ST
by Radim Vansa (JIRA)
Radim Vansa created ISPN-4310:
---------------------------------
Summary: StateResponse chunk with lastChunk=true from cancelled ST stops receiving data in next ST
Key: ISPN-4310
URL: https://issues.jboss.org/browse/ISPN-4310
Project: Infinispan
Issue Type: Bug
Components: State Transfer
Affects Versions: 7.0.0.Alpha4, 6.0.2.Final
Reporter: Radim Vansa
Assignee: Dan Berindei
Priority: Critical
1. A requests segment from B (there are multiple chunks)
2. B sends all chunks, but before A receives them, new topology arrives and A cancels the ST.
3. Another topology comes and A requests this segment again
4. A receives the old StateResponseCommand with lastChunk=true and thinks that it got all segments, therefore, it discards further chunks.
Result is inconsistent cluster, and after further rebalances completely lost data.
This ought to be rare, but was repeatedly observed when gracefully stopping coordinator on a 32-node cluster full of data.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 1 month
[JBoss JIRA] (ISPN-3530) The HotRod client should support a separate CH for each cache
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3530?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3530:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2572
> The HotRod client should support a separate CH for each cache
> -------------------------------------------------------------
>
> Key: ISPN-3530
> URL: https://issues.jboss.org/browse/ISPN-3530
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Affects Versions: 6.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Labels: hotrod, hotrod-java-client
> Fix For: 7.0.0.Beta1
>
>
> With asymmetric clusters, each cache can have its own consistent hash, so the primary owner of a key in one cache is not necessarily the owner in all the caches. Even with a symmetric cluster, the same client may be used to access both distributed and replicated caches, and those would certainly have a different CH.
> In order to send the operations to the correct owner, the HotRod client should use a different CH for each cache.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 1 month
[JBoss JIRA] (ISPN-1855) Accessing a non-distributed cache from a RemoteCacheManager can break topology updates
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1855?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-1855:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://issues.jboss.org/browse/ISPN-1855
> Accessing a non-distributed cache from a RemoteCacheManager can break topology updates
> --------------------------------------------------------------------------------------
>
> Key: ISPN-1855
> URL: https://issues.jboss.org/browse/ISPN-1855
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 5.1.1.FINAL
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1
>
>
> RemoteCacheManager uses a single consistent hash to map requests to different servers, but caches on the server may have different CHs (or even no CH if the cache is not in distributed mode).
> If the first request goes to a on-distributed cache, the client will never request an updated CH and so it will use a round robin strategy for routing request to all the caches. Obviously this is not optimal for distributed caches.
> Each distributed cache can also have different members since 5.1, so it would be best if we kept a separate CH per cache on the client.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 1 month
[JBoss JIRA] (ISPN-1855) Accessing a non-distributed cache from a RemoteCacheManager can break topology updates
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1855?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-1855:
-----------------------------------
Fix Version/s: 7.0.0.Beta1
> Accessing a non-distributed cache from a RemoteCacheManager can break topology updates
> --------------------------------------------------------------------------------------
>
> Key: ISPN-1855
> URL: https://issues.jboss.org/browse/ISPN-1855
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 5.1.1.FINAL
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1
>
>
> RemoteCacheManager uses a single consistent hash to map requests to different servers, but caches on the server may have different CHs (or even no CH if the cache is not in distributed mode).
> If the first request goes to a on-distributed cache, the client will never request an updated CH and so it will use a round robin strategy for routing request to all the caches. Obviously this is not optimal for distributed caches.
> Each distributed cache can also have different members since 5.1, so it would be best if we kept a separate CH per cache on the client.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 1 month
[JBoss JIRA] (ISPN-2752) IllegalStateException on shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2752?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2752:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 924755|https://bugzilla.redhat.com/show_bug.cgi?id=924755] from CLOSED to NEW
> IllegalStateException on shutdown
> ---------------------------------
>
> Key: ISPN-2752
> URL: https://issues.jboss.org/browse/ISPN-2752
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.2.0.CR2
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Priority: Minor
>
> This happens on graceful shutdown of 8 or 6 nodes of 5.2.0.CR2:
> {code}
> 07:17:45,892 ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] ISPN000196: Failed to recover cluster state after the current node became the coordinator: java.util.concurrent.ExecutionException: org.infinispan.CacheException: Remote (node0005/default) failed unexpectedly
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask.get(FutureTask.java:91) [rt.jar:1.6.0_33]
> at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:567) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl.recoverClusterStatus(ClusterTopologyManagerImpl.java:432) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:231) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:597) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_33]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_33]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_33]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_33]
> at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> Caused by: org.infinispan.CacheException: Remote (node0005/default) failed unexpectedly
> at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:96) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:541) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:549) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:546) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-2.jar:2.0.0.GA-redhat-2]
> Caused by: java.lang.IllegalStateException: transport was closed
> at org.jgroups.blocks.GroupRequest.transportClosed(GroupRequest.java:273) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.stop(RequestCorrelator.java:269) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher.stop(MessageDispatcher.java:152) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher.channelDisconnected(MessageDispatcher.java:455) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.Channel.notifyChannelDisconnected(Channel.java:507) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.JChannel.disconnect(JChannel.java:363) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.stop(JGroupsTransport.java:258) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_33]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_33]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_33]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_33]
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:883) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:690) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:568) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.factories.GlobalComponentRegistry.stop(GlobalComponentRegistry.java:260) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:742) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.manager.AbstractDelegatingEmbeddedCacheManager.stop(AbstractDelegatingEmbeddedCacheManager.java:179) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.jboss.as.clustering.infinispan.subsystem.EmbeddedCacheManagerService.stop(EmbeddedCacheManagerService.java:76) [jboss-datagrid-infinispan-6.1.0.ER9-redhat-1.jar:6.1.0.ER9-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA-redhat-2.jar:1.0.2.GA-redhat-2]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA-redhat-2.jar:1.0.2.GA-redhat-2]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 1 month
[JBoss JIRA] (ISPN-4309) Infinispan tree cache broken on Glassfish
by Andrew Scully (JIRA)
Andrew Scully created ISPN-4309:
-----------------------------------
Summary: Infinispan tree cache broken on Glassfish
Key: ISPN-4309
URL: https://issues.jboss.org/browse/ISPN-4309
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 6.0.2.Final
Environment: Glassfish 4, JGroups 3.4.3.Final.
Reporter: Andrew Scully
Assignee: Dan Berindei
I'm running Infinispan 6.0.2.Final (JGroups 3.4.3.Final ) on Glassfish 4.
At runtime, when creating a tree cache using new TreeCacheFactory().createTreeCache(cache), I get the following exception thrown (see bottom).
This does not happen for our other caches (only this one is a tree cache, the others are the standard Map-style caches).
Tree-cache requires TransactionMode.TRANSACTIONAL, so there is no hope of just turning off transactions for this one cache.
We did not get this on the previous version we used (5.2.1.Final), so this has been introduced since.
Having examined JavaEETransactionManagerSimplified (http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.transaction...) it appears that a bad transaction status (javax.transaction.Status.STATUS_ROLLEDBACK) is being given to the transaction layer by the BatchContainer class.
2014-05-15 15:09:29,716 ERROR [org.infinispan.transaction.TransactionCoordinator] (518,EclipseGeminiBlueprintExtenderThread-89) ISPN000188: Error while processing a commit in a two-phase transaction
org.infinispan.commons.CacheException: javax.transaction.InvalidTransactionException: Invalid transaction passed to resume() call.
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:341)
at org.infinispan.transaction.TransactionCoordinator.commitInternal(TransactionCoordinator.java:212)
at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:160)
at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58)
at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:557)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:854)
at com.sun.enterprise.transaction.TransactionManagerHelper.commit(TransactionManagerHelper.java:81)
at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101)
at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83)
at org.infinispan.batch.AutoBatchSupport.endAtomic(AutoBatchSupport.java:27)
at org.infinispan.tree.TreeStructureSupport.createNodeInCache(TreeStructureSupport.java:63)
at org.infinispan.tree.TreeStructureSupport.createNodeInCache(TreeStructureSupport.java:42)
at org.infinispan.tree.TreeCacheImpl.createRoot(TreeCacheImpl.java:437)
at org.infinispan.tree.TreeCacheImpl.<init>(TreeCacheImpl.java:32)
at org.infinispan.tree.TreeCacheImpl.<init>(TreeCacheImpl.java:24)
at org.infinispan.tree.TreeCacheFactory.createTreeCache(TreeCacheFactory.java:37)
Caused by: javax.transaction.InvalidTransactionException: Invalid transaction passed to resume() call.
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.resume(JavaEETransactionManagerSimplified.java:999)
at com.sun.enterprise.transaction.TransactionManagerHelper.resume(TransactionManagerHelper.java:96)
at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70)
at org.infinispan.commands.AbstractVisitor.visitCommitCommand(AbstractVisitor.java:106)
at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:38)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
... 39 more
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 1 month
[JBoss JIRA] (ISPN-4308) ISPN testsuite fails randomly with OOM, HEAP size
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4308?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4308:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1099880
> ISPN testsuite fails randomly with OOM, HEAP size
> -------------------------------------------------
>
> Key: ISPN-4308
> URL: https://issues.jboss.org/browse/ISPN-4308
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 7.0.0.Alpha1, 7.0.0.Alpha2, 7.0.0.Alpha4
> Environment: All
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Priority: Critical
> Labels: testsuite_stability
>
> When running ISPN testsuite following error is randomly ocurred
> {noformat}
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.14.1:test (default-test) on project infinispan-core: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.14.1:test failed: There was an error in the forked process
> [ERROR] java.lang.OutOfMemoryError: Java heap space
> [ERROR] at java.io.BufferedWriter.<init>(BufferedWriter.java:116)
> [ERROR] at java.io.BufferedWriter.<init>(BufferedWriter.java:99)
> [ERROR] at org.testng.internal.Utils.writeFile(Utils.java:190)
> [ERROR] at org.testng.internal.Utils.writeFile(Utils.java:165)
> [ERROR] at org.testng.internal.Utils.appendToFile(Utils.java:142)
> [ERROR] at org.testng.reporters.SuiteHTMLReporter.generateMethodsChronologically(SuiteHTMLReporter.java:442)
> [ERROR] at org.testng.reporters.SuiteHTMLReporter.generateReport(SuiteHTMLReporter.java:72)
> [ERROR] at org.testng.TestNG.generateReports(TestNG.java:1089)
> [ERROR] at org.testng.TestNG.run(TestNG.java:1048)
> [ERROR] at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
> [ERROR] at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:189)
> [ERROR] at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:105)
> [ERROR] at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:117)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94)
> [ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:619)
> [ERROR] at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> [ERROR] at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159)
> [ERROR] at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87)
> [ERROR] at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> [ERROR] at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> {noformat}
> Problem is in surefire plugin as it does not inherit JAVA_OPTS or MAVEN_OPTS.
> Heap settings should be set through argLine in maven-surefire-plugin.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 1 month
[JBoss JIRA] (ISPN-4307) RHQ JMX plugin failed to get measurement values
by Tomas Sykora (JIRA)
Tomas Sykora created ISPN-4307:
----------------------------------
Summary: RHQ JMX plugin failed to get measurement values
Key: ISPN-4307
URL: https://issues.jboss.org/browse/ISPN-4307
Project: Infinispan
Issue Type: Bug
Components: JMX, reporting and management
Affects Versions: 7.0.0.Alpha4
Reporter: Tomas Sykora
Assignee: William Burns
We are not able to monitor cache statistics due to this error. RHQ agents are reporting:
2014-05-21 05:54:24,958 WARN [MeasurementManager.collector-1] (rhq.core.pc.measurement.MeasurementCollectorRunner)- Failure to collect measurement data for Resource[id=10774, uuid=9f67384f-8f53-4a25-a138-13c54b32c6df, type={Infinispan}Infinispan Cache, key="___default(dist_sync)", name=___default(dist_sync), parent=DefaultCacheManager] - cause: java.lang.NullPointerException:null
2014-05-21 05:55:32,013 ERROR [WorkerThread#1[10.16.23.98:59988]] (rhq.core.pc.measurement.MeasurementManager)- Could not get measurement values
java.lang.NullPointerException
at org.rhq.plugins.jmx.MBeanResourceComponent.getEmsConnection(MBeanResourceComponent.java:574)
at org.infinispan.rhq.CacheComponent.getValues(CacheComponent.java:97)
at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocation.call(ResourceContainer.java:654)
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:679)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 1 month