[JBoss JIRA] (ISPN-12173) Explanation for eviction leads confusion
by Donald Naro (Jira)
[ https://issues.redhat.com/browse/ISPN-12173?page=com.atlassian.jira.plugi... ]
Donald Naro updated ISPN-12173:
-------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/8617
> 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)
5 years, 2 months
[JBoss JIRA] (ISPN-11176) XSite Max Idle
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11176?page=com.atlassian.jira.plugi... ]
Dan Berindei commented on ISPN-11176:
-------------------------------------
> Entries will only expire when reaper is run, which can take a while if a store is present or the time is high
Thinking some more about this, we could also send the touch command on read, if the read happens later than {{last access + max-idle timeout - max-idle delay}}.
Then we could expire the entries on read as well, we just need to do it later than {{last access + max-idle timeout}}.
> Entries that were read can still expire right after being read (even from same site). Option 2 would only expire an entry if the current site hasn't seen it, where as this could read from the same site and then have it expire.
Agree. But option 2 would also allow an entry to stay alive on one site after it has been removed on the other sites, and IMO that's worse.
> It adds another configuration option
Also true. I have thought about making it the 1x or 2x {{xsite backup timeout}}, but I didn't want to talk too much about the actual value.
> I don't think we can take away the fact that a local site read is sync to update max idle, because we would run into the original issue that required clustered xsite to be rewritten in that if a node goes down it can cause some entries to expire early.
I see it the other way around: IRAC already allows sites to make conflicting updates to the same key, and one of them wins so it's eventually consistent. So it's enough to make max-idle expiration eventually consistent as well, it's not worth adding the latency of a x-site RPC to make max-idle expiration as consistent as it is in a single cluster.
One more thing: In your option 1, I think the purge expired task needs to behave like a read and send a wait for a {{check last access}} response before actually expiring the entry. This will require some tuning WRT how many expirations can be ongoing at the same time. In my proposal the purge expired task just sends async commands, but it may need a limit as well, to avoid taking too much bandwidth/processing time away from real work.
> 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)
5 years, 2 months
[JBoss JIRA] (ISPN-12220) change default configuration within the ${infinispan.cluster.stack:XXX} does not have an effect
by Wolf-Dieter Fink (Jira)
Wolf-Dieter Fink created ISPN-12220:
---------------------------------------
Summary: change default configuration within the ${infinispan.cluster.stack:XXX} does not have an effect
Key: ISPN-12220
URL: https://issues.redhat.com/browse/ISPN-12220
Project: Infinispan
Issue Type: Enhancement
Components: Server
Affects Versions: 11.0.3.Final
Reporter: Wolf-Dieter Fink
If a different stack should be configured within the XML configuration
<cache-container name="default" statistics="true">
<transport cluster="${infinispan.cluster.name}" stack="${infinispan.cluster.stack:someDifferent}" node-name="${infinispan.node.name:}"/>
this will not have any effect, the default tcp stack is used as long as ${infinispan.cluster.stack} is set. The default "tcp" is set hardcoded.
This is confusing if the stack should be changed inside the configuration with the <jgroups> element.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 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 edited comment on ISPN-11176 at 8/11/20 1:54 PM:
------------------------------------------------------------
{quote}*TLDR;* Pre-expire entries at time {{last access + max-idle timeout}}, actually expire them at time {{last access + max-idle timeout + max-idle delay}}, or as soon as we know all other sites have also pre-expired the entry. Reads of pre-expired entries do not keep the entries alive.
{quote}
While this an interesting idea, I definitely have reservations about it.
# Entries will only expire when reaper is run, which can take a while if a store is present or the time is high
# Entries that were read can still expire right after being read (even from same site). Option 2 would only expire an entry if the current site hasn't seen it, where as this could read from the same site and then have it expire.
# It adds another configuration option :(
I personally don't think that is worth it just to make an expired read to not be async.
I don't think we can take away the fact that a local site read is sync to update max idle, because we would run into the original issue that required clustered xsite to be rewritten in that if a node goes down it can cause some entries to expire early.
was (Author: william.burns):
{quote}*TLDR;* Pre-expire entries at time {{last access + max-idle timeout}}, actually expire them at time {{last access + max-idle timeout + max-idle delay}}, or as soon as we know all other sites have also pre-expired the entry. Reads of pre-expired entries do not keep the entries alive.
{quote}
While this an interesting idea, I definitely have reservations about it.
# Entries will only expire when reaper is run, which can take a while if a store is present or the time is high
# Entries that were read can still expire right after being read (even from same site). Option 2 would only expire an entry if the current site hasn't seen it, where as this could read from the same site and then have it expire.
# It adds another configuration option :(
I personally don't think that is worth it just to make an expired read to not be async.
> 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)
5 years, 3 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 edited comment on ISPN-11176 at 8/11/20 12:57 PM:
-------------------------------------------------------------
{quote}*TLDR;* Pre-expire entries at time {{last access + max-idle timeout}}, actually expire them at time {{last access + max-idle timeout + max-idle delay}}, or as soon as we know all other sites have also pre-expired the entry. Reads of pre-expired entries do not keep the entries alive.
{quote}
While this an interesting idea, I definitely have reservations about it.
# Entries will only expire when reaper is run, which can take a while if a store is present or the time is high
# Entries that were read can still expire right after being read (even from same site). Option 2 would only expire an entry if the current site hasn't seen it, where as this could read from the same site and then have it expire.
# It adds another configuration option :(
I personally don't think that is worth it just to make an expired read to not be async.
was (Author: william.burns):
{quote}
*TLDR;* Pre-expire entries at time {{last access + max-idle timeout}}, actually expire them at time {{last access + max-idle timeout + max-idle delay}}, or as soon as we know all other sites have also pre-expired the entry. Reads of pre-expired entries do not keep the entries alive.
{quote}
While this an interesting idea, I definitely have reservations about it.
# Entries will only expire when reaper is run, which can take a while if a store is present or the time is high
# Entries that were read can still expire right after. Option 2 would only expire an entry if the current site hasn't seen it, where as this could read from the same site and then have it expire.
# It adds another configuration option :(
> 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)
5 years, 3 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 commented on ISPN-11176:
-----------------------------------
{quote}
*TLDR;* Pre-expire entries at time {{last access + max-idle timeout}}, actually expire them at time {{last access + max-idle timeout + max-idle delay}}, or as soon as we know all other sites have also pre-expired the entry. Reads of pre-expired entries do not keep the entries alive.
{quote}
While this an interesting idea, I definitely have reservations about it.
# Entries will only expire when reaper is run, which can take a while if a store is present or the time is high
# Entries that were read can still expire right after. Option 2 would only expire an entry if the current site hasn't seen it, where as this could read from the same site and then have it expire.
# It adds another configuration option :(
> 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)
5 years, 3 months
[JBoss JIRA] (ISPN-12219) Change the Operations Performance Metrics values
by Diego Lovison (Jira)
Diego Lovison created ISPN-12219:
------------------------------------
Summary: Change the Operations Performance Metrics values
Key: ISPN-12219
URL: https://issues.redhat.com/browse/ISPN-12219
Project: Infinispan
Issue Type: Enhancement
Components: Console
Reporter: Diego Lovison
When Infinispan REST API Return
{noformat}
average_read_time: 0
average_read_time_nanos: 367312
average_remove_time: 0
average_remove_time_nanos: 0
average_write_time: 93
average_write_time_nanos: 93738739
{noformat}
The UI will show
{noformat}
0 Avg Reads
93 Avg Writes
0 Avg Removes
{noformat}
It seems to me that no reads where performed in the cache.
We should instead of display 0 converts from nanos to ms
For example:
{noformat}
0,36 Avg Reads
93 Avg Writes
0 Avg Removes
{noformat}
Also, I don't know what means 93 or 0,36. We should add the time unit.
For example:
{noformat}
0,36ms Avg Reads
93ms Avg Writes
0ms Avg Removes
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (ISPN-12218) Indexed caches with non-indexed entities query inconsistency
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12218?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-12218:
-------------------------------------
Description:
When a cache is indexed, but the protobuf entitiy is not:
"FROM Entity" returns zero results
"FROM Entity WHERE <predicate>" return results
It appears in the first case the query goes to the index (that will be empty), but not in the second where it does a non-indexed query
was:
When a cache is indexed, but the protobuf entitiy is not:
"FROM Entity" returns zero results
"FROM Entity WHERE <predicate>" return results
It appears in the first case the query goes to the index, but not in the second where it does a non-indexed query
> Indexed caches with non-indexed entities query inconsistency
> ------------------------------------------------------------
>
> Key: ISPN-12218
> URL: https://issues.redhat.com/browse/ISPN-12218
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 11.0.3.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> When a cache is indexed, but the protobuf entitiy is not:
> "FROM Entity" returns zero results
> "FROM Entity WHERE <predicate>" return results
> It appears in the first case the query goes to the index (that will be empty), but not in the second where it does a non-indexed query
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (ISPN-12218) Indexed caches with non-indexed entities query inconsistency
by Gustavo Fernandes (Jira)
Gustavo Fernandes created ISPN-12218:
----------------------------------------
Summary: Indexed caches with non-indexed entities query inconsistency
Key: ISPN-12218
URL: https://issues.redhat.com/browse/ISPN-12218
Project: Infinispan
Issue Type: Bug
Components: Embedded Querying, Remote Querying
Affects Versions: 11.0.3.Final
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
When a cache is indexed, but the protobuf entities is not:
"FROM Entity" returns zero results
"FROM Entity WHERE <predicate>" return results
It appears in the first case the query goes to the index, but not in the second where it does a non-indexed query
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months