[JBoss JIRA] (ISPN-8518) FunctionalDistributionTest.testDistributionFromNonOwner random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8518?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8518:
----------------------------------
Fix Version/s: 9.3.0.Final
(was: 9.2.0.Final)
> FunctionalDistributionTest.testDistributionFromNonOwner random failures
> -----------------------------------------------------------------------
>
> Key: ISPN-8518
> URL: https://issues.jboss.org/browse/ISPN-8518
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.2.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Radim Vansa
> Labels: testsuite_stability
> Fix For: 9.3.0.Final
>
>
> Waiting 100ms is not always enough for the write to be applied on all the owners:
> {noformat}
> java.lang.NullPointerException
> at org.infinispan.functional.FunctionalDistributionTest.lambda$iterate$8(FunctionalDistributionTest.java:97)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1380)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at org.infinispan.functional.FunctionalDistributionTest.iterate(FunctionalDistributionTest.java:98)
> at org.infinispan.functional.FunctionalDistributionTest.doTestDistribution(FunctionalDistributionTest.java:77)
> at org.infinispan.functional.FunctionalDistributionTest.testDistributionFromNonOwner(FunctionalDistributionTest.java:66)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[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.3.0.Final
(was: 9.2.0.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
> Labels: testsuite_stability
> Fix For: 9.3.0.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.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-8494) Clear is leaking transaction with Batching
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8494?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8494:
----------------------------------
Fix Version/s: 9.3.0.Final
(was: 9.2.0.Final)
> Clear is leaking transaction with Batching
> ------------------------------------------
>
> Key: ISPN-8494
> URL: https://issues.jboss.org/browse/ISPN-8494
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.3.0.Final
>
>
> When batching is enabled, the clear() tries to suspend the running transaction but it ends leaking the internal transaction used in the batch.
> {code:java}
> public void testClearInBatch() {
> Cache<String, String> cache = createCache("testClearInBatch");
> cache.put("k2", "value2");
> cache.startBatch();
> cache.clear();
> cache.put("k1", "value1");
> cache.endBatch(true);
> // the tx is leaked and it tries to execute the get() against a committed transaction.
> AssertJUnit.assertEquals(null, cache.get("k2"));
> AssertJUnit.assertEquals("value1", cache.get("k1"));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[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.3.0.Final
(was: 9.2.0.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
> Fix For: 9.3.0.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.5.0#75005)
7 years, 10 months
[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.3.0.Final
(was: 9.2.0.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
> Fix For: 9.3.0.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.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-8460) Administration console - create user friendly configuration validation errors
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8460?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8460:
----------------------------------
Fix Version/s: 9.3.0.Final
(was: 9.2.0.Final)
> Administration console - create user friendly configuration validation errors
> -----------------------------------------------------------------------------
>
> Key: ISPN-8460
> URL: https://issues.jboss.org/browse/ISPN-8460
> Project: Infinispan
> Issue Type: Enhancement
> Components: Console
> Affects Versions: 9.1.1.Final, 9.2.0.Alpha2
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Fix For: 9.3.0.Final
>
> Attachments: Screen Shot 2017-11-01 at 6.08.57 AM.png
>
>
> While in ISPN-7262 we have ensured that all configurations are indeed checked for validity before being saved we have not provided user-friendly error descriptions. Current errors in place, although informational and correct, look scary and verbose. We should parse the configuration validation errors and display them in a more user friendly approach.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-8453) Commit should fail if cache is in degraded mode
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8453?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8453:
----------------------------------
Fix Version/s: 9.3.0.Final
(was: 9.2.0.Final)
> Commit should fail if cache is in degraded mode
> -----------------------------------------------
>
> Key: ISPN-8453
> URL: https://issues.jboss.org/browse/ISPN-8453
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.1.9.Final, 8.2.8.Final, 9.1.2.Final, 9.2.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.3.0.Final
>
>
> When the originator receives a {{CacheNotFoundResponse}} and the cache is in degraded mode, the transaction is marked as partially completed, but the commit completes successfully.
> I believe that is not correct, because the originator could crash after the commit but before the merge, and in that case the transaction will not be applied on all the owners. The transaction manager will ignore any commit exception in {{NON_XA}}/{{useSynchronization}} mode, but at least in {{FULL_XA}}/{{NON_DURABLE_XA}} mode we can signal to the user that the transaction may be lost.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months