February 2016 - infinispan-issues

[JBoss JIRA] (ISPN-6189) Enhance the REST Server to optionally return the value in put and remove calls

by Alan Field (JIRA)

Alan Field created ISPN-6189: -------------------------------- Summary: Enhance the REST Server to optionally return the value in put and remove calls Key: ISPN-6189 URL: https://issues.jboss.org/browse/ISPN-6189 Project: Infinispan Issue Type: Feature Request Components: Remote Protocols Affects Versions: 8.1.1.Final Reporter: Alan Field Currently the PUT and DELETE methods in the server do not return the previous value when executed. There should be a way to execute these methods and return the previous value, so that a getAndPut and getAndRemove behavior could be implemented. This behavior could be achieved by using a custom header, the cache-control header or the accept header. The default behavior would remain the same. The behavior of the POST method would also remain the same as it is already very similar to a putIfAbsent call. Not sure there are any HTTP standards for this, and I'm also not sure if any other key-value stores implement this. https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://tools.ietf.org/html/rfc7231#section-4.3 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6188) DMR Script management ops

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6188?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6188: ---------------------------------- Status: Open (was: New) > DMR Script management ops > -------------------------- > > Key: ISPN-6188 > URL: https://issues.jboss.org/browse/ISPN-6188 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.2.0.CR1 > > > Add the following script management ops to the DMR: > * script-add(name=name, code=code) > * script-remove(name=name) > * script-cat(name=name) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6188) DMR Script management ops

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6188?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6188: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3986 > DMR Script management ops > -------------------------- > > Key: ISPN-6188 > URL: https://issues.jboss.org/browse/ISPN-6188 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.2.0.CR1 > > > Add the following script management ops to the DMR: > * script-add(name=name, code=code) > * script-remove(name=name) > * script-cat(name=name) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6188) DMR Script management ops

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-6188: ------------------------------------- Summary: DMR Script management ops Key: ISPN-6188 URL: https://issues.jboss.org/browse/ISPN-6188 Project: Infinispan Issue Type: Sub-task Components: Server Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 8.2.0.CR1 Add the following script management ops to the DMR: * script-add(name=name, code=code) * script-remove(name=name) * script-cat(name=name) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6125) JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6125?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6125: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans > ---------------------------------------------------------------------------------- > > Key: ISPN-6125 > URL: https://issues.jboss.org/browse/ISPN-6125 > Project: Infinispan > Issue Type: Bug > Components: Core, Eviction > Affects Versions: 8.1.1.Final > Reporter: Martin Vrabel > Assignee: Martin Gencur > Fix For: 8.2.0.CR1, 8.1.2.Final > > > Description of problem: > Eviction is working because numberOfEntries never exceeds maxEntries. But "evictions" attribute displays always 0 in JMX. > How reproducible: > Always. > Actual results: > evictions is always 0. > Expected results: > evictions should be the count of evicted entries. > Additional info: > This issue found in both of server and library modes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6125) JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6125?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6125: -------------------------------- Fix Version/s: 8.1.2.Final > JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans > ---------------------------------------------------------------------------------- > > Key: ISPN-6125 > URL: https://issues.jboss.org/browse/ISPN-6125 > Project: Infinispan > Issue Type: Bug > Components: Core, Eviction > Affects Versions: 8.1.1.Final > Reporter: Martin Vrabel > Assignee: Martin Gencur > Fix For: 8.2.0.CR1, 8.1.2.Final > > > Description of problem: > Eviction is working because numberOfEntries never exceeds maxEntries. But "evictions" attribute displays always 0 in JMX. > How reproducible: > Always. > Actual results: > evictions is always 0. > Expected results: > evictions should be the count of evicted entries. > Additional info: > This issue found in both of server and library modes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6125) JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6125?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6125: -------------------------------- Fix Version/s: 8.2.0.CR1 > JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans > ---------------------------------------------------------------------------------- > > Key: ISPN-6125 > URL: https://issues.jboss.org/browse/ISPN-6125 > Project: Infinispan > Issue Type: Bug > Components: Core, Eviction > Affects Versions: 8.1.1.Final > Reporter: Martin Vrabel > Assignee: Martin Gencur > Fix For: 8.2.0.CR1 > > > Description of problem: > Eviction is working because numberOfEntries never exceeds maxEntries. But "evictions" attribute displays always 0 in JMX. > How reproducible: > Always. > Actual results: > evictions is always 0. > Expected results: > evictions should be the count of evicted entries. > Additional info: > This issue found in both of server and library modes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5965) Add a new mode (READ ONLY) for Partition Handling

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5965?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-5965: ------------------------------------ My feeling is that the cluster would spend too much time in read-only mode, as it would have to enter after any node crashes. But I guess the option could be useful if the cache is mostly static and the application can tolerate stale data (as the cache could stay in read-only mode for a very long time). > Add a new mode (READ ONLY) for Partition Handling > ------------------------------------------------- > > Key: ISPN-5965 > URL: https://issues.jboss.org/browse/ISPN-5965 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Wolf-Dieter Fink > Labels: partition_handling > > Without any PartitionHandling it is not possible to ensure the consistency of the cache. > With PH enabled it depends whether the remaining partition has the majority or at least all owners for a particular key to be able to access the key. > In some cases the prefered behaviour is to keep every entry readable but prevent from any change to keep consistency. > So there should be a configuration option for the partition handling to switch all instances to READ_ONLY instead of AVAILABLE/DEGRADED. > In this case each get will return the current value but each put will be rejected with a AvailabilityException > This prevents from any rebalancing if one partition contains a majority and stay available. > But in case of a real instance crash it might need a human interaction to set the state back to AVAILABLE as the node will never come back to the cluster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5965) Add a new mode (READ ONLY) for Partition Handling

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/ISPN-5965?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink closed ISPN-5965. ---------------------------------- Resolution: Duplicate Issue > Add a new mode (READ ONLY) for Partition Handling > ------------------------------------------------- > > Key: ISPN-5965 > URL: https://issues.jboss.org/browse/ISPN-5965 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Wolf-Dieter Fink > Labels: partition_handling > > Without any PartitionHandling it is not possible to ensure the consistency of the cache. > With PH enabled it depends whether the remaining partition has the majority or at least all owners for a particular key to be able to access the key. > In some cases the prefered behaviour is to keep every entry readable but prevent from any change to keep consistency. > So there should be a configuration option for the partition handling to switch all instances to READ_ONLY instead of AVAILABLE/DEGRADED. > In this case each get will return the current value but each put will be rejected with a AvailabilityException > This prevents from any rebalancing if one partition contains a majority and stay available. > But in case of a real instance crash it might need a human interaction to set the state back to AVAILABLE as the node will never come back to the cluster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6187) Nodes should be recognized if they join a cluster again if PartitionHandling is active

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created ISPN-6187: -------------------------------------- Summary: Nodes should be recognized if they join a cluster again if PartitionHandling is active Key: ISPN-6187 URL: https://issues.jboss.org/browse/ISPN-6187 Project: Infinispan Issue Type: Enhancement Components: Core Reporter: Wolf-Dieter Fink If a node leave a cluster by crash/power or network problems and is restarted the ID has changed and it is a NEW node. In case of PartitionHandling enabled the cluster can be in a state where it is impossible to recover automatically. As ISPN8 will have a new feature "persistent" address, which is used for CH only at this moment, this address can be used for PH as well. As a result the node join as known and can be - filled with data via state-transfer if the remaining cluster is the major partition and AVAILABLE. - filled with data if at least one owner is inside the remaining cluster equal splitt with numOwner>numNode/2 - full cluster rebalance with WARN/ERROR if there is a possible loss of data -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2016