[jira] [Updated] (IGNITE-6411) Add ability to disable WAL for ceratin caches in runtime
[ https://issues.apache.org/jira/browse/IGNITE-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6411: Fix Version/s: (was: 2.4) 2.5 > Add ability to disable WAL for ceratin caches in runtime > > > Key: IGNITE-6411 > URL: https://issues.apache.org/jira/browse/IGNITE-6411 > Project: Ignite > Issue Type: Task > Components: persistence >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-1, performance > Fix For: 2.5 > > > Currently every cache update require write to WAL. When doing bulk data load > usually crash recovery is not needed. If something went wrong during data > load, we should simply purge all intermediate data on cache restart. > It makes sense to add ability to disable WAL for ceratin caches. Depending on > restrictions of current architecture, it could be done on per-cache, > per-cache-group or per-memory-policy level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6411) Add ability to disable WAL for ceratin caches in runtime
[ https://issues.apache.org/jira/browse/IGNITE-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6411: Fix Version/s: 2.4 > Add ability to disable WAL for ceratin caches in runtime > > > Key: IGNITE-6411 > URL: https://issues.apache.org/jira/browse/IGNITE-6411 > Project: Ignite > Issue Type: Task > Components: persistence >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Assignee: Anton Vinogradov > Labels: iep-1, performance > Fix For: 2.4 > > > Currently every cache update require write to WAL. When doing bulk data load > usually crash recovery is not needed. If something went wrong during data > load, we should simply purge all intermediate data on cache restart. > It makes sense to add ability to disable WAL for ceratin caches. Depending on > restrictions of current architecture, it could be done on per-cache, > per-cache-group or per-memory-policy level. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6411) Add ability to disable WAL for ceratin caches in runtime
[ https://issues.apache.org/jira/browse/IGNITE-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6411: Labels: iep-1 (was: ) > Add ability to disable WAL for ceratin caches in runtime > > > Key: IGNITE-6411 > URL: https://issues.apache.org/jira/browse/IGNITE-6411 > Project: Ignite > Issue Type: Task > Components: persistence >Affects Versions: 2.1 >Reporter: Vladimir Ozerov > Labels: iep-1, performance > > Currently every cache update require write to WAL. When doing bulk data load > usually crash recovery is not needed. If something went wrong during data > load, we should simply purge all intermediate data on cache restart. > It makes sense to add ability to disable WAL for ceratin caches. Depending on > restrictions of current architecture, it could be done on per-cache, > per-cache-group or per-memory-policy level. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6411) Add ability to disable WAL for ceratin caches in runtime
[ https://issues.apache.org/jira/browse/IGNITE-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6411: Labels: iep-1 performance (was: iep-1) > Add ability to disable WAL for ceratin caches in runtime > > > Key: IGNITE-6411 > URL: https://issues.apache.org/jira/browse/IGNITE-6411 > Project: Ignite > Issue Type: Task > Components: persistence >Affects Versions: 2.1 >Reporter: Vladimir Ozerov > Labels: iep-1, performance > > Currently every cache update require write to WAL. When doing bulk data load > usually crash recovery is not needed. If something went wrong during data > load, we should simply purge all intermediate data on cache restart. > It makes sense to add ability to disable WAL for ceratin caches. Depending on > restrictions of current architecture, it could be done on per-cache, > per-cache-group or per-memory-policy level. -- This message was sent by Atlassian JIRA (v6.4.14#64029)