[JBoss JIRA] (ISPN-7590) Invocation idempotence
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-7590?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7590:
----------------------------------
Fix Version/s: 9.4.2.Final
(was: 9.4.1.Final)
> Invocation idempotence
> ----------------------
>
> Key: ISPN-7590
> URL: https://issues.jboss.org/browse/ISPN-7590
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.CR2
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Priority: Major
> Labels: consistency
> Fix For: 9.4.2.Final
>
>
> This is an umbrella JIRA to change the way how we deal with retries after topology change.
> Please link any outstanding issues that refer to incorrect return values of command during topology change.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-8602) ExpirationSingleFileStoreDistListenerFunctionalTest random failures
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8602?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8602:
----------------------------------
Fix Version/s: 9.4.2.Final
(was: 9.4.1.Final)
> ExpirationSingleFileStoreDistListenerFunctionalTest random failures
> -------------------------------------------------------------------
>
> Key: ISPN-8602
> URL: https://issues.jboss.org/browse/ISPN-8602
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.2.0.Beta1
> Reporter: Dan Berindei
> Assignee: William Burns
> Priority: Major
> Labels: testsuite_stability
> Fix For: 9.4.2.Final
>
>
> Various {{ExpirationSingleFileStoreDistListenerFunctionalTest}} tests are failing in master:
> {noformat}
> [ERROR] testExpirationOfStoreWhenDataNotInMemory[null](org.infinispan.expiration.impl.ExpirationSingleFileStoreDistListenerFunctionalTest) Time elapsed: 0.078 s <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<7>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
> at org.infinispan.expiration.impl.ExpirationStoreListenerFunctionalTest.testExpirationOfStoreWhenDataNotInMemory(ExpirationStoreListenerFunctionalTest.java:55)
> {noformat}
> {noformat}
> [ERROR] testSimpleExpirationLifespan[null](org.infinispan.expiration.impl.ExpirationSingleFileStoreDistListenerFunctionalTest) Time elapsed: 0.045 s <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
> at org.infinispan.expiration.impl.ExpirationFunctionalTest.testSimpleExpirationLifespan(ExpirationFunctionalTest.java:78)
> at org.infinispan.expiration.impl.ExpirationStoreListenerFunctionalTest.testSimpleExpirationLifespan(ExpirationStoreListenerFunctionalTest.java:37)
> {noformat}
> {noformat}
> [ERROR] testSimpleExpirationMaxIdle[null](org.infinispan.expiration.impl.ExpirationSingleFileStoreDistListenerFunctionalTest) Time elapsed: 0 s <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
> at org.infinispan.expiration.impl.ExpirationFunctionalTest.testSimpleExpirationMaxIdle(ExpirationFunctionalTest.java:86)
> at org.infinispan.expiration.impl.ExpirationStoreListenerFunctionalTest.testSimpleExpirationMaxIdle(ExpirationStoreListenerFunctionalTest.java:44)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-8576) Add authorization to Distributed Locks
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8576?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8576:
----------------------------------
Fix Version/s: 9.4.2.Final
(was: 9.4.1.Final)
> Add authorization to Distributed Locks
> --------------------------------------
>
> Key: ISPN-8576
> URL: https://issues.jboss.org/browse/ISPN-8576
> Project: Infinispan
> Issue Type: Enhancement
> Components: Clustered Locks, Security
> Reporter: Tristan Tarrant
> Assignee: Katia Aresti
> Priority: Major
> Fix For: 9.4.2.Final
>
>
> DistributedLocks should support authorization.
> Namely only ADMIN permissions should be allowed to defineLocks and WRITE permissions should be allowed to manipulate them.
> When authorization is enabled, the DistributedLockManager should return SecureClusteredLocks which verify that the user has the required privileges.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-8491) Add streaming variant of off heap to not create byte[] instances
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8491?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8491:
----------------------------------
Fix Version/s: 9.4.2.Final
(was: 9.4.1.Final)
> Add streaming variant of off heap to not create byte[] instances
> ----------------------------------------------------------------
>
> Key: ISPN-8491
> URL: https://issues.jboss.org/browse/ISPN-8491
> Project: Infinispan
> Issue Type: Sub-task
> Components: Off Heap
> Reporter: William Burns
> Priority: Major
> Fix For: 9.4.2.Final
>
>
> Currently off heap has to create a byte[] to copy memory from off heap. This is a waste of CPU and memory to do so. Instead we should have a streaming variant Output that the GlobalMarshaller can use that doesn't need all of this unnecessary copying. Unfortunately GlobalMarshaller is currently internally hard coded to require the usage of byte[] so we would have to tweak some code there as well to allow this.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-8513) DistSyncOnePhaseTxStateTransferTest random failures
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8513?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8513:
----------------------------------
Fix Version/s: 9.4.2.Final
(was: 9.4.1.Final)
> DistSyncOnePhaseTxStateTransferTest random failures
> ---------------------------------------------------
>
> Key: ISPN-8513
> URL: https://issues.jboss.org/browse/ISPN-8513
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.2.0.Alpha2
> Reporter: Pedro Ruivo
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 9.4.2.Final
>
> Attachments: DistSyncOnePhaseTxStateTransferTest_pr_wburns_offheap_singlenode2_20171030.log.gz
>
>
> {{DistSyncOnePhaseTxStateTransferTest}} sometimes asserts that the x-site transfer has finished in the remote site too early:
> {noformat}
> 17:34:38,464 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.xsite.statetransfer.DistSyncOnePhaseTxStateTransferTest.testCancelStateTransfer[null, tx=false]
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49) ~[testng-6.8.8.jar:?]
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest$20.assertInCache(BaseStateTransferTest.java:601) ~[test-classes/:?]
> at org.infinispan.xsite.AbstractXSiteTest.assertInSite(AbstractXSiteTest.java:172) ~[test-classes/:?]
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.assertNoStateTransferInReceivingSite(BaseStateTransferTest.java:596) ~[test-classes/:?]
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testCancelStateTransfer(BaseStateTransferTest.java:141) ~[test-classes/:?]
> {noformat}
> In fact, this part of the test seems to let the state transfer finish normally instead of cancelling it, so it could use some logs/comments to explain what's going on.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-8487) Global MBean registration happens too soon
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8487?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8487:
----------------------------------
Fix Version/s: 9.4.2.Final
(was: 9.4.1.Final)
> Global MBean registration happens too soon
> ------------------------------------------
>
> Key: ISPN-8487
> URL: https://issues.jboss.org/browse/ISPN-8487
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Alpha2
> Reporter: Dan Berindei
> Priority: Major
> Fix For: 9.4.2.Final
>
>
> Currently {{DefaultCacheManager}} explicitly starts {{CacheManagerJmxRegistration}} before calling {{ModuleLifecycle#cacheManagerStarting}}, which means MBeans in other modules are not registered in JMX.
> We should start {{CacheManagerJmxRegistration}} only during global component registry start, after the modules have registered their components. If we want to make the cache manager available in JMX before {{DefaultCacheManager.start()}}, we should only register that particular MBean. Conversely, on shutdown, components other than the cache manager should be removed from JMX on {{DefaultCacheManager.stop()}} (as per ISPN-118).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month