Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

INGITE-14406 #3

Closed
wants to merge 7 commits into from
Closed

INGITE-14406 #3

wants to merge 7 commits into from

Conversation

alievmirza
Copy link

No description provided.


version.incrementAndGet();

listeners.forEach(listener -> listener.onEntriesChanged(new Data(newValues, version.get(), 0)));

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here should be metastorage watches instead of direct call listeners.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, according to current design it's not valid to trigger and process configuration listeners within write tread, only watch processing thread is expected.


listeners.forEach(listener -> listener.onEntriesChanged(new Data(newValues, version.get(), 0)));

return CompletableFuture.completedFuture(true);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The final future should aggregate from metastorage futures.

/** Map to store values. */
private TreeMap<String, Value> storage = new TreeMap<>();

private final Object mux = new Object();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can to make all methods synchronized with a similar success.

@@ -0,0 +1,2 @@
# Ignite vault module
This module provides Vault API implementation.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest, this description is very concise :)

<dependency>
<groupId>org.rocksdb</groupId>
<artifactId>rocksdbjni</artifactId>
<version>6.6.4</version>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All versions must be placed at parent/pom.xml

/**
* Representation of vault entry.
*/
public class Value implements Serializable {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need revision for all values including local values (value of a local property/key)?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I planned to have revisions for all values, but local values would have revision equals to -1, for example

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Vse ravno neponiatno, zachem?

HashMap<String, Serializable> data = new HashMap<>();

for (Entry entry : cur)
data.put(entry.key().toString().replace(DISTRIBUTED_PREFIX + ".", ""), (Serializable)SerializationUtils.fromBytes(entry.value()));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems that replace isn't safe enough cause entry.key().toString() could also have DISTRIBUTED_PREFIX + "." somewhere in the middle in addition to prefix.

data.put(entry.key().toString().replace(DISTRIBUTED_PREFIX + ".", ""), (Serializable)SerializationUtils.fromBytes(entry.value()));

// storage revision 0?
return new Data(data, version.get(), 0);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure whether storageRevision is metastorage revision or key updateCounter. In any case it won't be 0 here. it'll be max revision or updateCounter that we saw within all entries that match rrange(new Key(DISTRIBUTED_PREFIX + "."), new Key(DISTRIBUTED_PREFIX + (char)('.' + 1)));

@Override public CompletableFuture<Boolean> write(Map<String, Serializable> newValues, long version) {
return null;
/** {@inheritDoc} */
@Override public synchronized CompletableFuture<Boolean> write(Map<String, Serializable> newValues, long sentVersion) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please clarify, why we need sentVersion?


version.incrementAndGet();

listeners.forEach(listener -> listener.onEntriesChanged(new Data(newValues, version.get(), 0)));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, according to current design it's not valid to trigger and process configuration listeners within write tread, only watch processing thread is expected.

import org.apache.ignite.metastorage.internal.MetaStorageManager;

public class DistributedConfigurationStorage implements ConfigurationStorage {
// TODO Distributed prefix. Will be replaced when ENUM with configuration type will be presented.
// https://issues.apache.org/jira/browse/IGNITE-14476
private static String DISTRIBUTED_PREFIX = "distributed";
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All keys within metastorage are distributed, I believe that you actually need "public" prefix here.

@Override public CompletableFuture<Boolean> write(Map<String, Serializable> newValues, long version) {
return null;
// storage revision 0?
return new Data(data, version, 0);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand, instead of 0, you should use max revision that was retrieved from range().


version++;

listeners.forEach(listener -> listener.onEntriesChanged(new Data(newValues, version, 0)));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not valid to use 0 here.

/**
* Representation of vault entry.
*/
public class Value implements Serializable {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Vse ravno neponiatno, zachem?

* Representation of vault entry.
*/
public class Value implements Serializable {
private String key;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we need key in Value?

Copy link
Author

@alievmirza alievmirza Apr 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems that we don't need to store value with key in vault and we can store only byte array, but VaultService should return something like Entry in MetastorageService, so I'm going to introduce some kind of VaultEntry wich will be returned in org.apache.ignite.internal.vault.service.VaultService#get, for example

*/
public class VaultServiceImpl implements VaultService {
/** Map to store values. */
private TreeMap<String, Value> storage = new TreeMap<>();
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as mentioned above, why not to reuse Key abstraction from MetaStorage?

return vaultService.appliedRevision(key);
}

public CompletableFuture<Void> put(String key, Value val) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll need multi keys put with applied revision at least in order to commit processed watch notifications and multi keys put without applied revision for local keys.

import java.util.Comparator;
import org.jetbrains.annotations.Nullable;

public class Watch {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not to reuse watch abstraction from DMS?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WatchListener depends on WatchEvent, which depends on Entry, Entry has revision and will have updateCounter in the future. Seems that it is not suitable for Vault as far as Vault don't need to have such fields.

private static final Comparator<String> CMP = CharSequence::compare;

@Nullable
private String startKey;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above, MetaStorage Key suites better here.

@alievmirza alievmirza force-pushed the ignite-14406 branch 2 times, most recently from 81b147c to 84a63be Compare April 21, 2021 08:14
SammyVimes added a commit that referenced this pull request Apr 27, 2021
SammyVimes added a commit that referenced this pull request Apr 29, 2021
SammyVimes added a commit that referenced this pull request May 6, 2021
SammyVimes added a commit that referenced this pull request May 11, 2021
tkalkirill added a commit that referenced this pull request Mar 30, 2022
tkalkirill added a commit that referenced this pull request Mar 30, 2022
tkalkirill added a commit that referenced this pull request Mar 30, 2022
tkalkirill added a commit that referenced this pull request Mar 30, 2022
tkalkirill added a commit that referenced this pull request Mar 31, 2022
tkalkirill added a commit that referenced this pull request Mar 31, 2022
tkalkirill added a commit that referenced this pull request May 26, 2022
tkalkirill added a commit that referenced this pull request May 26, 2022
tkalkirill added a commit that referenced this pull request Jul 19, 2022
korlov42 added a commit that referenced this pull request Aug 26, 2022
korlov42 added a commit that referenced this pull request Sep 22, 2022
korlov42 added a commit that referenced this pull request Sep 30, 2022
tkalkirill added a commit that referenced this pull request Oct 13, 2022
tkalkirill added a commit that referenced this pull request Oct 13, 2022
tkalkirill added a commit that referenced this pull request Oct 13, 2022
korlov42 added a commit that referenced this pull request Oct 19, 2022
korlov42 added a commit that referenced this pull request Oct 19, 2022
tkalkirill added a commit that referenced this pull request Nov 28, 2022
tkalkirill added a commit that referenced this pull request Dec 12, 2022
ibessonov added a commit that referenced this pull request Jan 18, 2023
Signed-off-by: ibessonov <bessonov.ip@gmail.com>
tkalkirill added a commit that referenced this pull request Feb 24, 2023
ibessonov added a commit that referenced this pull request Apr 25, 2023
Signed-off-by: ibessonov <bessonov.ip@gmail.com>
ibessonov added a commit that referenced this pull request Jun 5, 2023
Signed-off-by: ibessonov <bessonov.ip@gmail.com>
ibessonov added a commit that referenced this pull request Jun 27, 2023
Signed-off-by: ibessonov <bessonov.ip@gmail.com>
tkalkirill added a commit that referenced this pull request Sep 8, 2023
tkalkirill added a commit that referenced this pull request Sep 12, 2023
tkalkirill added a commit that referenced this pull request Sep 22, 2023
tkalkirill added a commit that referenced this pull request Sep 22, 2023
tkalkirill added a commit that referenced this pull request Jan 16, 2024
ibessonov added a commit that referenced this pull request Feb 23, 2024
Signed-off-by: ibessonov <bessonov.ip@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants