[JBoss JIRA] (ISPN-4076) RHQ server plugin: bytesRead and bytesWritten stats are broken
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-4076?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-4076:
--------------------------------
Labels: 630 (was: )
> RHQ server plugin: bytesRead and bytesWritten stats are broken
> --------------------------------------------------------------
>
> Key: ISPN-4076
> URL: https://issues.jboss.org/browse/ISPN-4076
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 7.0.0.Alpha1
> Reporter: Tomas Sykora
> Assignee: Tomas Sykora
> Labels: 630
> Fix For: 7.0.0.Alpha2, 7.0.0.Final
>
>
> resource path: subsystem=endpoint
> and underlined connectors provides statistics: bytesRead, bytesWritten.
> However plugin asks for bytes-read and bytes-written which is wrong. Small change in map in MetricsRemappingComponent is needed.
> + We will remove monitoring of those statistics for REST endpoint, as this endpoint does not provide those statistics at all.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-4085) Random failures in StateProviderTest due to race condition
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-4085?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-4085:
--------------------------------
Labels: 630 (was: )
> Random failures in StateProviderTest due to race condition
> ----------------------------------------------------------
>
> Key: ISPN-4085
> URL: https://issues.jboss.org/browse/ISPN-4085
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 7.0.0.Alpha1
> Environment: jgroups.bind_addr = 127.0.0.1
> java.runtime.version = 1.7.0_51-b13
> java.runtime.name =Java(TM) SE Runtime Environment
> java.vm.version = 24.51-b03
> java.vm.vendor = Oracle Corporation
> os.name = Mac OS X
> os.version = 10.9.2
> sun.arch.data.model = 64
> sun.cpu.endian = little
> protocol.stack = null
> infinispan.test.jgroups.protocol = tcp
> infinispan.unsafe.allow_jdk8_chm = true
> java.net.preferIPv4Stack = true
> java.net.preferIPv6Stack = null
> log4.configuration = null
> MAVEN_OPTS = null
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Labels: 630
> Fix For: 7.0.0.Alpha2, 7.0.0.Final
>
>
> In my environment the StateProviderTest .test2() fails sometimes (about 10% of the time) with the following error(s):
> {code}
> Tests run: 4233, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 428.06 sec <<< FAILURE!
> test2(org.infinispan.statetransfer.StateProviderTest) Time elapsed: 0.042 sec <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:92)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertTrue(Assert.java:54)
> at org.infinispan.statetransfer.StateProviderTest.test2(StateProviderTest.java:316)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> {code}
> The reason why is that test2() feeds the StateProvider a ThreadPoolExecutorService to execute a OutboundTransfer task asynchronously and right after forcing a state transfer
> asserts that there is a StateTransfer in progress. Sometimes the executor service manages to execute the task and as a result it clear the ‘transfersByDestination’ map, and thus the test cannot assert that the state transfer is happening
> OTOH, the method test1() never fails because it users a mock executor service which never executes the task, so the state transfer map will always contain the outbound task after initiating the state transfer and thus always visible from outside
> The quick fix is to also use a mock executor test for the test2()
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-4053) WriteSkew not throwing an exception for AtomicMap in REPL and DIST mode
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-4053?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-4053:
--------------------------------
Labels: 621 630 (was: 621)
> WriteSkew not throwing an exception for AtomicMap in REPL and DIST mode
> -----------------------------------------------------------------------
>
> Key: ISPN-4053
> URL: https://issues.jboss.org/browse/ISPN-4053
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.1.Final
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: 621, 630
> Fix For: 7.0.0.Alpha2, 7.0.0.Final
>
>
> The writeSkewCheck flag does not work correctly for AtomicMap. When Infinispan runs in REPEATABLE_READ isolation mode for transactions, the writeSkewCheck flag is enabled, and two concurrent transactions read/write data from the same AtomicMap. The WriteSkewException exception is never thrown when committing either of the transactions.
> Consequently, the data stored in the AtomicMap might be changed by another transaction, and current transaction will not register this change during commit.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3942) HotRod client keep trying recover a connection to a cluster member after shutdown
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3942:
--------------------------------
Labels: 630 clustered hotrod hotrod-java-client (was: clustered hotrod hotrod-java-client)
> HotRod client keep trying recover a connection to a cluster member after shutdown
> ---------------------------------------------------------------------------------
>
> Key: ISPN-3942
> URL: https://issues.jboss.org/browse/ISPN-3942
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 6.0.1.Final, 7.0.0.Alpha1
> Environment: Infinispan server with HotRod client in server-client mode and replicated caches.
> Reporter: Wolf-Dieter Fink
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 630, clustered, hotrod, hotrod-java-client
> Fix For: 7.0.0.Alpha2, 7.0.0.Final
>
> Attachments: hotrod-client.log
>
>
> If a HotRod client is connected to a server cluster and one of the servers do a correct shutdown, the client keep try to reconnect the server after the cluster view has changed.
> There is only a replicated cache configured.
> From the server-logfile the new cluster view is established
> 16:00:22,290 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,shared=udp) ISPN000094: Received new cluster view: [node1/clustered|2] (1) [node1/clustered]
> There is no failure from the application perspective, but there there is always a retry if the RoundRobin return the unavailable server.
> This might end in a performance or failure issue if there is a larger cluster and a part going out of work for some reason.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3338) DistributionManager operations Locate key & Is key local are not working properly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3338?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3338:
--------------------------------
Assignee: Martin Gencur (was: Mircea Markus)
> DistributionManager operations Locate key & Is key local are not working properly
> ---------------------------------------------------------------------------------
>
> Key: ISPN-3338
> URL: https://issues.jboss.org/browse/ISPN-3338
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Environment: Tested localy Fedora16
> Reporter: Tomas Sykora
> Assignee: Martin Gencur
> Labels: 630
> Fix For: 7.0.0.Alpha2, 7.0.0.Final
>
>
> Testing infinispan-rhq-plugin (for InVM).
> DistributionManager operations Locate key & Is key local seem not to working properly. For a nonsense key Locate key operation is returning success with result of a label for cache "home node".
> Is key local operation for nonsense key is returning TRUE which is obviously wrong. This happens even on totally clear, entry-free, cache.
> Operation Could key be affected by a rehash is returning operation success with result false. This is questionable whether it should return failure or not. Again, for nonsense key.
> Please can anyone look at it?
> I don't think this is directly jon/plugin related.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3641) org.infinispan.util.ThreadLocalLeakTest.testCheckThreadLocalLeaks fails with Azul JDK
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3641?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3641:
--------------------------------
Labels: 630 testsuite_stability (was: testsuite_stability)
> org.infinispan.util.ThreadLocalLeakTest.testCheckThreadLocalLeaks fails with Azul JDK
> -------------------------------------------------------------------------------------
>
> Key: ISPN-3641
> URL: https://issues.jboss.org/browse/ISPN-3641
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Beta1, 6.0.0.Beta2, 6.0.0.CR1
> Reporter: Vitalii Chepeliuk
> Assignee: Dan Berindei
> Priority: Minor
> Labels: 630, testsuite_stability
> Fix For: 7.0.0.Alpha2, 7.0.0.Final
>
>
> This is JKD related fail
> Error Message
> java.lang.NoSuchFieldException: referent
> Stacktrace
> java.util.concurrent.ExecutionException: java.lang.NoSuchFieldException: referent
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232)
> at java.util.concurrent.FutureTask.get(FutureTask.java:91)
> at org.infinispan.util.ThreadLocalLeakTest.testCheckThreadLocalLeaks(ThreadLocalLeakTest.java:85)
> 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.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> 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:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.NoSuchFieldException: referent
> at java.lang.Class.getDeclaredField(Class.java:1882)
> at org.infinispan.util.ThreadLocalLeakTest.findThreadLocalLeaks(ThreadLocalLeakTest.java:143)
> at org.infinispan.util.ThreadLocalLeakTest.access$300(ThreadLocalLeakTest.java:35)
> at org.infinispan.util.ThreadLocalLeakTest$1.call(ThreadLocalLeakTest.java:76)
> at org.infinispan.util.ThreadLocalLeakTest$1.call(ThreadLocalLeakTest.java:61)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> ... 1
> Jenkins job with failed test is here
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-62-ispn-testsuite...
--
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
10 years, 5 months