May 2019 - infinispan-issues - Jboss List Archives

[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: Open (was: New) > 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 > 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)

4 years, 11 months

1
0
0 / 0

[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... ] Work on HRJS-79 started by Anna Manukyan. ----------------------------------------- > 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)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (HRJS-78) Adding listener with unknown type succeeds

by Anna Manukyan (Jira)

[ https://issues.jboss.org/browse/HRJS-78?page=com.atlassian.jira.plugin.sy... ] Anna Manukyan updated HRJS-78: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/js-client/pull/41 > Adding listener with unknown type succeeds > ------------------------------------------ > > Key: HRJS-78 > URL: https://issues.jboss.org/browse/HRJS-78 > Project: Infinispan Javascript client > Issue Type: Bug > Reporter: Anna Manukyan > Assignee: Anna Manukyan > Priority: Major > > When adding a new listener with unknown event type, nothing happens. From the logs I can see that the event was added successfully. See the logs below: > {code} > [2018-09-25T22:24:55.824] [DEBUG] client - Invoke addListener(msgId=460,event=barev,listenerId=listener_461,opts=undefined) remotely > [2018-09-25T22:24:55.824] [TRACE] encoder - Encode operation with topology id 0 > [2018-09-25T22:24:55.825] [TRACE] listener - Create listener emitter for connection 127.0.0.1:11222@conn_15 and listener with listenerId=listener_461 > [2018-09-25T22:24:55.825] [TRACE] io_7 - Write buffer(msgId=460) to 127.0.0.1:11222@conn_15: A0CC031D2500000300010D00010D000C6C697374656E65725F343631000000000F > [2018-09-25T22:24:55.827] [TRACE] decoder - Read header(msgId=460): opCode=38, status=0, hasNewTopology=0 > [2018-09-25T22:24:55.827] [TRACE] decoder - Call decode for request(msgId=460) > [2018-09-25T22:24:55.827] [TRACE] io_7_conn_15 - Complete success for request(msgId=460) with true > [2018-09-25T22:24:55.827] [TRACE] io_7_conn_15 - After decoding request(msgId=460), buffer size is 6, and offset 6 > {code} > The code for this logs is given here: > {code} > ... code from spec... > it('fails when wrong event name is passed', function(done) { > client.then(t.on('barev', t.expectEvent('wrongNameCreate', done, true, 'value'))) > .then(t.assert(t.putIfAbsent('wrongNameCreate', 'value'), t.toBeTruthy)) > .catch(t.failed(done)).finally(done); > }); > ... > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9722) Perform all CacheStore operations on a separate thread

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9722?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-9722: ------------------------------------ > We shouldn't ever be hitting the CallerRunsPolicy. The thread pool should have a large amount of threads and a large queue. We don't ever want to run this on the soon to be very precious CPU threads. For all we know, the application could be doing {{while (true) cache.putAsync(Random.nextInt(), "value")}}. At some point we'll run out of memory and we'll stall waiting for the GC, so I still don't think we can guarantee we'll never block unless we have some other backpressure mechanism that prevents new cache invocations from running on the CPU thread pool even when the CPU thread pool is free. > Adding support for actual asynchronous stores is a different PR after this. Sorry I wasn't clear, I meant stores with {{write-behind}} enabled, which are wrapped in an {{AsyncCacheWriter}}. I understand that you would like the caller to never block, but I don't think we can guarantee that with the current SPI and without implementing backpressure first. > Perform all CacheStore operations on a separate thread > ------------------------------------------------------ > > Key: ISPN-9722 > URL: https://issues.jboss.org/browse/ISPN-9722 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.Beta4, 10.0.0.Final > > > Persistence is one of the few remaining systems that are not non blocking. This needs to be remedied. We will eventually need to add an SPI that does this, but for now we need to offload the persistence operations to a different thread pool. > This should only require changes in the PersistenceManager to return non blocking methods (ie. return CompletionStage). We should then update references to use non blocking when possible. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9716) Update internal remote listener code to support non blocking

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9716?page=com.atlassian.jira.plugin.... ] Will Burns updated ISPN-9716: ----------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/6995 > Update internal remote listener code to support non blocking > ------------------------------------------------------------ > > Key: ISPN-9716 > URL: https://issues.jboss.org/browse/ISPN-9716 > Project: Infinispan > Issue Type: Sub-task > Components: Listeners > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > > With ISPN-9714 we will not be able to have non blocking listeners. We need to update all of our remote listeners to use non blocking properly. > Note that the client listeners themselves currently do not send a response, so this does not mean to update our client listener objects, but rather the code supporting them (ie. ClientListenerRegistry). -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10245) Spring Session bug when session id changes

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10245?page=com.atlassian.jira.plugin... ] Katia Aresti updated ISPN-10245: -------------------------------- Status: Open (was: New) > Spring Session bug when session id changes > ------------------------------------------ > > Key: ISPN-10245 > URL: https://issues.jboss.org/browse/ISPN-10245 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10245) Spring Session bug when session id changes

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10245?page=com.atlassian.jira.plugin... ] Work on ISPN-10245 started by Katia Aresti. ------------------------------------------- > Spring Session bug when session id changes > ------------------------------------------ > > Key: ISPN-10245 > URL: https://issues.jboss.org/browse/ISPN-10245 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10245) Spring Session bug when session id changes

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10245?page=com.atlassian.jira.plugin... ] Katia Aresti updated ISPN-10245: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/6960 > Spring Session bug when session id changes > ------------------------------------------ > > Key: ISPN-10245 > URL: https://issues.jboss.org/browse/ISPN-10245 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10037) Create documentation source for Infinispan Operator

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10037?page=com.atlassian.jira.plugin... ] Donald Naro closed ISPN-10037. ------------------------------ > Create documentation source for Infinispan Operator > --------------------------------------------------- > > Key: ISPN-10037 > URL: https://issues.jboss.org/browse/ISPN-10037 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Define and develop a set of titles based on customer use cases for the Infinispan operator. Docs should be sourced as modular asciidoc under infinispan-operator/documentation/asciidoc -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10245) Spring Session bug when session id changes

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10245?page=com.atlassian.jira.plugin... ] Katia Aresti reassigned ISPN-10245: ----------------------------------- Assignee: Katia Aresti > Spring Session bug when session id changes > ------------------------------------------ > > Key: ISPN-10245 > URL: https://issues.jboss.org/browse/ISPN-10245 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2019