[JBoss JIRA] (ISPN-5849) AutoCloseable return from adding listeners can be clunky to use
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5849?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-5849:
------------------------------
Fix Version/s: 9.0.0.CR3
(was: 9.0.0.CR2)
> AutoCloseable return from adding listeners can be clunky to use
> ---------------------------------------------------------------
>
> Key: ISPN-5849
> URL: https://issues.jboss.org/browse/ISPN-5849
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.CR3
>
>
> On one side, to use it as a try-with-resource, you need to declare it right in the {{try()}};
> {code}
> try(AutoCloseable handler = writeOnlyMap.listeners().onWrite(written ->
> System.out.printf("Written (via onWrite): %s%n", written.get()))) {
> Map<String, String> entries = new HashMap<>();
> entries.put("key1", "value1");
> entries.put("key2", "value2");
> writeOnlyMap.evalMany(entries, (v, writeView) -> writeView.set(v))
> .get(); // Wait for completable future
> }
> {code}
> So it's usability is mostly designed for unit tests since listeners tend to be set and removed at a later stage. IOW, listeners are not generally a short-lived object.
> The other aspect that is clunky to use is the fact that AutoCloseable's close() throws Exception, which again makes it ackward to use for example if lambdas.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-6103) LocalKeyAffinityTest.testFilteredRemoveServers random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6103?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6103:
------------------------------
Fix Version/s: 9.0.0.CR3
(was: 9.0.0.CR2)
> LocalKeyAffinityTest.testFilteredRemoveServers random failures
> --------------------------------------------------------------
>
> Key: ISPN-6103
> URL: https://issues.jboss.org/browse/ISPN-6103
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.0.0.CR3
>
>
> {noformat}
> 19:04:00,884 ERROR (testng-LocalKeyAffinityServiceTest:) [UnitTestTestNGListener] Test testFilteredRemoveServers(org.infinispan.affinity.impl.LocalKeyAffinityServiceTest) failed.
> 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.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:109) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:91) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:67) ~[test-classes/:?]
> at org.infinispan.affinity.impl.BaseKeyAffinityServiceTest.assertEventualFullCapacity(BaseKeyAffinityServiceTest.java:77) ~[test-classes/:?]
> at org.infinispan.affinity.impl.BaseFilterKeyAffinityServiceTest.assertUnaffected(BaseFilterKeyAffinityServiceTest.java:86) ~[test-classes/:?]
> at org.infinispan.affinity.impl.BaseFilterKeyAffinityServiceTest.testRemoveServers(BaseFilterKeyAffinityServiceTest.java:60) ~[test-classes/:?]
> at org.infinispan.affinity.impl.LocalKeyAffinityServiceTest.testFilteredRemoveServers(LocalKeyAffinityServiceTest.java:47) ~[test-classes/:?]
> {noformat}
> Counting the number of generated keys in the log, it seems to be correct, need better logging to determine if there are too few or too many keys in the queue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-6094) Use security actions to read system properties for configuration
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6094?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6094:
------------------------------
Fix Version/s: 9.0.0.CR3
(was: 9.0.0.CR2)
> Use security actions to read system properties for configuration
> ----------------------------------------------------------------
>
> Key: ISPN-6094
> URL: https://issues.jboss.org/browse/ISPN-6094
> Project: Infinispan
> Issue Type: Task
> Components: Core, Embedded Querying
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.CR3
>
>
> Infinispan uses system properties for out-of-band settings that weren't deemed important enough to have a proper configuration attribute:
> * infinispan.arrays.debug
> * infinispan.unsafe.force_multicast
> * infinispan.compat (obsolete?)
> * infinispan.debugDependencies
> * infinispan.stagger.delay (introduced with ISPN-825)
> * org.infinispan.query.indexmanager.LockAcquiringBackend.MAX_QUEUE_SIZE
> We should use a {{SecurityActions}} class to access these properties instead of {{Boolean.getBoolean()}} and {{Integer.getInteger()}}. We should also document these system properties, and evaluate moving them to the proper configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-6041) Remote Listeners: Client event reader thread reports EOF as error
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6041?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6041:
------------------------------
Fix Version/s: 9.0.0.CR3
(was: 9.0.0.CR2)
> Remote Listeners: Client event reader thread reports EOF as error
> -----------------------------------------------------------------
>
> Key: ISPN-6041
> URL: https://issues.jboss.org/browse/ISPN-6041
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Priority: Minor
> Fix For: 9.0.0.CR3
>
>
> {noformat}
> 14:02:14,904 ERROR (Client-Listener-87aa07aee56d43e1) [ClientListenerNotifier] ISPN004043: Unrecoverable error reading event from server /127.0.0.1:15530, exiting event reader thread
> org.infinispan.client.hotrod.exceptions.TransportException: End of stream reached!
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:198)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:305)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:147)
> at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:252)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-6040) FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6040?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6040:
------------------------------
Fix Version/s: 9.0.0.CR3
(was: 9.0.0.CR2)
> FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures
> -------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6040
> URL: https://issues.jboss.org/browse/ISPN-6040
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 9.0.0.CR3
>
>
> Similar to ISPN-6039, the test failure is caused by the state transfer put happening after the test's remove.
> In this case, the command types are different, so blocking works correctly. However, when the {{ReadWriteKeyValueCommand}} executes before the state transfer put, it doesn't find any value, and it doesn't commit the entry. This means the key is not added to {{CommitManager}}'s {{tracker}} map, and the state transfer put is allowed to write to it - effectively undoing the remove.
> {noformat}
> java.lang.AssertionError: expected:<null> but was:<v0>
> 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:88)
> at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:194)
> at org.infinispan.functional.distribution.rehash.FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove(FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-6039) NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6039?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6039:
------------------------------
Fix Version/s: 9.0.0.CR3
(was: 9.0.0.CR2)
> NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures
> ---------------------------------------------------------------------------------------------------
>
> Key: ISPN-6039
> URL: https://issues.jboss.org/browse/ISPN-6039
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 9.0.0.CR3
>
>
> The problem is that the state transfer write can happen after we started the regular put, and is blocked by the {{BlockingInterceptor}}. The test then unblocks the state transfer put, but never unblocks the regular put, which eventually times out.
> {noformat}
> java.util.concurrent.TimeoutException
> at java.util.concurrent.FutureTask.get(FutureTask.java:205)
> at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:193)
> at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:75)
> {noformat}
> The test should be more explicit about the state transfer put - ideally it should have 2 cases, one with the state transfer put happening before the regular put, and one after.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month