[JBoss JIRA] (ISPN-12174) Custom Store cannot configure segmented via xml
by Will Burns (Jira)
Will Burns created ISPN-12174:
---------------------------------
Summary: Custom Store cannot configure segmented via xml
Key: ISPN-12174
URL: https://issues.redhat.com/browse/ISPN-12174
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 11.0.1.Final
Reporter: Will Burns
Assignee: Will Burns
Fix For: 12.0.0.Final
When segmented stores were added it was added to the parser however the code block for custom store was missed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-12173) Explanation for eviction leads confusion
by Wolf-Dieter Fink (Jira)
[ https://issues.redhat.com/browse/ISPN-12173?page=com.atlassian.jira.plugi... ]
Wolf-Dieter Fink reassigned ISPN-12173:
---------------------------------------
Assignee: Donald Naro
> Explanation for eviction leads confusion
> ----------------------------------------
>
> Key: ISPN-12173
> URL: https://issues.redhat.com/browse/ISPN-12173
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation
> Affects Versions: 12.0.0.Dev01
> Reporter: Wolf-Dieter Fink
> Assignee: Donald Naro
> Priority: Major
> Labels: eviction
>
> chapter 8.2. Eviction ([https://infinispan.org/docs/dev/titles/configuring/configuring.html#evict...]
> Starts with a sentence that leads confusion
> "Eviction lets you control the size of the data container by removing cache entries to make space when adding new entries."
>
> The wording "removing cache entries to make space" sound like the entry will be removed like a remove('key') invocation or expiration.
> But this is not the case. It should be clear that the entry is evicted from memory on exactly this instance, no other instance is affected.
> To prevent from not deterministic behaviour if different instances within the cluster are used for request eviction should not be configured without persistence (as mentioned) but the initial statement should be more precise
>
> Proposal
> Eviction lets you contol the size of data container in this local instance by dropping (evict) one choosen entry from memory only without further effects.
> This is a local action for this node and does not affect any other node within the cluster
> To prevent from inconsistency eviction should not be used without a configured persistence
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-12173) Explanation for eviction leads confusion
by Wolf-Dieter Fink (Jira)
[ https://issues.redhat.com/browse/ISPN-12173?page=com.atlassian.jira.plugi... ]
Wolf-Dieter Fink updated ISPN-12173:
------------------------------------
Status: Open (was: New)
> Explanation for eviction leads confusion
> ----------------------------------------
>
> Key: ISPN-12173
> URL: https://issues.redhat.com/browse/ISPN-12173
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation
> Affects Versions: 12.0.0.Dev01
> Reporter: Wolf-Dieter Fink
> Assignee: Donald Naro
> Priority: Major
> Labels: eviction
>
> chapter 8.2. Eviction ([https://infinispan.org/docs/dev/titles/configuring/configuring.html#evict...]
> Starts with a sentence that leads confusion
> "Eviction lets you control the size of the data container by removing cache entries to make space when adding new entries."
>
> The wording "removing cache entries to make space" sound like the entry will be removed like a remove('key') invocation or expiration.
> But this is not the case. It should be clear that the entry is evicted from memory on exactly this instance, no other instance is affected.
> To prevent from not deterministic behaviour if different instances within the cluster are used for request eviction should not be configured without persistence (as mentioned) but the initial statement should be more precise
>
> Proposal
> Eviction lets you contol the size of data container in this local instance by dropping (evict) one choosen entry from memory only without further effects.
> This is a local action for this node and does not affect any other node within the cluster
> To prevent from inconsistency eviction should not be used without a configured persistence
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-12173) Explanation for eviction leads confusion
by Wolf-Dieter Fink (Jira)
Wolf-Dieter Fink created ISPN-12173:
---------------------------------------
Summary: Explanation for eviction leads confusion
Key: ISPN-12173
URL: https://issues.redhat.com/browse/ISPN-12173
Project: Infinispan
Issue Type: Enhancement
Components: Documentation
Affects Versions: 12.0.0.Dev01
Reporter: Wolf-Dieter Fink
chapter 8.2. Eviction ([https://infinispan.org/docs/dev/titles/configuring/configuring.html#evict...]
Starts with a sentence that leads confusion
"Eviction lets you control the size of the data container by removing cache entries to make space when adding new entries."
The wording "removing cache entries to make space" sound like the entry will be removed like a remove('key') invocation or expiration.
But this is not the case. It should be clear that the entry is evicted from memory on exactly this instance, no other instance is affected.
To prevent from not deterministic behaviour if different instances within the cluster are used for request eviction should not be configured without persistence (as mentioned) but the initial statement should be more precise
Proposal
Eviction lets you contol the size of data container in this local instance by dropping (evict) one choosen entry from memory only without further effects.
This is a local action for this node and does not affect any other node within the cluster
To prevent from inconsistency eviction should not be used without a configured persistence
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-11176) XSite Max Idle
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-11176?page=com.atlassian.jira.plugi... ]
Will Burns updated ISPN-11176:
------------------------------
Status: Open (was: New)
> XSite Max Idle
> --------------
>
> Key: ISPN-11176
> URL: https://issues.redhat.com/browse/ISPN-11176
> Project: Infinispan
> Issue Type: Enhancement
> Components: Cross-Site Replication, Expiration
> Reporter: Will Burns
> Priority: Major
> Fix For: 12.0.0.Final
>
>
> Max idle expiration currently doesn't work with xsite. That is if an entry was written and replicated to both sites but one site never reads the value, but the other does. If they then need to read the value from the other site it will be expired (assuming the max idle time has elapsed).
> There are a few ways we can do this.
> 1. Keep access times local to every site. When a site finds an entry is expired it asks the other site(s) if it has a more recent access. If a site is known to have gone down we should touch all entries, since they may not have updated access times. Requires very little additional xsite communication.
> 2. Batch touch commands and only send every so often. Has window of loss, but should be small. Requires more site usage. Wouldn't work for really low max idle times as an entry could expire before the touch command is replicated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-11176) XSite Max Idle
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-11176?page=com.atlassian.jira.plugi... ]
Work on ISPN-11176 started by Will Burns.
-----------------------------------------
> XSite Max Idle
> --------------
>
> Key: ISPN-11176
> URL: https://issues.redhat.com/browse/ISPN-11176
> Project: Infinispan
> Issue Type: Enhancement
> Components: Cross-Site Replication, Expiration
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 12.0.0.Final
>
>
> Max idle expiration currently doesn't work with xsite. That is if an entry was written and replicated to both sites but one site never reads the value, but the other does. If they then need to read the value from the other site it will be expired (assuming the max idle time has elapsed).
> There are a few ways we can do this.
> 1. Keep access times local to every site. When a site finds an entry is expired it asks the other site(s) if it has a more recent access. If a site is known to have gone down we should touch all entries, since they may not have updated access times. Requires very little additional xsite communication.
> 2. Batch touch commands and only send every so often. Has window of loss, but should be small. Requires more site usage. Wouldn't work for really low max idle times as an entry could expire before the touch command is replicated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-12171) Set store segmented attribute dynamically based upon store characteristics
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-12171?page=com.atlassian.jira.plugi... ]
Will Burns updated ISPN-12171:
------------------------------
Fix Version/s: (was: 12.0.0.Final)
> Set store segmented attribute dynamically based upon store characteristics
> --------------------------------------------------------------------------
>
> Key: ISPN-12171
> URL: https://issues.redhat.com/browse/ISPN-12171
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
>
> We now have the new Store SPI which has the `characteristics` method which allows a store to publish what operations/configurations it supports. We should utilize this to determine if a store is segmented or not when the user doesn't specify the configuration value.
> If a Store can dynamically change supporting the segmentation characteristic it should log a message or possibly error if needed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-12171) Set store segmented attribute dynamically based upon store characteristics
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-12171?page=com.atlassian.jira.plugi... ]
Work on ISPN-12171 stopped by Will Burns.
-----------------------------------------
> Set store segmented attribute dynamically based upon store characteristics
> --------------------------------------------------------------------------
>
> Key: ISPN-12171
> URL: https://issues.redhat.com/browse/ISPN-12171
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 12.0.0.Final
>
>
> We now have the new Store SPI which has the `characteristics` method which allows a store to publish what operations/configurations it supports. We should utilize this to determine if a store is segmented or not when the user doesn't specify the configuration value.
> If a Store can dynamically change supporting the segmentation characteristic it should log a message or possibly error if needed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-12171) Set store segmented attribute dynamically based upon store characteristics
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-12171?page=com.atlassian.jira.plugi... ]
Will Burns updated ISPN-12171:
------------------------------
Status: Open (was: New)
> Set store segmented attribute dynamically based upon store characteristics
> --------------------------------------------------------------------------
>
> Key: ISPN-12171
> URL: https://issues.redhat.com/browse/ISPN-12171
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: Will Burns
> Priority: Major
> Fix For: 12.0.0.Final
>
>
> We now have the new Store SPI which has the `characteristics` method which allows a store to publish what operations/configurations it supports. We should utilize this to determine if a store is segmented or not when the user doesn't specify the configuration value.
> If a Store can dynamically change supporting the segmentation characteristic it should log a message or possibly error if needed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-12171) Set store segmented attribute dynamically based upon store characteristics
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-12171?page=com.atlassian.jira.plugi... ]
Work on ISPN-12171 started by Will Burns.
-----------------------------------------
> Set store segmented attribute dynamically based upon store characteristics
> --------------------------------------------------------------------------
>
> Key: ISPN-12171
> URL: https://issues.redhat.com/browse/ISPN-12171
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 12.0.0.Final
>
>
> We now have the new Store SPI which has the `characteristics` method which allows a store to publish what operations/configurations it supports. We should utilize this to determine if a store is segmented or not when the user doesn't specify the configuration value.
> If a Store can dynamically change supporting the segmentation characteristic it should log a message or possibly error if needed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months