ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Chugunov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-5499) Binary metadata is persisted when persistence is enabled
Date Thu, 15 Jun 2017 12:45:00 GMT

     [ https://issues.apache.org/jira/browse/IGNITE-5499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sergey Chugunov updated IGNITE-5499:
------------------------------------
    Description: 
h2. Notes
Roughly speaking current model of binary metadata handling has two modes: compactFooter on
and off, flag to switch is available at *IgniteConfiguration#BinaryConfiguration#compactFooter*
configuration setting.

If compact footer is on (default configuration) than metadata isn't persisted anywhere even
if persisting of caches content is enabled (see IGNITE-5267 for more details about persistence
feature in Ignite).
Thus after full cluster restart all metadata gets lost and persisted data cannot be deserialized
and used.

h2. Acceptance Criteria
# All metadata changes are persisted when persistence is enabled.
# On full cluster restart persisted metadata is used.
# Meaning of compactFooter flag may be reconsidered in persistence enabled case.

h2. Performance and Durability Concerns
# As persisting metadata to disk requires IO activity, it must be properly handled in metadata
exchange protocol as it is executed from discovery thread (must never be blocked on IO).
Changes to protocol may be required.
# Possible metadata conflicts must be taken into account as nodes with differences in persisted
metadata may be started and stopped in different orders.
Other corner cases may arise here.

  was:
h2. Notes
Roughly speaking current model of binary metadata handling has two modes: compactFooter on
and off, flag to switch is available at *IgniteConfiguration#BinaryConfiguration#compactFooter*
configuration setting.

If compact footer is on (default configuration) than metadata isn't persisted anywhere even
if persisting of caches content is enabled (see IGNITE-5267 for more details about persistence
feature in Ignite).
Thus after full cluster restart all metadata gets lost and persisted data cannot be deserialized
and used.

h2. Acceptance Criteria
# All metadata changes are persisted when persistence is enabled.
# On full cluster restart persisted metadata is used.

h2. Performance and Durability Concerns
# As persisting metadata to disk requires IO activity, it must be properly handled in metadata
exchange protocol as it is executed from discovery thread (must never be blocked on IO).
Changes to protocol may be required.
# Possible metadata conflicts must be taken into account as nodes with differences in persisted
metadata may be started and stopped in different orders.
Other corner cases may arise here.


> Binary metadata is persisted when persistence is enabled
> --------------------------------------------------------
>
>                 Key: IGNITE-5499
>                 URL: https://issues.apache.org/jira/browse/IGNITE-5499
>             Project: Ignite
>          Issue Type: Task
>          Components: persistence
>            Reporter: Sergey Chugunov
>             Fix For: 2.2
>
>
> h2. Notes
> Roughly speaking current model of binary metadata handling has two modes: compactFooter
on and off, flag to switch is available at *IgniteConfiguration#BinaryConfiguration#compactFooter*
configuration setting.
> If compact footer is on (default configuration) than metadata isn't persisted anywhere
even if persisting of caches content is enabled (see IGNITE-5267 for more details about persistence
feature in Ignite).
> Thus after full cluster restart all metadata gets lost and persisted data cannot be deserialized
and used.
> h2. Acceptance Criteria
> # All metadata changes are persisted when persistence is enabled.
> # On full cluster restart persisted metadata is used.
> # Meaning of compactFooter flag may be reconsidered in persistence enabled case.
> h2. Performance and Durability Concerns
> # As persisting metadata to disk requires IO activity, it must be properly handled in
metadata exchange protocol as it is executed from discovery thread (must never be blocked
on IO).
> Changes to protocol may be required.
> # Possible metadata conflicts must be taken into account as nodes with differences in
persisted metadata may be started and stopped in different orders.
> Other corner cases may arise here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message