April 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6504) Try to use the index even if the query matches all entries

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6504?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6504: -------------------------------- Description: A DSL query with no filter clauses will match all entries. In this case we currently run a non-indexed query even if the cache is indexed. This is ok for queries that do not use sorting or pprojections. In that case we do not get any benefit from involving the index. Performance could be improved a bit by using the index if the query has sorting or projections so this should be treated as a special case. was: A DSL query with no filter clauses will match all entries. In this case we currently run a non-indexed query even if the cache is indexed. Performance could be improved a bit by using the index if the query has sorting or projections. This should be treated as a special case. > Try to use the index even if the query matches all entries > ---------------------------------------------------------- > > Key: ISPN-6504 > URL: https://issues.jboss.org/browse/ISPN-6504 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Affects Versions: 8.2.1.Final, 9.0.0.Alpha1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final > > > A DSL query with no filter clauses will match all entries. In this case we currently run a non-indexed query even if the cache is indexed. This is ok for queries that do not use sorting or pprojections. In that case we do not get any benefit from involving the index. > Performance could be improved a bit by using the index if the query has sorting or projections so this should be treated as a special case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6508) Test DSL based remote event filters with compat mode

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6508?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6508: -------------------------------- Status: Open (was: New) > Test DSL based remote event filters with compat mode > ---------------------------------------------------- > > Key: ISPN-6508 > URL: https://issues.jboss.org/browse/ISPN-6508 > Project: Infinispan > Issue Type: Task > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6508) Test DSL based remote event filters with compat mode

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6508?page=com.atlassian.jira.plugin.... ] Work on ISPN-6508 started by Adrian Nistor. ------------------------------------------- > Test DSL based remote event filters with compat mode > ---------------------------------------------------- > > Key: ISPN-6508 > URL: https://issues.jboss.org/browse/ISPN-6508 > Project: Infinispan > Issue Type: Task > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6508) Test DSL based remote event filters with compat mode

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-6508: ----------------------------------- Summary: Test DSL based remote event filters with compat mode Key: ISPN-6508 URL: https://issues.jboss.org/browse/ISPN-6508 Project: Infinispan Issue Type: Task Components: Remote Querying Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 9.0.0.Alpha2 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6394) Coalesce server group view and Infinispan/JGroups view

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6394?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6394: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.2.2.Final Resolution: Done > Coalesce server group view and Infinispan/JGroups view > ------------------------------------------------------ > > Key: ISPN-6394 > URL: https://issues.jboss.org/browse/ISPN-6394 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.2.0.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Critical > Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final > > > Currently the console is using the server-group knowledge (i.e. which host/servers belong to a specific group). While that is definitely the "ideal" situation, we also need to ensure that it corresponds to the "actual" cluster as known to Infinispan/JGroups. This information should be then used to present the user with appropriate warnings if necessary. > For each container %c in each server %s in the server group we need to extract the "members" property: > /host=%h/server=%s/subsystem=datagrid-infinispan/cache-container=%c:read-attribute(name=members) > This returns a list of server names (in the form %h:%s). > This is how we should use the information (in combination with the existing "cluster-availability" property information from the coordinator): > 1. If the server-group list coincides with the container members of all nodes, all is good: the cluster is healthy, all nodes are up and running > 2. If all of the container members contain the SAME subset of the server group, but the missing members are in the STOPPED or STARTING state, everything could be normal: we should depend on the coordinator's "cluster-availability" to tell us if the cluster is unhealthy. > 3. If the container members differ between each other and with the server group view, and all these servers are in RUNNING we have a potential split brain or a cluster which is not formed correctly. > The above deduction should determine not only the label / colour-coding we place in the view header (AVAILABLE, DEGRADED, etc) but also some of the view content: in both the cluster nodes view and the cache nodes view we need to group / sort by membership, so that we clearly show split clusters and stopped nodes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6394) Coalesce server group view and Infinispan/JGroups view

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6394?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6394: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/78 > Coalesce server group view and Infinispan/JGroups view > ------------------------------------------------------ > > Key: ISPN-6394 > URL: https://issues.jboss.org/browse/ISPN-6394 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.2.0.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Critical > Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final > > > Currently the console is using the server-group knowledge (i.e. which host/servers belong to a specific group). While that is definitely the "ideal" situation, we also need to ensure that it corresponds to the "actual" cluster as known to Infinispan/JGroups. This information should be then used to present the user with appropriate warnings if necessary. > For each container %c in each server %s in the server group we need to extract the "members" property: > /host=%h/server=%s/subsystem=datagrid-infinispan/cache-container=%c:read-attribute(name=members) > This returns a list of server names (in the form %h:%s). > This is how we should use the information (in combination with the existing "cluster-availability" property information from the coordinator): > 1. If the server-group list coincides with the container members of all nodes, all is good: the cluster is healthy, all nodes are up and running > 2. If all of the container members contain the SAME subset of the server group, but the missing members are in the STOPPED or STARTING state, everything could be normal: we should depend on the coordinator's "cluster-availability" to tell us if the cluster is unhealthy. > 3. If the container members differ between each other and with the server group view, and all these servers are in RUNNING we have a potential split brain or a cluster which is not formed correctly. > The above deduction should determine not only the label / colour-coding we place in the view header (AVAILABLE, DEGRADED, etc) but also some of the view content: in both the cluster nodes view and the cache nodes view we need to group / sort by membership, so that we clearly show split clusters and stopped nodes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6465) Managent console - launching task with no parameters creates one empty parameter

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6465?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6465: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Alpha2 8.2.2.Final 9.0.0.Final Resolution: Done > Managent console - launching task with no parameters creates one empty parameter > -------------------------------------------------------------------------------- > > Key: ISPN-6465 > URL: https://issues.jboss.org/browse/ISPN-6465 > Project: Infinispan > Issue Type: Bug > Components: Console > Reporter: Jiří Holuša > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final > > > Page: Caches -> select cache container -> select Tasks execution tab > When launching new task, you can specify parameters, which works correctly, if you do. However, if you specify no parameters, you would then expect in your task when calling TaskContext.getParameters() to be null (or at least empty). Currently when you specify no parameters, the getParameters() returns Map with one entry, both empty key and value. > This issue was not present in previous releases, when if no parameter specified, the getParameters returned null. I went through the history and tracked down the commit which causes it: > {code} > commit 6a4d156a9678bcde18d8365ee75fbcea31373949 > Author: vblagoje <vblagoje(a)redhat.com> > Date: Wed Mar 16 14:57:02 2016 -0400 > Simplify task handling > {code} > However, finding the actual cause is below my AngularJS knowledge. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6394) Coalesce server group view and Infinispan/JGroups view

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6394?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6394: ---------------------------------- Status: Open (was: New) > Coalesce server group view and Infinispan/JGroups view > ------------------------------------------------------ > > Key: ISPN-6394 > URL: https://issues.jboss.org/browse/ISPN-6394 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.2.0.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Critical > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > Currently the console is using the server-group knowledge (i.e. which host/servers belong to a specific group). While that is definitely the "ideal" situation, we also need to ensure that it corresponds to the "actual" cluster as known to Infinispan/JGroups. This information should be then used to present the user with appropriate warnings if necessary. > For each container %c in each server %s in the server group we need to extract the "members" property: > /host=%h/server=%s/subsystem=datagrid-infinispan/cache-container=%c:read-attribute(name=members) > This returns a list of server names (in the form %h:%s). > This is how we should use the information (in combination with the existing "cluster-availability" property information from the coordinator): > 1. If the server-group list coincides with the container members of all nodes, all is good: the cluster is healthy, all nodes are up and running > 2. If all of the container members contain the SAME subset of the server group, but the missing members are in the STOPPED or STARTING state, everything could be normal: we should depend on the coordinator's "cluster-availability" to tell us if the cluster is unhealthy. > 3. If the container members differ between each other and with the server group view, and all these servers are in RUNNING we have a potential split brain or a cluster which is not formed correctly. > The above deduction should determine not only the label / colour-coding we place in the view header (AVAILABLE, DEGRADED, etc) but also some of the view content: in both the cluster nodes view and the cache nodes view we need to group / sort by membership, so that we clearly show split clusters and stopped nodes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6408) ClassCastException while executed javascript returns Integer to js-client

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6408?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-6408: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/4242 > ClassCastException while executed javascript returns Integer to js-client > ------------------------------------------------------------------------- > > Key: ISPN-6408 > URL: https://issues.jboss.org/browse/ISPN-6408 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Reporter: Anna Manukyan > Assignee: Galder Zamarreño > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > In case if the javascript returns number, the execution of it over js-client, returns the following error: > {code} > Message: > java.lang.ClassCastException: java.lang.Integer cannot be cast to [B > Stacktrace: > undefined > The code is: > // mode=local,language=javascript,datatype='text/plain; charset=utf-8' > cache.size() > The verifying test is: > it('can execute a script remotely to get node address from cacheManager', function(done) { > Promise.all([client, readFile('spec/utils/test-cacheManager.js')]) > .then(function(vals) { > var c = vals[0]; > return c.addScript('test-cacheManager.js', vals[1].toString()) > .then(function() { return c; } ); > }) > .then(t.assert(t.exec('test-cacheManager.js'), > t.toBe(0))) > .catch(failed(done)).finally(done); > }); > {code} > There is no exception on server side. Also please find below the log of the node.js execution: > {code} > [2016-03-18 18:10:53.848] [DEBUG] connection - Connecting to 127.0.0.1:11222 > [2016-03-18 18:10:53.849] [DEBUG] connection - Connected to 127.0.0.1:11222 > [2016-03-18 18:10:53.849] [DEBUG] client - Invoke ping(msgId=186) > [2016-03-18 18:10:53.849] [TRACE] encoder - Encode operation with topology id 0 > [2016-03-18 18:10:53.849] [TRACE] transport - Write buffer(msgId=186) to 127.0.0.1:11222 > [2016-03-18 18:10:53.852] [TRACE] decoder - Read header(msgId=186): opCode=24, status=6, hasNewTopology=0 > [2016-03-18 18:10:53.852] [TRACE] decoder - Call decode for request(msgId=186) > [2016-03-18 18:10:53.852] [TRACE] connection - After decoding request(msgId=186), buffer size is 6, and offset 6 > [2016-03-18 18:10:53.852] [TRACE] connection - Complete success for request(msgId=186) with undefined > [2016-03-18 18:10:53.852] [DEBUG] client - Invoke put(msgId=187,key=>test-cacheManager.js,value=>S// mode=local,language=javascript,datatype='text/plain; charset=utf-8' > cache.size(),opts=undefined) > [2016-03-18 18:10:53.853] [TRACE] encoder - Encode operation with topology id 0 > [2016-03-18 18:10:53.853] [TRACE] transport - Write buffer(msgId=187) to 127.0.0.1:11222 > [2016-03-18 18:10:53.854] [TRACE] decoder - Read header(msgId=187): opCode=2, status=6, hasNewTopology=0 > [2016-03-18 18:10:53.854] [TRACE] decoder - Call decode for request(msgId=187) > [2016-03-18 18:10:53.854] [TRACE] connection - After decoding request(msgId=187), buffer size is 6, and offset 6 > [2016-03-18 18:10:53.854] [TRACE] connection - Complete success for request(msgId=187) with undefined > [2016-03-18 18:10:53.854] [DEBUG] client - Invoke execute(msgId=188,scriptName=test-cacheManager.js,params=undefined) > [2016-03-18 18:10:53.855] [TRACE] encoder - Encode operation with topology id 0 > [2016-03-18 18:10:53.855] [TRACE] transport - Write buffer(msgId=188) to 127.0.0.1:11222 > [2016-03-18 18:10:53.855] [DEBUG] connection - Disconnected from 127.0.0.1:11222 > [2016-03-18 18:10:53.858] [TRACE] decoder - Read header(msgId=188): opCode=80, status=133, hasNewTopology=0 > [2016-03-18 18:10:53.858] [ERROR] decoder - Error decoding body of request(msgId=188): java.lang.ClassCastException: java.lang.Integer cannot be cast to [B > [2016-03-18 18:10:53.859] [TRACE] connection - After decoding request(msgId=188), buffer size is 75, and offset 75 > [2016-03-18 18:10:53.859] [TRACE] connection - Complete failure for request(msgId=188) with java.lang.ClassCastException: java.lang.Integer cannot be cast to [B > [2016-03-18 18:10:53.869] [DEBUG] client - Invoke clear(msgId=189) > [2016-03-18 18:10:53.869] [TRACE] encoder - Encode operation with topology id 0 > [2016-03-18 18:10:53.869] [TRACE] transport - Write buffer(msgId=189) to 127.0.0.1:11222 > [2016-03-18 18:10:53.869] [TRACE] decoder - Read header(msgId=189): opCode=20, status=0, hasNewTopology=0 > [2016-03-18 18:10:53.869] [TRACE] decoder - Call decode for request(msgId=189) > [2016-03-18 18:10:53.869] [TRACE] connection - After decoding request(msgId=189), buffer size is 6, and offset 6 > [2016-03-18 18:10:53.869] [TRACE] connection - Complete success for request(msgId=189) with undefined > [2016-03-18 18:10:53.878] [DEBUG] connection - Disconnected from 127.0.0.1:11222 > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-20) check whether locking in JDBC cache stores can be replaced with SELECT FOR UPDATE

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-20?page=com.atlassian.jira.plugin.sy... ] Ryan Emerson reassigned ISPN-20: -------------------------------- Assignee: Ryan Emerson (was: Tristan Tarrant) > check whether locking in JDBC cache stores can be replaced with SELECT FOR UPDATE > --------------------------------------------------------------------------------- > > Key: ISPN-20 > URL: https://issues.jboss.org/browse/ISPN-20 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores, Transactions > Reporter: Mircea Markus > Assignee: Ryan Emerson > Labels: hackathon > > Not sure whether the 'outside' locking (MVCC) can't be used so that we won't need locking code within cache stores -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2016