You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Konstantin Dudkov (JIRA)" <ji...@apache.org> on 2017/10/02 15:03:00 UTC
[jira] [Commented] (IGNITE-5849) Introduce ignite node persistent
meta-store
[ https://issues.apache.org/jira/browse/IGNITE-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188260#comment-16188260 ]
Konstantin Dudkov commented on IGNITE-5849:
-------------------------------------------
Ilya, thanks for your review
* MetadataStorage - refactor, rename to IndexStorage and make subtype of MetaStorage.
renamed, but they now have completely different logic, so I find no way to make a relation
* Validate that cache with name "MetaStorage" cannot be created with meaningful error message. Also validate memory policy name.
done
* MetaStorage put/remove - can we avoid synchronization at this level? CacheDataStore works without it.
afaik CacheDataStore methods are called from CacheDataStore under the entry lock
* MetaStorage.getOrAllocateMetas() - looks like copy/paste. Refactor?
* MetaStorage.FreeListImpl.getRow(...) - looks like it does the same work as CacheDataRowAdapter.initFromLink(...). Reuse existing code, it already has fragmentation handling.
* MetaStorage.start(...) - rename to init() or something else. Start(...) implicitly requires that stop(...) method also exists.
done
* DataPageIO - reuse it for MetaStorage, skip unneeded fragments.
I put all common code to AbstractDataPageIO
* GridCacheDatabaseSharedManager.getMetastoreData() - unused method? .start0() - commented code?
removed
* IgniteCacheDatabaseSharedManager.addMemoryPolicy(...) and createPageEvictionTracker(...) - why protected?
they are called from outside
> Introduce ignite node persistent meta-store
> -------------------------------------------
>
> Key: IGNITE-5849
> URL: https://issues.apache.org/jira/browse/IGNITE-5849
> Project: Ignite
> Issue Type: New Feature
> Components: persistence
> Affects Versions: 2.1
> Reporter: Alexey Goncharuk
> Assignee: Konstantin Dudkov
> Labels: important
> Fix For: 2.4
>
>
> As persistence feature is being developed, we will have a need for a component, which reliably stores arbitrary metadata about node and cluster.
> We already have reserved partition IDs for this purpose, all we need to do is to extend the partition store abstraction to store non-cache objects and make sure this new store participates in all common recovery procedures.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)