ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yakov Zhdanov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-34) revisit queues for write behind and local stores
Date Wed, 03 Dec 2014 13:35:12 GMT

     [ 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)

Mime
View raw message