Roman Puchkovskiy created IGNITE-16120:
------------------------------------------

             Summary: Return real page size if encryption is configured for a 
region even when keys are not injected yet
                 Key: IGNITE-16120
                 URL: https://issues.apache.org/jira/browse/IGNITE-16120
             Project: Ignite
          Issue Type: Improvement
          Components: cache
    Affects Versions: 2.13
            Reporter: Roman Puchkovskiy
            Assignee: Roman Puchkovskiy


When encryption is enabled for a region in the configuration, 
PageMemory#realPageSize(int) returns a value reduced by some encryption-related 
data overhead. For instance, currently, when full page size (returned by 
PageMemory#pageSize()) is 4096, #realPageSize(int) returns 4064.

But #realPageSize(int) starts returning the 'real' realPageSize only when it 
has some keys for the provided group ID. The injection of keys happens on node 
join. The following comment explains why:

//We can't store keys before node join to cluster(on statically configured 
cache registration).
//Because, keys should be received from cluster.
//Otherwise, we would generate different keys on each started node.
//So, after starting, coordinator saves locally newly generated encryption keys.
//And sends that keys to every joining node.

This means that for short period of time (before the keys are injected) 
#realPageSize(int) returns full page size (4096); this happens when allocating 
pages with metadata for caches preconfigured in the region configuration, for 
example. These pages are initialized with wrong page size. Currently, this page 
size is not used for these pages during initialization, but in the future this 
might cause some problem.

My suggestion is to try remove this gap.
 # First of all, for the preconfigured groups (listed in IgniteConfiguration 
which is accessible to PageMemoryImpl constructor) we don't need to wait for 
keys injection: we just have the list of these groups
 # Another option (probably better) would be to employ some event system to 
mark a group as encrypted before it gets created. If such a mechanism exists :) 
If not, maybe it's not that hard to implement it.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to