[
https://issues.apache.org/jira/browse/IGNITE-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Zhdanov updated IGNITE-34:
--------------------------------
Description:
Now we have separate queues to process updated entries.
What about using another approach?
# Maintain counters - unprocessed entries per cache, per partition, cache map
segment
# Special thread wakes up each time counter gets positive from 0 and scans
updated partitions and flushes them to store.
# Removed entries stay in memory until worker processes them (potential OOME)
# After entry is processed counters get decremented.
This approach is more lightweight and more stable when store becomes
unavailable since does not require any additional allocations, searches, etc.
And also provides the same guarantees - all updates will get persisted unless
cluster is alive.
was:
Now we have separate queues to process updated entries.
What about using another approach?
# Maintain counters - unprocessed entries per cache, per partition, cache map
segment
# Special thread wakes up each time counter gets positive from 0 and scans
updated partitions and flushes them to store.
# Removed entries stay in memory until worker processes them (potential OOME)
# After entry is processed counters get decremented.
This approach is more lightweight and more stable when store becomes
unavailable since does not require any additional allocations, searches, etc.
> revisit queues for write behind and local stores
> ------------------------------------------------
>
> Key: IGNITE-34
> URL: https://issues.apache.org/jira/browse/IGNITE-34
> Project: Ignite
> Issue Type: Task
> Reporter: Yakov Zhdanov
>
> Now we have separate queues to process updated entries.
> What about using another approach?
> # Maintain counters - unprocessed entries per cache, per partition, cache map
> segment
> # Special thread wakes up each time counter gets positive from 0 and scans
> updated partitions and flushes them to store.
> # Removed entries stay in memory until worker processes them (potential OOME)
> # After entry is processed counters get decremented.
> This approach is more lightweight and more stable when store becomes
> unavailable since does not require any additional allocations, searches, etc.
> And also provides the same guarantees - all updates will get persisted unless
> cluster is alive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
