March 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4066) org.infinispan.query.dsl.Query.getResultSize() gives wrong results when used in remote mode

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4066?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4066: -------------------------------- Labels: 6.3remotequeries 621 630 (was: 6.3remotequeries 621) > org.infinispan.query.dsl.Query.getResultSize() gives wrong results when used in remote mode > ------------------------------------------------------------------------------------------- > > Key: ISPN-4066 > URL: https://issues.jboss.org/browse/ISPN-4066 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 6.3remotequeries, 621, 630 > Fix For: 7.0.0.Alpha2, 7.0.0.Final > > > It works in embedded mode but not in remote mode. No test case yet for this issue, but it was reported by a user on #infinispan irc. -- 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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4023) RESTCertSecurityTest.testSecuredReadWriteOperations random failures

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4023?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4023: -------------------------------- Labels: 630 testsuite_stability (was: testsuite_stability) > RESTCertSecurityTest.testSecuredReadWriteOperations random failures > ------------------------------------------------------------------- > > Key: ISPN-4023 > URL: https://issues.jboss.org/browse/ISPN-4023 > Project: Infinispan > Issue Type: Bug > Components: Security, Server > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Martin Gencur > Labels: 630, testsuite_stability > Fix For: 7.0.0.Alpha2 > > > Frequent NullPointerExceptions in CI, both for testSecuredReadWriteOperations and testSecuredWriteOperations: > {noformat} > java.lang.NullPointerException > at org.infinispan.server.test.rest.security.RESTCertSecurityTest.put(RESTCertSecurityTest.java:175) > at org.infinispan.server.test.rest.security.RESTCertSecurityTest.testSecuredReadWriteOperations(RESTCertSecurityTest.java:134) > {noformat} > http://ci.infinispan.org/viewLog.html?buildId=6586&tab=buildResultsDiv&bu... -- 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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3948) Missing logic to add the store to the configuration for custom stores

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3948?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3948: -------------------------------- Labels: 630 (was: ) > Missing logic to add the store to the configuration for custom stores > --------------------------------------------------------------------- > > Key: ISPN-3948 > URL: https://issues.jboss.org/browse/ISPN-3948 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Kurt Lehrke > Assignee: Dan Berindei > Priority: Critical > Labels: 630 > Fix For: 7.0.0.Alpha2, 7.0.0.Final > > > Looking at the Parser60 class, if you specify a custom store that isn't a singleFileStore or a clusterLoader, the store doesn't get added to the configuration. I found this when I specified my own CacheLoader and it wasn't instantiated like expected. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3990) AtomicMapAPITest.testConcurrentTx fails randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3990?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3990: -------------------------------- Labels: 630 testsuite_stability (was: testsuite_stability) > AtomicMapAPITest.testConcurrentTx fails randomly > ------------------------------------------------ > > Key: ISPN-3990 > URL: https://issues.jboss.org/browse/ISPN-3990 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: 630, testsuite_stability > Fix For: 7.0.0.Alpha2, 7.0.0.Final > > > org.infinispan.atomic.AtomicMapAPITest.testConcurrentTx > http://ci.infinispan.org/viewLog.html?buildId=5946&tab=buildResultsDiv&bu... > --- > org.infinispan.atomic.RepeatableReadAtomicMapAPITest.testConcurrentTx > http://ci.infinispan.org/viewLog.html?buildId=6518&tab=buildResultsDiv&bu... -- 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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

[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, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2014