[JBoss JIRA] (ISPN-8673) UX improvements in Template Configuration
by Diego Lovison (JIRA)
[ https://issues.jboss.org/browse/ISPN-8673?page=com.atlassian.jira.plugin.... ]
Diego Lovison commented on ISPN-8673:
-------------------------------------
For all server options. (standalone, standalone clustered, domain )
> 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
[JBoss JIRA] (ISPN-8460) Administration console - create user friendly configuration validation errors
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-8460?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-8460:
--------------------------------------
Status: Open (was: New)
> Administration console - create user friendly configuration validation errors
> -----------------------------------------------------------------------------
>
> Key: ISPN-8460
> URL: https://issues.jboss.org/browse/ISPN-8460
> Project: Infinispan
> Issue Type: Enhancement
> Components: Console
> Affects Versions: 9.1.1.Final, 9.2.0.Alpha2
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Fix For: 9.3.0.Final
>
> Attachments: Screen Shot 2017-11-01 at 6.08.57 AM.png
>
>
> While in ISPN-7262 we have ensured that all configurations are indeed checked for validity before being saved we have not provided user-friendly error descriptions. Current errors in place, although informational and correct, look scary and verbose. We should parse the configuration validation errors and display them in a more user friendly approach.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-9003 at 4/2/18 7:00 AM:
------------------------------------------------------------
[~william.burns] I assume we also need a timer task on the primary as well, to handle scenarios like web session keys that are almost never accessed after expiration?
If we do have a timer task running on the primary, it would be running steps 2-6 for each entry that would be expired based on the local last-access timestamp. Then maybe reads should only check expiration on the primary as well, and the backups would just assume that the last-access timestamp on the primary is newer. (Come to think of it, I'm not sure why we didn't do the same for lifespan expiration.)
Then the timer task would need the primary owner to update its last-access timestamp with the latest timestamp from the backups. That means we need to send wall-clock timestamps across nodes, and we'll probably need tests with divergent clocks.
I think state transfer also updates the last-access timestamp, so we need to make sure that state transfer doesn't revive expired entries (accounting for different clocks and long delays applying state).
was (Author: dan.berindei):
@wburns I assume we also need a timer task on the primary as well, to handle scenarios like web session keys that are almost never accessed after expiration?
If we do have a timer task running on the primary, it would be running steps 2-6 for each entry that would be expired based on the local last-access timestamp. Then maybe reads should only check expiration on the primary as well, and the backups would just assume that the last-access timestamp on the primary is newer. (Come to think of it, I'm not sure why we didn't do the same for lifespan expiration.)
Then the timer task would need the primary owner to update its last-access timestamp with the latest timestamp from the backups. That means we need to send wall-clock timestamps across nodes, and we'll probably need tests with divergent clocks.
I think state transfer also updates the last-access timestamp, so we need to make sure that state transfer doesn't revive expired entries (accounting for different clocks and long delays applying state).
> Clustered maxIdle expiration
> ----------------------------
>
> Key: ISPN-9003
> URL: https://issues.jboss.org/browse/ISPN-9003
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Tristan Tarrant
> Assignee: William Burns
> Fix For: 9.3.0.Beta1, 9.3.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-9003:
------------------------------------
@wburns I assume we also need a timer task on the primary as well, to handle scenarios like web session keys that are almost never accessed after expiration?
If we do have a timer task running on the primary, it would be running steps 2-6 for each entry that would be expired based on the local last-access timestamp. Then maybe reads should only check expiration on the primary as well, and the backups would just assume that the last-access timestamp on the primary is newer. (Come to think of it, I'm not sure why we didn't do the same for lifespan expiration.)
Then the timer task would need the primary owner to update its last-access timestamp with the latest timestamp from the backups. That means we need to send wall-clock timestamps across nodes, and we'll probably need tests with divergent clocks.
I think state transfer also updates the last-access timestamp, so we need to make sure that state transfer doesn't revive expired entries (accounting for different clocks and long delays applying state).
> Clustered maxIdle expiration
> ----------------------------
>
> Key: ISPN-9003
> URL: https://issues.jboss.org/browse/ISPN-9003
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Tristan Tarrant
> Assignee: William Burns
> Fix For: 9.3.0.Beta1, 9.3.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[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] Is this issue happening only in standalone clustered? i.e. does this work in other modes i.e. local standalone and clustered?
> 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
[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 reassigned ISPN-8673:
-----------------------------------------
Assignee: Vladimir Blagojevic
> 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
[JBoss JIRA] (ISPN-8973) Administration console - changing eviction strategy results in error
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-8973?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic commented on ISPN-8973:
-------------------------------------------
[~rmacor] I am trying this on server master and it works for me. Have you used official Infinispan 9.2.0 server distribution?
> Administration console - changing eviction strategy results in error
> --------------------------------------------------------------------
>
> Key: ISPN-8973
> URL: https://issues.jboss.org/browse/ISPN-8973
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.2.0.Final
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
>
> Steps to reproduce:
> - start server in domain mode
> - click on cache container -> cache -> configuration -> memory tab -> set memory
> - e.g. (Type: binary, Eviction: count, Size: 10, strategy: FIFO)
> - apply changes -> restart now
> - change the strategy to LRU, click apply changes
> That results in error popup:
> {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:":{"server-group":{"cluster":{"host":{"master":{"server-one":{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:":{"Operation step-3":"WFLYCTL0158: Operation handler failed: java.lang.NullPointerException"}},"server-two":{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:":{"Operation step-3":"WFLYCTL0158: Operation handler failed: java.lang.NullPointerException"}}}}}}}}
> There are no error logs in the server log.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9030) Avoid anonymous classes inside lambdas
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9030?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9030:
-------------------------------
Status: Open (was: New)
> Avoid anonymous classes inside lambdas
> --------------------------------------
>
> Key: ISPN-9030
> URL: https://issues.jboss.org/browse/ISPN-9030
> Project: Infinispan
> Issue Type: Task
> Components: Build
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 9.3.0.Alpha1
>
>
> IntelliJ's incremental compilation sometimes breaks down when recompiling an [anonymous class declared inside a lambda|https://youtrack.jetbrains.com/issue/IDEA-177431]:
> {noformat}
> Error:java: cannot access org.infinispan.query.dsl.embedded.impl.HibernateSearchPropertyHelper$2
> bad class file: /home/dan/Work/jdg/query/target/classes/org/infinispan/query/dsl/embedded/impl/HibernateSearchPropertyHelper$2.class
> bad enclosing method attribute for class org.infinispan.query.dsl.embedded.impl.HibernateSearchPropertyHelper$2
> Please remove or make sure it appears in the correct subdirectory of the classpath.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years