-
Notifications
You must be signed in to change notification settings - Fork 1
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
INGITE-14406 #3
Conversation
...src/main/java/org/apache/ignite/runner/internal/storage/DistributedConfigurationStorage.java
Show resolved
Hide resolved
...unner/src/main/java/org/apache/ignite/runner/internal/storage/LocalConfigurationStorage.java
Show resolved
Hide resolved
modules/runner/src/main/java/org/apache/ignite/runner/internal/app/IgnitionImpl.java
Outdated
Show resolved
Hide resolved
...src/main/java/org/apache/ignite/runner/internal/storage/DistributedConfigurationStorage.java
Outdated
Show resolved
Hide resolved
|
||
version.incrementAndGet(); | ||
|
||
listeners.forEach(listener -> listener.onEntriesChanged(new Data(newValues, version.get(), 0))); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
...unner/src/main/java/org/apache/ignite/runner/internal/storage/LocalConfigurationStorage.java
Outdated
Show resolved
Hide resolved
/** Map to store values. */ | ||
private TreeMap<String, Value> storage = new TreeMap<>(); | ||
|
||
private final Object mux = new Object(); |
There was a problem hiding this comment.
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.
...src/main/java/org/apache/ignite/runner/internal/storage/DistributedConfigurationStorage.java
Show resolved
Hide resolved
@@ -0,0 +1,2 @@ | |||
# Ignite vault module | |||
This module provides Vault API implementation. |
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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
...src/main/java/org/apache/ignite/runner/internal/storage/DistributedConfigurationStorage.java
Show resolved
Hide resolved
modules/vault/src/main/java/org/apache/ignite/internal/vault/VaultManager.java
Show resolved
Hide resolved
/** | ||
* Representation of vault entry. | ||
*/ | ||
public class Value implements Serializable { |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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())); |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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)));
7edc042
to
93a41cb
Compare
@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) { |
There was a problem hiding this comment.
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))); |
There was a problem hiding this comment.
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"; |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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))); |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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<>(); |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
81b147c
to
84a63be
Compare
84a63be
to
bdb77c0
Compare
Signed-off-by: ibessonov <bessonov.ip@gmail.com>
Signed-off-by: ibessonov <bessonov.ip@gmail.com>
Signed-off-by: ibessonov <bessonov.ip@gmail.com>
Signed-off-by: ibessonov <bessonov.ip@gmail.com>
Signed-off-by: ibessonov <bessonov.ip@gmail.com>
No description provided.