[JBoss JIRA] (ISPN-10289) SingleTargetRequest may invoke the response collector twice for same view
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10289?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10289:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/7026
> SingleTargetRequest may invoke the response collector twice for same view
> -------------------------------------------------------------------------
>
> Key: ISPN-10289
> URL: https://issues.jboss.org/browse/ISPN-10289
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 10.0.0.Beta3, 9.4.14.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta4
>
>
> {{SingleTargetRequest.onNewView()}} is sometimes invoked twice:
> * From {{JGroupsTransport.invokeCommand()}}, in the thread that is sending the request
> * From {{JGroupsTransport.receiveClusterView()}}, in the thread processing the view change
> Because of insufficient synchronization, both {{onNewView()}} invocations may trigger a call to {{ResponseCollector.addResponse()}}, and the collector may not deal with the extra call properly.
> For example, the bridge response collectors used by {{ControlledRpcManager}} do not allow duplicate responses for the same target, and this causes random failures in {{GetAllCommandNodeCrashTest}}:
> {noformat}
> 12:44:56.270 [ERROR] commands.GetAllCommandNodeCrashTest(org.infinispan.commands.GetAllCommandNodeCrashTest) Time elapsed: 0.144 s <<< FAILURE!
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49)
> at org.infinispan.util.ControlledRpcManager$BlockedResponseMap.receive(ControlledRpcManager.java:701)
> at org.infinispan.util.ControlledRpcManager$SentRequest.receiveAll(ControlledRpcManager.java:601)
> at org.infinispan.commands.GetAllCommandNodeCrashTest.test(GetAllCommandNodeCrashTest.java:66)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (ISPN-10289) SingleTargetRequest may invoke the response collector twice for same view
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10289?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10289:
--------------------------------
Status: Open (was: New)
> SingleTargetRequest may invoke the response collector twice for same view
> -------------------------------------------------------------------------
>
> Key: ISPN-10289
> URL: https://issues.jboss.org/browse/ISPN-10289
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 10.0.0.Beta3, 9.4.14.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta4
>
>
> {{SingleTargetRequest.onNewView()}} is sometimes invoked twice:
> * From {{JGroupsTransport.invokeCommand()}}, in the thread that is sending the request
> * From {{JGroupsTransport.receiveClusterView()}}, in the thread processing the view change
> Because of insufficient synchronization, both {{onNewView()}} invocations may trigger a call to {{ResponseCollector.addResponse()}}, and the collector may not deal with the extra call properly.
> For example, the bridge response collectors used by {{ControlledRpcManager}} do not allow duplicate responses for the same target, and this causes random failures in {{GetAllCommandNodeCrashTest}}:
> {noformat}
> 12:44:56.270 [ERROR] commands.GetAllCommandNodeCrashTest(org.infinispan.commands.GetAllCommandNodeCrashTest) Time elapsed: 0.144 s <<< FAILURE!
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49)
> at org.infinispan.util.ControlledRpcManager$BlockedResponseMap.receive(ControlledRpcManager.java:701)
> at org.infinispan.util.ControlledRpcManager$SentRequest.receiveAll(ControlledRpcManager.java:601)
> at org.infinispan.commands.GetAllCommandNodeCrashTest.test(GetAllCommandNodeCrashTest.java:66)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (ISPN-10289) SingleTargetRequest may invoke the response collector twice for same view
by Dan Berindei (Jira)
Dan Berindei created ISPN-10289:
-----------------------------------
Summary: SingleTargetRequest may invoke the response collector twice for same view
Key: ISPN-10289
URL: https://issues.jboss.org/browse/ISPN-10289
Project: Infinispan
Issue Type: Bug
Components: Core, Test Suite - Core
Affects Versions: 9.4.14.Final, 10.0.0.Beta3
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 10.0.0.Beta4
{{SingleTargetRequest.onNewView()}} is sometimes invoked twice:
* From {{JGroupsTransport.invokeCommand()}}, in the thread that is sending the request
* From {{JGroupsTransport.receiveClusterView()}}, in the thread processing the view change
Because of insufficient synchronization, both {{onNewView()}} invocations may trigger a call to {{ResponseCollector.addResponse()}}, and the collector may not deal with the extra call properly.
For example, the bridge response collectors used by {{ControlledRpcManager}} do not allow duplicate responses for the same target, and this causes random failures in {{GetAllCommandNodeCrashTest}}:
{noformat}
12:44:56.270 [ERROR] commands.GetAllCommandNodeCrashTest(org.infinispan.commands.GetAllCommandNodeCrashTest) Time elapsed: 0.144 s <<< FAILURE!
java.lang.AssertionError:
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41)
at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49)
at org.infinispan.util.ControlledRpcManager$BlockedResponseMap.receive(ControlledRpcManager.java:701)
at org.infinispan.util.ControlledRpcManager$SentRequest.receiveAll(ControlledRpcManager.java:601)
at org.infinispan.commands.GetAllCommandNodeCrashTest.test(GetAllCommandNodeCrashTest.java:66)
{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (ISPN-10288) Remove the pre-iterator rolling upgrade migration code
by Tristan Tarrant (Jira)
Tristan Tarrant created ISPN-10288:
--------------------------------------
Summary: Remove the pre-iterator rolling upgrade migration code
Key: ISPN-10288
URL: https://issues.jboss.org/browse/ISPN-10288
Project: Infinispan
Issue Type: Sub-task
Components: Hot Rod
Reporter: Tristan Tarrant
Assignee: Gustavo Fernandes
Fix For: 10.0.0.Final
Remove all logic related to dumping keys into a single entry (source/target migrators and CLI dump keys)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (HRJS-79) Registering listener with undefined listenerId does nothing
by Anna Manukyan (Jira)
[ https://issues.jboss.org/browse/HRJS-79?page=com.atlassian.jira.plugin.sy... ]
Anna Manukyan updated HRJS-79:
------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/js-client/pull/42
> Registering listener with undefined listenerId does nothing
> -----------------------------------------------------------
>
> Key: HRJS-79
> URL: https://issues.jboss.org/browse/HRJS-79
> Project: Infinispan Javascript client
> Issue Type: Bug
> Reporter: Anna Manukyan
> Assignee: Anna Manukyan
> Priority: Major
>
> I was trying the following scenario: the case when the listenerId is passed while adding new listeners.
> I was creating 3 listeners for create,modify and remove events. While adding listeners for modify and remove events I was passing the listenerId, but for modify event the listenerId was some nonexistent string.
> I was curious what will happen. From the functional side nothing happened, so the modify event is not fired and from the logs I can see the following:
> {code}
> [2018-09-25T22:24:55.845] [DEBUG] client - Invoke addListener(msgId=464,event=create,listenerId=listener_465,opts=undefined) remotely
> [2018-09-25T22:24:55.845] [TRACE] encoder - Encode operation with topology id 0
> [2018-09-25T22:24:55.846] [TRACE] listener - Create listener emitter for connection 127.0.0.1:11222@conn_15 and listener with listenerId=listener_465
> [2018-09-25T22:24:55.846] [TRACE] io_7 - Write buffer(msgId=464) to 127.0.0.1:11222@conn_15: A0D0031D2500000300010D00010D000C6C697374656E65725F343635000000000F
> [2018-09-25T22:24:55.847] [TRACE] decoder - Read header(msgId=464): opCode=38, status=0, hasNewTopology=0
> [2018-09-25T22:24:55.847] [TRACE] decoder - Call decode for request(msgId=464)
> [2018-09-25T22:24:55.847] [TRACE] io_7_conn_15 - Complete success for request(msgId=464) with true
> [2018-09-25T22:24:55.847] [TRACE] io_7_conn_15 - After decoding request(msgId=464), buffer size is 6, and offset 6
> [2018-09-25T22:24:55.847] [DEBUG] client - Invoke addListener(msgId=466,event=modify,opts={"listenerId":"blblbl"}) locally
> {color:red}[2018-09-25T22:24:55.848] [TRACE] listener - Create listener emitter for connection undefined and listener with listenerId=blblbl{color}
> [2018-09-25T22:24:55.848] [DEBUG] client - Invoke addListener(msgId=467,event=remove,opts={"listenerId":"listener_465"}) locally
> {code}
> So the first line creates "create" event listener remotely. For the "modify" and "delete" events the "addLocalListener()" function is called. I am worried about the line marked in red, there the connection is passed as {color:red}undefined{color}.
> I have found out that the connection parameter is not passed to protocol's addListener function when it is called from addLocalListener() function, but couldn't find a way to fix that.
> Should it be that way?
> I know that this kind of scenario is hardly possible but just in case the developer did some mistake, perhaps he/she may spend much time on finding why the event is not fired.
> The code for generating this log is given here:
> {code}
> ...code in the test...
> it('fails when trying to attach to non-existent listener', function(done) {
> client.then(function (client) {
> var clientAddListenerCreate = client.addListener(
> 'create', function(key) { console.log('[Event] Created key: ' + key); });
> var clientAddListeners = clientAddListenerCreate.then(
> function(listenerId) {
> // Multiple callbacks can be associated with a single client-side listener.
> // This is achieved by registering listeners with the same listener id
> // as shown in the example below.
> var clientAddListenerModify = client.addListener(
> 'modify', function(key) { console.log('[Event] Modified key: ' + key); },
> {listenerId: 'blblbl'});
> var clientAddListenerRemove = client.addListener(
> 'remove', function(key) { console.log('[Event] Removed key: ' + key); },
> {listenerId: listenerId});
> return Promise.all([clientAddListenerModify, clientAddListenerRemove]);
> });
> var clientCreate = clientAddListeners.then(
> function() { return client.putIfAbsent('eventful', 'v0'); });
> var clientModify = clientCreate.then(
> function() { return client.replace('eventful', 'v1'); });
> var clientRemove = clientModify.then(
> function() { return client.remove('eventful'); });
> var clientRemoveListener =
> Promise.all([clientAddListenerCreate, clientRemove]).then(
> function(values) {
> var listenerId = values[0];
> return client.removeListener(listenerId);
> });
> }).catch(t.failed(done)).finally(done);
> });
> ........
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (ISPN-9816) Handle non segmented container/store for publisher more efficiently
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9816?page=com.atlassian.jira.plugin.... ]
Will Burns commented on ISPN-9816:
----------------------------------
I will have to investigate further if this change is needed; I have to admit I am surprised the perf difference isn't bigger between old distributed streams and distributed publisher when not segmented.
> Handle non segmented container/store for publisher more efficiently
> -------------------------------------------------------------------
>
> Key: ISPN-9816
> URL: https://issues.jboss.org/browse/ISPN-9816
> Project: Infinispan
> Issue Type: Sub-task
> Components: Publisher
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> The new Publisher is designed to take into account segmented data container and segmented stores. However if a store/data container is not segmented, the handling can cause performance issues, although it would still behave better memory and rehash based. The tradeoff is probably fine for data container, however stores performance drop would be massive. We need to process all segments in at least the non segmented store case to retain our old performance.
> To clarify this would require changes in the LocalPublisherManagerImpl class when invoking `CacheCollection.localPublisher(int)`, we would need to instead invoke `CacheCollection.localPublisher(IntSet)` so that we only have to iterate over the store once instead of IntSet.size times.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (ISPN-10286) Segmented Store can get stuck with bulk write
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-10286?page=com.atlassian.jira.plugin... ]
Will Burns updated ISPN-10286:
------------------------------
Status: Open (was: New)
> Segmented Store can get stuck with bulk write
> ---------------------------------------------
>
> Key: ISPN-10286
> URL: https://issues.jboss.org/browse/ISPN-10286
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 10.0.0.Alpha3
> Reporter: Will Burns
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> The code was refactored in ComposedSegmentedLoadWriteStore to be more non blocking friendly. Unfortunately due to how groupBy and flatMap interact it is possible for the bulkUpdate to never complete.
> FlatMap by default sets a parallelism level of 128. this means it will request 128 groups from groupBy, but unfortunately if there are more than 128 groups, it will never complete as groupBy must publish all groups before a single one can complete. Thus any time we use flatMap after a groupBy we must either set the parallelism level to Integer.MAX_VALUE or to an explicit value if we know how many groups at max there will be.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (ISPN-10286) Segmented Store can get stuck with bulk write
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-10286?page=com.atlassian.jira.plugin... ]
Will Burns updated ISPN-10286:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/7024
> Segmented Store can get stuck with bulk write
> ---------------------------------------------
>
> Key: ISPN-10286
> URL: https://issues.jboss.org/browse/ISPN-10286
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 10.0.0.Alpha3
> Reporter: Will Burns
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> The code was refactored in ComposedSegmentedLoadWriteStore to be more non blocking friendly. Unfortunately due to how groupBy and flatMap interact it is possible for the bulkUpdate to never complete.
> FlatMap by default sets a parallelism level of 128. this means it will request 128 groups from groupBy, but unfortunately if there are more than 128 groups, it will never complete as groupBy must publish all groups before a single one can complete. Thus any time we use flatMap after a groupBy we must either set the parallelism level to Integer.MAX_VALUE or to an explicit value if we know how many groups at max there will be.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months