[JBoss JIRA] (ISPN-9117) Expose passivateAll over JMX
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-9117:
-------------------------------------
Summary: Expose passivateAll over JMX
Key: ISPN-9117
URL: https://issues.jboss.org/browse/ISPN-9117
Project: Infinispan
Issue Type: Enhancement
Components: JMX, reporting and management, Loaders and Stores
Affects Versions: 9.2.2.Final
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 9.3.0.Final, 9.2.3.Final
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ISPN-9115) Creating a permanent cache breaks server startup on Windows
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9115?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-9115:
-------------------------------------
Assignee: Tristan Tarrant
> 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
> Assignee: Tristan Tarrant
>
> 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)
7 years, 11 months
[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)
7 years, 11 months
[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)
7 years, 11 months
[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)
7 years, 11 months
[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)
7 years, 11 months
[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)
7 years, 11 months