[JBoss JIRA] (ISPN-3602) Cache statistics update differently in library and Client-Server mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3602?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3602:
-----------------------------------------------
Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1016450|https://bugzilla.redhat.com/show_bug.cgi?id=1016450] from ON_QA to VERIFIED
> Cache statistics update differently in library and Client-Server mode
> ---------------------------------------------------------------------
>
> Key: ISPN-3602
> URL: https://issues.jboss.org/browse/ISPN-3602
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.CR1
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
> Priority: Minor
> Labels: dm
> Fix For: 7.0.0.Final
>
>
> When running jdg quickstart carmart ( https://github.com/infinispan/jdg-quickstart/tree/master/carmart ) I noticed interesting thing.
> When calling replace() in library mode, the number of stores in cache statistics doesn't change whereas when calling in Client-Server mode, the number of stores increase by 1.
> I went deeper into the code and I found out that in CacheMgmtInterceptor, where there are implemented methods for such statistics updates (like for put() ), there isn't implemented method for updating stats for replace() method, so the control flow is just passed.
> I think it should be consistent, but I don't know which approach is intended, if either increase by 1 or leave it the same.
> If increase is the answer than the solution is simple, implement CacheMgmtInterceptor.visitReplaceCommand(...) the same way as e.g. visitPutKeyValueCommand.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
7 years, 9 months
[JBoss JIRA] (ISPN-5427) Change getAll to return ordered map
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5427?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5427:
--------------------------------
Description:
Currently our getAll returns a map of entries that exist in the cache in any order. We could enhance this to return a map where the entries are in the same iteration order of the Set (important when the user uses a LinkedHashSet). We could even do something like List<V> getAll(List<K>) to show better ordering as an option too.
This has 2 immediate advantages.
1. Remote getAll no longer requires to serialize all the keys in the response since it knows which values map to which keys based on what it sent.
2. Query results need ordered List as well. See query/src/main/java/org/infinispan/query/impl/EntityLoader.java
was:
Currently our getAll returns a map of entries that exist in the cache in any order. We could enhance this to return a map where the entries are in the same iteration order of the Set (important when the user uses a LinkedHashSet). We could even do something like List<V> getAll(List<K>) to show better ordering.
This has 2 immediate advantages.
1. Remote getAll no longer requires to serialize all the keys in the response since it knows which values map to which keys based on what it sent.
2. Query results need ordered List as well. See query/src/main/java/org/infinispan/query/impl/EntityLoader.java
> Change getAll to return ordered map
> -----------------------------------
>
> Key: ISPN-5427
> URL: https://issues.jboss.org/browse/ISPN-5427
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Remote Protocols
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 8.0.0.Final
>
>
> Currently our getAll returns a map of entries that exist in the cache in any order. We could enhance this to return a map where the entries are in the same iteration order of the Set (important when the user uses a LinkedHashSet). We could even do something like List<V> getAll(List<K>) to show better ordering as an option too.
> This has 2 immediate advantages.
> 1. Remote getAll no longer requires to serialize all the keys in the response since it knows which values map to which keys based on what it sent.
> 2. Query results need ordered List as well. See query/src/main/java/org/infinispan/query/impl/EntityLoader.java
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
7 years, 9 months
[JBoss JIRA] (ISPN-5427) Change getAll to return ordered map
by William Burns (JIRA)
William Burns created ISPN-5427:
-----------------------------------
Summary: Change getAll to return ordered map
Key: ISPN-5427
URL: https://issues.jboss.org/browse/ISPN-5427
Project: Infinispan
Issue Type: Enhancement
Components: Core, Remote Protocols
Reporter: William Burns
Assignee: William Burns
Fix For: 8.0.0.Final
Currently our getAll returns a map of entries that exist in the cache in any order. We could enhance this to return a map where the entries are in the same iteration order of the Set (important when the user uses a LinkedHashSet). We could even do something like List<V> getAll(List<K>) to show better ordering.
This has 2 immediate advantages.
1. Remote getAll no longer requires to serialize all the keys in the response since it knows which values map to which keys based on what it sent.
2. Query results need ordered List as well. See query/src/main/java/org/infinispan/query/impl/EntityLoader.java
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
7 years, 9 months
[JBoss JIRA] (ISPN-5268) Backup segments may not be removed after failed state transfer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5268?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5268:
-----------------------------------------------
Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1199210|https://bugzilla.redhat.com/show_bug.cgi?id=1199210] from ON_QA to VERIFIED
> Backup segments may not be removed after failed state transfer
> ---------------------------------------------------------------
>
> Key: ISPN-5268
> URL: https://issues.jboss.org/browse/ISPN-5268
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Tristan Tarrant
> Assignee: Dan Berindei
> Fix For: 7.0.0.Final
>
>
> Dist cache can lost data if the primary and all backups are lost at the same time. To detect such data loss, they are monitoring the tatal sum of entries from all nodes using JMX. If the sum reduces by a considerable ammount, data loss (by lost a segment) is concluded. But they found a case that the sum increases, not decreases, after failed state transfer. This is probably caused by an extra backup segment that hasn't been cleaned up when the last state transfer failed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
7 years, 9 months