[JBoss JIRA] (ISPN-4368) StateTransferOverwriteTest random failures
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4368?page=com.atlassian.jira.plugin.... ]
Work on ISPN-4368 started by William Burns.
> StateTransferOverwriteTest random failures
> ------------------------------------------
>
> Key: ISPN-4368
> URL: https://issues.jboss.org/browse/ISPN-4368
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: William Burns
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta1
>
>
> {{testStateTransferInBetweenPrepareCommitWithPutCreate}} sometimes fails because the state transfer doesn't finish in time:
> {noformat}
> java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node NodeBN-23267, current topology is CacheTopology{id=6, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeBM-52725, NodeBN-23267]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeBM-52725, NodeBN-23267]}, unionCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeBM-52725, NodeBN-23267]}}
> at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:214)
> at org.infinispan.distribution.rehash.BaseTxStateTransferOverwriteTest.doStateTransferInBetweenPrepareCommit(BaseTxStateTransferOverwriteTest.java:265)
> at org.infinispan.distribution.rehash.BaseTxStateTransferOverwriteTest.testStateTransferInBetweenPrepareCommitWithPutCreate(BaseTxStateTransferOverwriteTest.java:94)
> {noformat}
> The problem seems to be that the test intends to block the {{PUT_CREATE}} command on the primary owner of the test key, but it sometimes also blocks the state transfer put for the {{placeholder}} key - depending on which node was the backup owner of the {{placeholder}} key.
> The purpose of the {{placeholder}} key is also not very clear, we should add a comment how we expect the presence of another entry to interact with the tx / operation in progress.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (ISPN-4370) CacheNotifierImplInitialTransferDistTest random failures
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4370?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4370:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2617
> CacheNotifierImplInitialTransferDistTest random failures
> --------------------------------------------------------
>
> Key: ISPN-4370
> URL: https://issues.jboss.org/browse/ISPN-4370
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: William Burns
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta1
>
> Attachments: CacheNotifierImplInitialTransferDistTest_t_ISPN-4118_20140609.log.gz
>
>
> Random failures in {{testModificationAfterIterationBeganAndSegmentNotCompleteValueOwnerClustered}} and {{testRemoveAfterIterationBeganAndSegmentNotCompleteValueOwnerClustered}}.
> {noformat}
> java.lang.AssertionError: There was no matching create event for key key-1 expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testIterationBeganAndSegmentNotComplete(CacheNotifierImplInitialTransferDistTest.java:542)
> at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testRemoveAfterIterationBeganAndSegmentNotCompleteValueOwnerClustered(CacheNotifierImplInitialTransferDistTest.java:655)
> {noformat}
> {noformat}
> java.lang.AssertionError: There was no matching create event for key key-1 expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testIterationBeganAndSegmentNotComplete(CacheNotifierImplInitialTransferDistTest.java:542)
> at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testRemoveAfterIterationBeganAndSegmentNotCompleteValueOwnerClustered(CacheNotifierImplInitialTransferDistTest.java:655)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (ISPN-4370) CacheNotifierImplInitialTransferDistTest random failures
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4370?page=com.atlassian.jira.plugin.... ]
Work on ISPN-4370 started by William Burns.
> CacheNotifierImplInitialTransferDistTest random failures
> --------------------------------------------------------
>
> Key: ISPN-4370
> URL: https://issues.jboss.org/browse/ISPN-4370
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: William Burns
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta1
>
> Attachments: CacheNotifierImplInitialTransferDistTest_t_ISPN-4118_20140609.log.gz
>
>
> Random failures in {{testModificationAfterIterationBeganAndSegmentNotCompleteValueOwnerClustered}} and {{testRemoveAfterIterationBeganAndSegmentNotCompleteValueOwnerClustered}}.
> {noformat}
> java.lang.AssertionError: There was no matching create event for key key-1 expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testIterationBeganAndSegmentNotComplete(CacheNotifierImplInitialTransferDistTest.java:542)
> at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testRemoveAfterIterationBeganAndSegmentNotCompleteValueOwnerClustered(CacheNotifierImplInitialTransferDistTest.java:655)
> {noformat}
> {noformat}
> java.lang.AssertionError: There was no matching create event for key key-1 expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testIterationBeganAndSegmentNotComplete(CacheNotifierImplInitialTransferDistTest.java:542)
> at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testRemoveAfterIterationBeganAndSegmentNotCompleteValueOwnerClustered(CacheNotifierImplInitialTransferDistTest.java:655)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (ISPN-4366) RHQ JMX plugin provides unstable availability check with extensive deployments
by Tomas Sykora (JIRA)
[ https://issues.jboss.org/browse/ISPN-4366?page=com.atlassian.jira.plugin.... ]
Tomas Sykora commented on ISPN-4366:
------------------------------------
Hi Will, exactly. I confirm, our deployments in the testing environment are stable.... and was stable through the whole weekend -- when we use the newest RHQ JMX plug-in of version 4.11 which contains above-mentioned mc4j libs of version 1.3.5.
> RHQ JMX plugin provides unstable availability check with extensive deployments
> ------------------------------------------------------------------------------
>
> Key: ISPN-4366
> URL: https://issues.jboss.org/browse/ISPN-4366
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 7.0.0.Alpha4
> Reporter: Tomas Sykora
> Assignee: William Burns
> Labels: 63gablocker, rhq
>
> Availability check was greatly improved by changes introduced in https://issues.jboss.org/browse/ISPN-4236 and https://issues.jboss.org/browse/ISPN-4235.
> This works pretty well in case of one deployment of an embedded application on one application server, which is monitored by an agent.
> However, when we try to monitor more deployments by the same agent (app servers, switched ports, each one with its own deployment), the process of availability checking is unstable.
> Cache managers / caches... are reported repeatedly UP and DOWN, UP and DOWN. See linked bugzilla with attached screenshots depicting this issue.
> I suspect higher number of MBeans to cause this problem.
> When we deploy on 2 servers, one of them for example was able to stabilize availability check after 2 hours and then, it stays UP.
> During deployment in 2xdomain mode = 4 servers, availability check "is skipping, jumping" UP, DOWN, UP, DOWN... etc. again, see screenshots in BZ.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (ISPN-4366) RHQ JMX plugin provides unstable availability check with extensive deployments
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4366?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-4366:
-------------------------------------
I believe when I was working [~tsykora] on Friday, I had him upgrade the rhq-jmx plugin distributed by rhq to the newer version. The newer version has a new mc4j jar that I identified an issue that the RHQ guys had fixed. I believe with the new jar everything was alright, but I would need [~tsykora] to confirm it is still working fine today or not. If not I will need to figure out a way to have a larger deployment to test this on myself.
> RHQ JMX plugin provides unstable availability check with extensive deployments
> ------------------------------------------------------------------------------
>
> Key: ISPN-4366
> URL: https://issues.jboss.org/browse/ISPN-4366
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 7.0.0.Alpha4
> Reporter: Tomas Sykora
> Assignee: William Burns
> Labels: 63gablocker, rhq
>
> Availability check was greatly improved by changes introduced in https://issues.jboss.org/browse/ISPN-4236 and https://issues.jboss.org/browse/ISPN-4235.
> This works pretty well in case of one deployment of an embedded application on one application server, which is monitored by an agent.
> However, when we try to monitor more deployments by the same agent (app servers, switched ports, each one with its own deployment), the process of availability checking is unstable.
> Cache managers / caches... are reported repeatedly UP and DOWN, UP and DOWN. See linked bugzilla with attached screenshots depicting this issue.
> I suspect higher number of MBeans to cause this problem.
> When we deploy on 2 servers, one of them for example was able to stabilize availability check after 2 hours and then, it stays UP.
> During deployment in 2xdomain mode = 4 servers, availability check "is skipping, jumping" UP, DOWN, UP, DOWN... etc. again, see screenshots in BZ.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (ISPN-4366) RHQ JMX plugin provides unstable availability check with extensive deployments
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-4366?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-4366:
--------------------------------
Labels: 63gablocker rhq (was: rhq)
> RHQ JMX plugin provides unstable availability check with extensive deployments
> ------------------------------------------------------------------------------
>
> Key: ISPN-4366
> URL: https://issues.jboss.org/browse/ISPN-4366
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 7.0.0.Alpha4
> Reporter: Tomas Sykora
> Assignee: William Burns
> Labels: 63gablocker, rhq
>
> Availability check was greatly improved by changes introduced in https://issues.jboss.org/browse/ISPN-4236 and https://issues.jboss.org/browse/ISPN-4235.
> This works pretty well in case of one deployment of an embedded application on one application server, which is monitored by an agent.
> However, when we try to monitor more deployments by the same agent (app servers, switched ports, each one with its own deployment), the process of availability checking is unstable.
> Cache managers / caches... are reported repeatedly UP and DOWN, UP and DOWN. See linked bugzilla with attached screenshots depicting this issue.
> I suspect higher number of MBeans to cause this problem.
> When we deploy on 2 servers, one of them for example was able to stabilize availability check after 2 hours and then, it stays UP.
> During deployment in 2xdomain mode = 4 servers, availability check "is skipping, jumping" UP, DOWN, UP, DOWN... etc. again, see screenshots in BZ.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (ISPN-4310) StateResponse chunk with lastChunk=true from cancelled ST stops receiving data in next ST
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-4310?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-4310:
--------------------------------
Labels: 63gablocker (was: )
> 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: 6.0.2.Final, 7.0.0.Alpha4
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 63gablocker
>
> 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)
11 years, 10 months
[JBoss JIRA] (ISPN-4311) Security tests, Windows, access denied (java.security.SecurityPermission setPolicy)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-4311?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-4311:
--------------------------------
Labels: 63gablocker testsuite_stability (was: testsuite_stability)
> 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
> Labels: 63gablocker, testsuite_stability
>
> 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)
11 years, 10 months
[JBoss JIRA] (ISPN-4247) JPA cachestore fails with Oracle12c and PostgreadPlus 9
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-4247?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-4247:
-------------------------------------
[~rvansa] [~NadirX] do you see any issues with upgrading to hibernate 4.3.x for this? We can then ask for a hibenrate backport.
> JPA cachestore fails with Oracle12c and PostgreadPlus 9
> -------------------------------------------------------
>
> Key: ISPN-4247
> URL: https://issues.jboss.org/browse/ISPN-4247
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Vojtech Juranek
> Assignee: Dan Berindei
> Labels: 63gablocker
> Fix For: 7.0.0.Alpha4, 7.0.0.Final
>
>
> JPA cache store fails on Oracle12c and PostgreadPlus 9 as Hibernate is not able to determine the dialect to be used:
> {noformat}
> [java] Caused by: org.hibernate.HibernateException: Unable to determine Dialect to use [name=Oracle, majorVersion=12]; user must register resolver or explicitly set 'hibernate.dialect'
> {noformat}
> resp.
> {noformat}
> [java] Caused by: org.hibernate.HibernateException: Unable to determine Dialect to use [name=EnterpriseDB, majorVersion=9]; user must register resolver or explicitly set 'hibernate.dialect'
> {noformat}
> To fix it, HIbernate upgrade is needed. PotgresPlus is fixed in 4.3.0.Beta4 (tracking JIRA is [HHH-8349|https://hibernate.atlassian.net/browse/HHH-8349]), Oracle12c is fixed in Hibernate 5.0.0 (tracking JIRA is [HHH-9044|https://hibernate.atlassian.net/browse/HHH-9044])
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months