May 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8010) Data Management Operations through Console

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8010?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-8010: ------------------------------------------- [~pzapataf] This issue seems like a spot on duplicate of ISPN-8759. In ISPN-8759 we even have subtasks that are also duplicates of the subtasks listed here. What do we do? > Data Management Operations through Console > ------------------------------------------ > > Key: ISPN-8010 > URL: https://issues.jboss.org/browse/ISPN-8010 > Project: Infinispan > Issue Type: Feature Request > Components: Console > Reporter: Pedro Zapata > Assignee: Vladimir Blagojevic > > Users should be allowed to perform basic data operations over the grid, such as: > * Browsing the content of a cache, with pagination and result count > * Sending a Ickle query, and walk through the results - validate syntax > * Sending a GET and retrieving value > * Sending a PUT > * Delete by Key > * Download results of a query > * Get current value of a counter and/or increment > * Reset counter > The basic format for object representation will be JSON. This operations will work against the REST interface. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8433) Cache counts per node in management console incorrect

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8433?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-8433: ------------------------------------------- [~galder.zamarreno] I agree with you but the root cause has to be in the server code and the way we calculate these counts. In admin console, we just read values given to us from the server side. If someone else more familiar with that codebase cannot take this JIRA - I'll do. > Cache counts per node in management console incorrect > ----------------------------------------------------- > > Key: ISPN-8433 > URL: https://issues.jboss.org/browse/ISPN-8433 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.1.0.Final > Reporter: Galder Zamarreño > Assignee: Vladimir Blagojevic > Attachments: Screen Shot 2017-10-18 at 17.05.10.png > > > I was playing around with the management console, and the write counts per node in a cache don't appear to be correct. The count per node seems to be evaluated from the total, divided by number of nodes, but in a distributed cache that's not exactly true. Each node might have slightly different count. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8673) UX improvements in Template Configuration

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8673?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-8673: ------------------------------------------- [~dlovison] I was not able to reproduce this issue in standalone, clustered, or domain mode. Here is a video https://youtu.be/Sg-Pq-I8p9k > UX improvements in Template Configuration > ----------------------------------------- > > Key: ISPN-8673 > URL: https://issues.jboss.org/browse/ISPN-8673 > Project: Infinispan > Issue Type: Feature Request > Components: Console > Affects Versions: 9.2.0.Beta2 > Reporter: Diego Lovison > Assignee: Vladimir Blagojevic > Priority: Trivial > > 1. Start the Infinispan server in the standalone mode using the clustered option. Command to be executed: ./standalone.sh -Djboss.socket.binding.port-offset=100 -Djboss.node.name=nodeA -c clustered.xml > 2. Open http://127.0.0.1:10090/console/index.html#/containers/standalone/clustere... and hit the button “Create new template”. Fill the information and hit the “Next” button. > 3. In the "Clustering" panel you will see that there are values in the fields: Owners, Segments, L1 Lifespan, etc. > 4. Hit the “Create” button. The new template will appears in the list. > 5. In the list, hit the “Edit” button > 6. You will see that the values are empty. I am expecting the same values when I was creating the Template Configuration. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9206) Handle long qualified region names more efficiently

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-9206?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-9206: ------------------------------ Summary: Handle long qualified region names more efficiently (was: Handle long qualified region names more effectively) > Handle long qualified region names more efficiently > --------------------------------------------------- > > Key: ISPN-9206 > URL: https://issues.jboss.org/browse/ISPN-9206 > Project: Infinispan > Issue Type: Enhancement > Components: Hibernate Cache > Affects Versions: 9.2.2.Final, 9.3.0.Beta1 > Reporter: Radim Vansa > Assignee: Radim Vansa > > Hibernate region names are FQCNs, and when the prefix is added this can exceed the 255 byte ByteString limit. Also, it's inefficient to ship such long cache names with each command. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9206) Handle long qualified region names more effectively

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-9206?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-9206: ----------------------------------- If you change the fields/marshalling of the entities, yes, you'll have issues. But as an user I'd expect that adding a completely new entity to my schema doesn't blow the app up, and I'd prefer to keep it implemented that way. My feeling is that hashing (assuming non-byzantine* deployments) makes conflicts so rare that a config option to revert to current behaviour would be sufficient. And if the name is too long *and* has conflicts, the user is simply out of luck. The only thing I'd do is telling user that he has a conflict on the node where we can detect it. * I hope that we're past the multi-tenancy attempts where we'd expect the other deployment stealing data from cache through generating conflicting hashes on region names, right? > Handle long qualified region names more effectively > --------------------------------------------------- > > Key: ISPN-9206 > URL: https://issues.jboss.org/browse/ISPN-9206 > Project: Infinispan > Issue Type: Enhancement > Components: Hibernate Cache > Affects Versions: 9.2.2.Final, 9.3.0.Beta1 > Reporter: Radim Vansa > Assignee: Radim Vansa > > Hibernate region names are FQCNs, and when the prefix is added this can exceed the 255 byte ByteString limit. Also, it's inefficient to ship such long cache names with each command. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9160) Concurrent management console access in multiple OpenShift clusters

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-9160?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-9160: ------------------------------------------- [~galder.zamarreno] could you not open a new browser window pointing to another cluster? Please give us a bit more context. > Concurrent management console access in multiple OpenShift clusters > ------------------------------------------------------------------- > > Key: ISPN-9160 > URL: https://issues.jboss.org/browse/ISPN-9160 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management, OpenShift > Reporter: Galder Zamarreño > Assignee: Vladimir Blagojevic > Labels: redhat-summit-18 > > The management console, when used in conjunction with OpenShift, does not handle well opening management console windows to different OpenShift clusters. To workaround it, during the presentation, one site was queried using the console, and the same console was used to update data in that site, but when it came to checking other sites, command line was used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9159) Improve visulation of cached data in management console

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-9159?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-9159: ------------------------------------------- So what you are saying [~galder.zamarreno] is that we should display data in table rows instead of plain JSON? > Improve visulation of cached data in management console > ------------------------------------------------------- > > Key: ISPN-9159 > URL: https://issues.jboss.org/browse/ISPN-9159 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management > Reporter: Galder Zamarreño > Assignee: Vladimir Blagojevic > Labels: redhat-summit-18 > > A pre-release version of this was used during the presentation to demonstrate that updates in one site would be replicated to other sites. The first thing we noticed is the UI itself, it needs some polishing and adjusting to better represent data. Tristan mentioned having some kind of table and I agree with that, using rows in a table to represent k/v entries would probably be better. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9206) Handle long qualified region names more effectively

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-9206?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-9206: --------------------------------------- Regarding full/short names, I agree and we recently had this same debate in the management SPIs of Hibernate ORM (those who expose a String - these changed). Good point about possibly having different deployment versions. Wouldn't that have many more issues though? You can't even guarantee that the same named entities actually have compatible fields, or even point to the same database. I would expect that to be a user error but you're right on needing to be defensive about it, having just a short id would be poor. Either way, just hashing the name could potentially suffer from similar problems, it just makes it less likely to manifest in practice. Would be nice to hear [~pferraro]'s opinion on such strategies, I'm sure he has more experience. > Handle long qualified region names more effectively > --------------------------------------------------- > > Key: ISPN-9206 > URL: https://issues.jboss.org/browse/ISPN-9206 > Project: Infinispan > Issue Type: Enhancement > Components: Hibernate Cache > Affects Versions: 9.2.2.Final, 9.3.0.Beta1 > Reporter: Radim Vansa > Assignee: Radim Vansa > > Hibernate region names are FQCNs, and when the prefix is added this can exceed the 255 byte ByteString limit. Also, it's inefficient to ship such long cache names with each command. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9205) LocalInvalidationSynchronization#afterCompletion calls PutFromLoadValidator#endInvalidatingKey with arguments in incorrect order

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-9205?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-9205: ----------------------------------- It does not since it got introduced in HHH-12457 which is not in master yet. > LocalInvalidationSynchronization#afterCompletion calls PutFromLoadValidator#endInvalidatingKey with arguments in incorrect order > -------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-9205 > URL: https://issues.jboss.org/browse/ISPN-9205 > Project: Infinispan > Issue Type: Bug > Components: Hibernate Cache > Affects Versions: 9.2.3.Final > Reporter: Gail Badner > Fix For: 9.2.4.Final > > > {{LocalInvalidationSynchronization#afterCompletion}} calls: > {{validator.endInvalidatingKey(key, lockOwner, ...) }} > Instead, it should call: > {{validator.endInvalidatingKey(lockOwner, key, ... }} > I'll create a PR shortly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9183) Replace <eviction> with <memory> in 2LC configs

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9183?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9183: ---------------------------------- Fix Version/s: 9.2.4.Final > Replace <eviction> with <memory> in 2LC configs > ----------------------------------------------- > > Key: ISPN-9183 > URL: https://issues.jboss.org/browse/ISPN-9183 > Project: Infinispan > Issue Type: Task > Components: Hibernate Cache > Affects Versions: 9.3.0.Beta1 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.3.0.CR1, 9.2.4.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2018