May 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7168) Prevent user from configuring passivation with a shared store

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7168?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7168: -------------------------------- Fix Version/s: 9.3.0.Final (was: 10.0.0.Final) > Prevent user from configuring passivation with a shared store > ------------------------------------------------------------- > > Key: ISPN-7168 > URL: https://issues.jboss.org/browse/ISPN-7168 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.4.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 9.3.0.Final > > > Passivation only makes sense with a non shared cache store. --The problem is that if an entry is passivated on a shared cache store only the first node will be able to activate the entry and subsequent nodes will always see null.-- > Looking closer the bigger issue is if an entry becomes passivated and then subsequently written to you will have a different value in the store as you would in memory. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8979) Accept header documentation needs to be clarified

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8979?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes edited comment on ISPN-8979 at 5/2/18 12:25 PM: ------------------------------------------------------------------ This should be written as: {panel:title=Accept: text/plain;q=0.7, application/json;q=0.8, */*;q=0.6} Infinispan will give precedence to the JSON format (higher priority 0.8) during the negotiation. If the format with higher priority is not supported by the server, the next candidate format will be text/plain (second highest priority 0.7), and in case not supported as well, it'd fall back to \*/\*, that will pick a format suitable for displaying automatically based on the cache configuration. After the negotiation is done, the operation will carry on in the chosen format, and eventual posterior errors will not cause the server to try the next format. {panel} was (Author: gustavonalle): This should be written as: {panel:title=Accept: text/plain;q=0.7, application/json;q=0.8, */*;q=0.6} Infinispan will give precedence to the JSON format (higher priority 0.8) during the negotiation. If the format with higher priority is not supported by the server, the next format picked will be text/plain (second highest priority 0.7), and finally it falls back to \*/\*, that will pick a format suitable for displaying automatically based on the cache configuration. After the negotiation is done, the operation will carry on in the chosen format, and eventual posterior errors will not cause the server to try the next format. {panel} > Accept header documentation needs to be clarified > -------------------------------------------------- > > Key: ISPN-8979 > URL: https://issues.jboss.org/browse/ISPN-8979 > Project: Infinispan > Issue Type: Enhancement > Reporter: Diego Lovison > Assignee: Gustavo Fernandes > > The "Accept header" documentation http://infinispan.org/docs/stable/user_guide/user_guide.html#rest.accept has the following information > ---- > will cause Infinispan to try first to return content in JSON format (higher priority 0.8). If it’s not possible to convert the storage format to JSON, next format tried will be text/plain (second highest priority 0.7), and finally it falls back to */*, that will pick a format suitable for displaying automatically based on the cache configuration. > ---- > But it was not designed to be working on this way. > The commit https://github.com/diegolovison/infinispan/commit/6a57964f26d6742e8ec29cc... has an invalid xml content with a second priority format equals "text/plain". > The xml is invalid but the text is valid. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8979) Accept header documentation needs to be clarified

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8979?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-8979: ----------------------------------------- This should be written as: {panel:title=Accept: text/plain;q=0.7, application/json;q=0.8, */*;q=0.6} Infinispan will give precedence to the JSON format (higher priority 0.8) during the negotiation. If the format with higher priority is not supported by the server, the next format picked will be text/plain (second highest priority 0.7), and finally it falls back to \*/\*, that will pick a format suitable for displaying automatically based on the cache configuration. After the negotiation is done, the operation will carry on in the chosen format, and eventual posterior errors will not cause the server to try the next format. {panel} > Accept header documentation needs to be clarified > -------------------------------------------------- > > Key: ISPN-8979 > URL: https://issues.jboss.org/browse/ISPN-8979 > Project: Infinispan > Issue Type: Enhancement > Reporter: Diego Lovison > Assignee: Gustavo Fernandes > > The "Accept header" documentation http://infinispan.org/docs/stable/user_guide/user_guide.html#rest.accept has the following information > ---- > will cause Infinispan to try first to return content in JSON format (higher priority 0.8). If it’s not possible to convert the storage format to JSON, next format tried will be text/plain (second highest priority 0.7), and finally it falls back to */*, that will pick a format suitable for displaying automatically based on the cache configuration. > ---- > But it was not designed to be working on this way. > The commit https://github.com/diegolovison/infinispan/commit/6a57964f26d6742e8ec29cc... has an invalid xml content with a second priority format equals "text/plain". > The xml is invalid but the text is valid. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9115) Creating a permanent cache breaks server startup on Windows

by Vittorio Rigamonti (JIRA)

Vittorio Rigamonti created ISPN-9115: ---------------------------------------- Summary: Creating a permanent cache breaks server startup on Windows Key: ISPN-9115 URL: https://issues.jboss.org/browse/ISPN-9115 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 9.2.0.Final Environment: Windows Reporter: Vittorio Rigamonti On windows the server fails to start with this error: ISPN000508: Cannot rename file C:\Users\rigazilla\git\cpp-client\infinispan-server-9.2.0.Final\standalone\data\datagrid-infinispan\local\caches4888298868697999836.tmp to C:\Users\rigazilla\git\cpp-client\infinispan-server-9.2.0.Final\standalone\data\datagrid-infinispan\local\caches.xml if a permanent cache has been created programmatically _(administration().withFlags(PERMANENT))_. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9110) Create generic store migrator

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9110?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9110: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/5952 > Create generic store migrator > ----------------------------- > > Key: ISPN-9110 > URL: https://issues.jboss.org/browse/ISPN-9110 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 9.3.0.Alpha1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.3.0.Beta1 > > > Currently we have the JDBCMigrator to help users migrate from infinispan 8.2.x -> 9.x as 8.x stores are not compatible with 9.x stores due to the marshaller changes. We should make this tool a generic store migrator that allows any of our supported stores to migrate to the latest Infinispan version. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8979) Accept header documentation needs to be clarified

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8979?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reassigned ISPN-8979: --------------------------------------- Assignee: Gustavo Fernandes > Accept header documentation needs to be clarified > -------------------------------------------------- > > Key: ISPN-8979 > URL: https://issues.jboss.org/browse/ISPN-8979 > Project: Infinispan > Issue Type: Enhancement > Reporter: Diego Lovison > Assignee: Gustavo Fernandes > > The "Accept header" documentation http://infinispan.org/docs/stable/user_guide/user_guide.html#rest.accept has the following information > ---- > will cause Infinispan to try first to return content in JSON format (higher priority 0.8). If it’s not possible to convert the storage format to JSON, next format tried will be text/plain (second highest priority 0.7), and finally it falls back to */*, that will pick a format suitable for displaying automatically based on the cache configuration. > ---- > But it was not designed to be working on this way. > The commit https://github.com/diegolovison/infinispan/commit/6a57964f26d6742e8ec29cc... has an invalid xml content with a second priority format equals "text/plain". > The xml is invalid but the text is valid. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7168) Prevent user from configuring passivation with a shared store

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7168?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7168: -------------------------------- Description: Passivation only makes sense with a non shared cache store. --The problem is that if an entry is passivated on a shared cache store only the first node will be able to activate the entry and subsequent nodes will always see null.-- Looking closer the bigger issue is if an entry becomes passivated and then subsequently written to you will have a different value in the store as you would in memory. was:Passivation only makes sense with a non shared cache store. The problem is that if an entry is passivated on a shared cache store only the first node will be able to activate the entry and subsequent nodes will always see null. > Prevent user from configuring passivation with a shared store > ------------------------------------------------------------- > > Key: ISPN-7168 > URL: https://issues.jboss.org/browse/ISPN-7168 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.4.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 10.0.0.Final > > > Passivation only makes sense with a non shared cache store. --The problem is that if an entry is passivated on a shared cache store only the first node will be able to activate the entry and subsequent nodes will always see null.-- > Looking closer the bigger issue is if an entry becomes passivated and then subsequently written to you will have a different value in the store as you would in memory. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7168) Prevent user from configuring passivation with a shared store

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7168?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7168: -------------------------------- Fix Version/s: 10.0.0.Final (was: 9.3.0.Final) > Prevent user from configuring passivation with a shared store > ------------------------------------------------------------- > > Key: ISPN-7168 > URL: https://issues.jboss.org/browse/ISPN-7168 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.4.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 10.0.0.Final > > > Passivation only makes sense with a non shared cache store. The problem is that if an entry is passivated on a shared cache store only the first node will be able to activate the entry and subsequent nodes will always see null. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9113) SITE_UNREACHABLE not handled by JGroupsTransport

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9113?page=com.atlassian.jira.plugin.... ] Galder Zamarreño reassigned ISPN-9113: -------------------------------------- Assignee: Galder Zamarreño > SITE_UNREACHABLE not handled by JGroupsTransport > ------------------------------------------------ > > Key: ISPN-9113 > URL: https://issues.jboss.org/browse/ISPN-9113 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication > Affects Versions: 9.2.2.Final, 9.3.0.Alpha1 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > If a user defineds a site with SYNC x-site replication and the site is unavailable, requests will timeout instead of quickly failing. See below for a summary discussion: > {code} > Galder: @Dan Berindei @Pedro Ruivo @Bela Ban Any thoughts on my dev thread? > Galder: In essence, @Dan Berindei you made ChannelCallbacks implement UpHandler, but JChannel.invokeCallback() > won't pass any events to receive instance variable because it doesn't check whether the receiver is UpHandler //cc @Tristan > Bela Ban: @Galder yes, this won't work > Bela Ban: @Galder You need to call RELAY2.setRouterStatusListener() directly > Bela Ban: Implementing this as part of Receiver won't help > Galder: Don't think RELAY2.setRouterStatusListener() is what I want - I can see RELAY2.handleMessage() passing up the > stack Event.SITE_UNREACHABLE though, the problem is that there's no handler for that > Bela Ban: @Galder Yes, but the SITE_UNREACHABLE event is only handled by RequestCorrelator, not by JChannel > Galder: Ah ok, let me check what that does > Bela Ban: The thing is that RequestCorrelator is not used anymore (AFAIK), as Infinispan moved from > MessageDispatcher to JChannel > Galder: the RequestCorrelator is never called > Galder: exactly > Bela Ban: So this is a regression caused by that move then > Galder: Yeah, that's my feeling too. That's why I was asking Dan about the move to make ChannelCallbacks class an > UpHandler, because I noticed that happened when the move to JChannel happened > Galder: The impact of this is the following: if any site in SYNC and the site is unreachable, you'd get a timeout eventually > instead of a immediate failure > Galder: I'm trying to implement auto x-site state transfer for protobuf metadata cache and I cannot do it until this is fixed > Galder: I'll see if I can get something working with ASYNC, but ASYNC is not a good option for protobuf metadata. > If a node does not succesfully get it, it won't be able to work properly > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9114) Replace Runtime.getRuntime().availableProcessors() usage with a cgroups quota-aware implementation

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-9114: ------------------------------------- Summary: Replace Runtime.getRuntime().availableProcessors() usage with a cgroups quota-aware implementation Key: ISPN-9114 URL: https://issues.jboss.org/browse/ISPN-9114 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.2.1.Final Reporter: Tristan Tarrant Assignee: Tristan Tarrant Java's Runtime.getRuntime().availableProcessors() doesn't take into account cgroup quotas correctly. Provide our own implementation that does. See https://github.com/wildfly/wildfly-common/blob/master/src/main/java/org/w... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2018