-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
IGNITE-19950 Cache dumps implemented #10950
Conversation
import static org.apache.ignite.internal.pagemem.PageIdAllocator.INDEX_PARTITION; | ||
|
||
/** | ||
* |
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.
Let's collapse it into one line or provide a meaningful Javadoc.
* Regular count of partitions is {@link RendezvousAffinityFunction#DFLT_PARTITION_COUNT} | ||
* and thread is {@link IgniteConfiguration#DFLT_PUBLIC_THREAD_CNT} whic is significantly less. | ||
*/ | ||
private final ConcurrentMap<Long, ByteBuffer> thLocBufs = new ConcurrentHashMap<>(); |
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 still believe that it's better to use some kind of pooled memory allocator here.
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.
For what reason? Can you, please, explain, what is wrong with current approach and how memory allocator will make things better?
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.
https://issues.apache.org/jira/browse/IGNITE-20594?jql=labels%20%3D%20IEP-109 created after private discussion.
.../apache/ignite/internal/processors/cache/persistence/snapshot/dump/CreateDumpFutureTask.java
Outdated
Show resolved
Hide resolved
.../apache/ignite/internal/processors/cache/persistence/snapshot/dump/CreateDumpFutureTask.java
Outdated
Show resolved
Hide resolved
...che/ignite/internal/processors/cache/persistence/wal/reader/StandaloneGridKernalContext.java
Outdated
Show resolved
Hide resolved
* Regular count of partitions is {@link RendezvousAffinityFunction#DFLT_PARTITION_COUNT} | ||
* and thread is {@link IgniteConfiguration#DFLT_PUBLIC_THREAD_CNT} whic is significantly less. | ||
*/ | ||
private final ConcurrentMap<Long, ByteBuffer> thLocBufs = new ConcurrentHashMap<>(); |
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 still believe that it's better to use some kind of pooled memory allocator here.
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.
For what reason? Can you, please, explain, what is wrong with current approach and how memory allocator will make things better?
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.
https://issues.apache.org/jira/browse/IGNITE-20594?jql=labels%20%3D%20IEP-109 created after private discussion.
* @param raw If {@code true} then keep read entries in form of {@link KeyCacheObject} and {@link CacheObject}. | ||
* @param log Logger. | ||
*/ | ||
public Dump(File dumpDir, @Nullable String consistentId, boolean keepBinary, boolean raw, IgniteLogger log) { |
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 Dump
class API doesn't seem consistent to me. #partitions()
, #metadata()
, #iterator()
etc methods require a node
argument, although we have a dedicated constructor to create a node-specific dump.
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.
There are two scenario when we analyzing dump content:
-
User exploring dump content with
DumpReader
. SoDump
provide a way to consume all data saved in dump. -
Ignite checks dump consistency during creation. In this case we don't want to know or even read data belong to other nodes, because, other node can be in the middle of dump creation. That's why we want to have the way to filter out all node except one in constructor.
Note, that Dump
is internal class, so it's not an API
.
.../apache/ignite/internal/processors/cache/persistence/snapshot/dump/CreateDumpFutureTask.java
Outdated
Show resolved
Hide resolved
.../apache/ignite/internal/processors/cache/persistence/snapshot/dump/CreateDumpFutureTask.java
Outdated
Show resolved
Hide resolved
SonarCloud Quality Gate failed. 6 Bugs 0.0% Coverage The version of Java (11.0.20.1) you have used to run this analysis is deprecated and we will stop accepting it soon. Please update to at least Java 17. Catch issues before they fail your Quality Gate with our IDE extension SonarLint |
Thank you for submitting the pull request to the Apache Ignite.
In order to streamline the review of the contribution
we ask you to ensure the following steps have been taken:
The Contribution Checklist
The description explains WHAT and WHY was made instead of HOW.
The following pattern must be used:
IGNITE-XXXX Change summary
whereXXXX
- number of JIRA issue.(see the Maintainers list)
the
green visa
attached to the JIRA ticket (see TC.Bot: Check PR)Notes
If you need any help, please email dev@ignite.apache.org or ask anу advice on http://asf.slack.com #ignite channel.