[jira] [Commented] (RATIS-279) Create administrative API for a log stream
[
https://issues.apache.org/jira/browse/RATIS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639252#comment-16639252
]
Sergey Soldatov commented on RATIS-279:
---
bq. Overall looks good.
Well. I have some questions.
{code}
LogService logService =
LogServiceFactory.getInstance().createLogService(raftClient);
{code}
Qs: What is this LogService? Is it client that performs all operations? If so,
why we need a factory for that and why we shuld provide raftClient? How we
would create that raftClient in the real world? What is the groupId? What are
the peers?
{code}
LogStream logStream = logService.createLog(logName);
{code}
Qs: Well, we create a log. Where? On the current quorum? Or we create a log in
the state machine?
{code}
logService.getLog(logName);
assertEquals("log1", logStream.getName().getName());
{code}
Qs: We get the log. What does that mean? And how it's related to the next
assertion?
{code}
logStream = logService.listLogs().next();
{code}
Qs: Well, yet agaion - what is the LogService. Is it a client? Is it a service
(according to the name it's a service, but well, where is the client in that
case???).
Now about the state machine. I don't understand how it's supposed to work in
the real world. What are those requests 'createLog',
'deleteLog' ? What it should do in the state machine? At the beginning (when
there are literally nothing in the RaftServer) we create a raft group and the
corresponding StateMachine. And this pair {color:red}is{color} the Log
implementation where we may write and read. I can understand operations like
getState or close. But completely don't understand createLog, listLogs. Those
operations just don't belong to the Log. They are the part of the meta data
operations.
IMHO the operations with log(s) should look like:
{code}
LogServiceAdmin admin =
LogServiceAdmin.newBuilder().setMasterQuorum("host1:,host2:,host3:).build();
Log log1 = admin.createLog("log1");
try {
Log log2 = admin.getLog("log2");
} catch(LogNotFoundException e) {
}
LogReadStream readStream = log1.getReadStream();
LogWriteStream writeStream = log1.getWriteStream();
//or
log1.append(message);
log1.readAt(100);
log1.getLength();
{code}
And what actually would happen inside of admin.createLog("log1") (that's the
part of the code I'm working on) :
1. create the raft client for 'meta' quorum
2. send the message 'createLog' to 'meta' quorum. 'meta' state machine:
a. find 3 (or n) free available RaftServers (peers)
b. create RaftGroup 'rg' with those peers and unique RaftGroupId 'rgi'
c. call for each of those peers: clientPeer.groupAdd(rg, peer)
d. create a client for each of those peers with the rgi group id and call
clientPeer2.setConfiguration(peers)
e. wait for the leader election in the new quorum
f. persist the map between log name and 'rg' (that would be used for
'getLog' calls)
g. returns 'rg' back
3. Log 'log1' stores 'rg' internally as well as creates the raft client that
would read/write from this quorum (and that's the raft client from your code)
> Create administrative API for a log stream
> --
>
> Key: RATIS-279
> URL: https://issues.apache.org/jira/browse/RATIS-279
> Project: Ratis
> Issue Type: Sub-task
> Components: LogService
>Reporter: Josh Elser
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Attachments: RATIS-279_WIP.patch, RATIS-279_v2.patch,
> RATIS-279_v3.patch, RATIS-279_v4.patch, RATIS-279_v5.patch
>
>
> We need to do basic things like:
> * List all log streams
> * Delete a log stream
> * Truncate a log stream
> This may overlap with functionality that actually should live in HBase.
> Making that distinction is part of the tasks of this issue.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RATIS-274) Read/Write-path of log stream state machine
[
https://issues.apache.org/jira/browse/RATIS-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639202#comment-16639202
]
Josh Elser commented on RATIS-274:
--
{code:java}
+ /**
+ * Gets Raft client object
+ * @return raft client object
+ */
+ RaftClient getRaftClient();{code}
I'm hesitant about having RaftClient in our API. (rhetorical) Are we use that
Ratis is going to keep this stable? Glancing at the rest of the patch, couldn't
we hide this on the implementation?
{code:java}
+ private CompletableFuture processSyncRequest(TransactionContext trx,
+ SyncRequestMessage logMessage) {
+
+//TODO really need this?
+takeSnapshot();
+return CompletableFuture.completedFuture(new SyncReplyMessage(null));
+
+ }{code}
Yeah, this doesn't really make sense, does it? Every action should already be
"synced" after it is visible in the statemachine. I was originally thinking
about this in regards to the group-commit we'll want in HBase, but now I'm not
so sure what it's giving us here.
{code:java}
--- /dev/null
+++ b/ratis-proto/src/main/proto/LogService.proto{code}
Any reason to not keep this in the ratis-logservice module? I can help with the
pom changes if necessary.
{code:java}
+case CLOSE:
+ return processCloseRequest(trx,
(CloseRequestMessage)logMessage);{code}
I gave the suggestion to Rajesh in RATIS-279 that we try to separate out these
DDL operations from the DML operations via an interface, in hopes of keeping
you and he from stepping on each other. Do you see a better way?
Mentioned this on RATIS-279 too: a visitor pattern to eliminate the switch
statements for RPC dispatch would be nice.
Do you want to try to split this up and commit in smaller chunks or keep
building, Vlad? Looks like you're on a good path.
> Read/Write-path of log stream state machine
> ---
>
> Key: RATIS-274
> URL: https://issues.apache.org/jira/browse/RATIS-274
> Project: Ratis
> Issue Type: Sub-task
> Components: LogService
>Reporter: Josh Elser
>Assignee: Vladimir Rodionov
>Priority: Major
> Attachments: RATIS-274-v1.patch
>
>
> Implement the ability to read/write data to a log stream.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RATIS-279) Create administrative API for a log stream
[
https://issues.apache.org/jira/browse/RATIS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639183#comment-16639183
]
Josh Elser commented on RATIS-279:
--
{code:java}
+package org.apache.ratis.logservice;
+
+public class LogServiceImpl implements LogService {{code}
Should we put implementation classes into their own java package (e.g.
o.a.ratis.logservice.impl)?
{code:java}
+message LogServiceRequestProto {
+ oneof Request {
+LogMessage logMessage = 1;
+CreateLogRequestProto createLog = 2;
+ListLogsRequestProto listLogs = 3;
+GetLogRequestProto getLog = 4;
+CloseLogRequestProto closeLog = 5;
+GetStateRequestProto getState = 6;
+ArchiveLogRequestProto archiveLog = 7;
+DeleteLogRequestProto deleteLog = 8;
+ }
+{code}
If you agree with me that splitting up the DDL methods (e.g. list, create,
delete) from the DML methods (e.g. write, read), I think it would also make
sense to split up the protobuf messages too.
{code:java}
+final CLUSTER cluster = newCluster(NUM_PEERS);
+cluster.start();
+RaftTestUtil.waitForLeader(cluster){code}
{code:java}
+cluster.shutdown();{code}
Move these into Before and After annotated methods, respectively?
Overall looks good. Will need to put heads together with [~vrodionov] to make
sure we're not stepping on each other. Heading over to his patch now..
> Create administrative API for a log stream
> --
>
> Key: RATIS-279
> URL: https://issues.apache.org/jira/browse/RATIS-279
> Project: Ratis
> Issue Type: Sub-task
> Components: LogService
>Reporter: Josh Elser
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Attachments: RATIS-279_WIP.patch, RATIS-279_v2.patch,
> RATIS-279_v3.patch, RATIS-279_v4.patch, RATIS-279_v5.patch
>
>
> We need to do basic things like:
> * List all log streams
> * Delete a log stream
> * Truncate a log stream
> This may overlap with functionality that actually should live in HBase.
> Making that distinction is part of the tasks of this issue.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RATIS-279) Create administrative API for a log stream
[
https://issues.apache.org/jira/browse/RATIS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639180#comment-16639180
]
Josh Elser commented on RATIS-279:
--
{code:java}
+ switch (logServiceRequestProto.getRequestCase()) {
+ case LOGMESSAGE:
+ case CREATELOG:
+ return processCreateLogRequest(logServiceRequestProto);
+ case LISTLOGS:
+ return processListLogsRequest();
+ case GETLOG:
+ return processGetLogRequest(logServiceRequestProto);
+ case GETSTATE:
+ return processGetStateRequest(logServiceRequestProto);
+ case ARCHIVELOG:
+return processArchiveLog(logServiceRequestProto);
+ case CLOSELOG:
+return processCloseLog(logServiceRequestProto);
+ case DELETELOG:
+return processDeleteLog(logServiceRequestProto);
+ default:
+return null;{code}
Any chance we can convert this into some kind of Visitor pattern in which we
can rely on the argument type to dispatch this to the right method? (and avoid
the massive enum)
{code:java}
diff --git
a/ratis-logservice/src/test/java/org/apache/ratis/logservice/TestLogServiceWithGrpc.java
b/ratis-logservice/src/test/java/org/apache/ratis/logservice/TestLogServiceWithGrpc.java
new file mode 100644
index 000..f7219b0
--- /dev/null
+++
b/ratis-logservice/src/test/java/org/apache/ratis/logservice/TestLogServiceWithGrpc.java
@@ -0,0 +1,7 @@
+package org.apache.ratis.logservice;
+
+import org.apache.ratis.grpc.MiniRaftClusterWithGrpc;
+
+public class TestLogServiceWithGrpc extends
LogServiceBaseTest
+implements MiniRaftClusterWithGrpc.FactoryGet {
+}{code}
This might be a "bigger" thing than just down here in log service, but it would
be nice for Ratis to provide a base test class that uses the JUnit
Parameterized feature instead of forcing us to create "empty" classes like this
to test netty and grpc support. Maybe I spin this out into a new Jira issue?
{code:java}
+ case CREATELOG:
+ return processCreateLogRequest(logServiceRequestProto);
+ case LISTLOGS:
+ return processListLogsRequest();
...
+ case GETSTATE:
+ return processGetStateRequest(logServiceRequestProto);
+ case ARCHIVELOG:
+return processArchiveLog(logServiceRequestProto);
+ case CLOSELOG:
+return processCloseLog(logServiceRequestProto);
+ case DELETELOG:
+return processDeleteLog(logServiceRequestProto);{code}
These would eventually be going to a the "metadata service", right? So, these
will eventually be lifted into a different state machine. Might make it easier
to transition if we have an interface for these methods (might also help avoid
conflicts with Vlad). What do you think?
> Create administrative API for a log stream
> --
>
> Key: RATIS-279
> URL: https://issues.apache.org/jira/browse/RATIS-279
> Project: Ratis
> Issue Type: Sub-task
> Components: LogService
>Reporter: Josh Elser
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Attachments: RATIS-279_WIP.patch, RATIS-279_v2.patch,
> RATIS-279_v3.patch, RATIS-279_v4.patch, RATIS-279_v5.patch
>
>
> We need to do basic things like:
> * List all log streams
> * Delete a log stream
> * Truncate a log stream
> This may overlap with functionality that actually should live in HBase.
> Making that distinction is part of the tasks of this issue.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RATIS-335) Move ratis-hadoop-shaded to thirdparty
[ https://issues.apache.org/jira/browse/RATIS-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved RATIS-335. -- Resolution: Fixed Fix Version/s: 0.3.0 Super delayed, but finally pushed. Deployed a new SNAPSHOT of thirdparty to Nexus too. Should be able to work on a release now. > Move ratis-hadoop-shaded to thirdparty > -- > > Key: RATIS-335 > URL: https://issues.apache.org/jira/browse/RATIS-335 > Project: Ratis > Issue Type: Task > Components: thirdparty >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: 0.3.0 > > Attachments: RATIS-335.001.patch, RATIS-335.002.patch, > RATIS-335.core-change.patch > > > [~vrodionov] pointed out that ratis-hadoop-shaded still shows errors in the > IDE. This is due to the same reason that ratis-proto showed errors. > Let me lift this over to ratis-thirdparty too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RATIS-339) ServerState logging should have groupId information
Sergey Soldatov created RATIS-339: - Summary: ServerState logging should have groupId information Key: RATIS-339 URL: https://issues.apache.org/jira/browse/RATIS-339 Project: Ratis Issue Type: Sub-task Reporter: Sergey Soldatov At the moment all ServerState messages such as Leader changed don't have any information about the group id and when several quorums are working on the same nodes the log looks quite confusing and it's not clear for which group the node was elected as a leader. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-279) Create administrative API for a log stream
[
https://issues.apache.org/jira/browse/RATIS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638547#comment-16638547
]
Hadoop QA commented on RATIS-279:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
38s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
5s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
47s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
41s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 41s{color} |
{color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 41s{color}
| {color:red} root in the patch failed. {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
0m 14s{color} | {color:orange} root: The patch generated 31 new + 26 unchanged
- 6 fixed = 57 total (was 32) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
32s{color} | {color:red} root generated 16 new + 0 unchanged - 0 fixed = 16
total (was 0) {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 7m 2s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 13m 6s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | ratis.server.simulation.TestRaftWithSimulatedRpc |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/ratis:date2018-10-04
|
| JIRA Issue | RATIS-279 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12940663/RATIS-279_v2.patch |
| Optional Tests | asflicense javac javadoc unit findbugs checkstyle
compile cc |
| uname | Linux 825a93c7ea9c 3.13.0-153-generic #203-Ubuntu SMP Thu Jun 14
08:52:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-RATIS-Build/yetus-personality.sh
|
| git revision | master / e35d954 |
| Default Java | 1.8.0_181 |
| mvninstall |
https://builds.apache.org/job/PreCommit-RATIS-Build/371/artifact/out/patch-mvninstall-root.txt
|
| compile |
https://builds.apache.org/job/PreCommit-RATIS-Build/371/artifact/out/patch-compile-root.txt
|
| cc |
https://builds.apache.org/job/PreCommit-RATIS-Build/371/artifact/out/patch-compile-root.txt
|
| javac |
https://builds.apache.org/job/PreCommit-RATIS-Build/371/artifact/out/patch-compile-root.txt
|
| checkstyle |
https://builds.apache.org/job/PreCommit-RATIS-Build/371/artifact/out/diff-checkstyle-root.txt
|
| javadoc |
https://builds.apache.org/job/PreCommit-RATIS-Build/371/artifact/out/diff-javadoc-javadoc-root.txt
|
| unit |
[jira] [Updated] (RATIS-279) Create administrative API for a log stream
[ https://issues.apache.org/jira/browse/RATIS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla updated RATIS-279: -- Attachment: RATIS-279_v5.patch > Create administrative API for a log stream > -- > > Key: RATIS-279 > URL: https://issues.apache.org/jira/browse/RATIS-279 > Project: Ratis > Issue Type: Sub-task > Components: LogService >Reporter: Josh Elser >Assignee: Rajeshbabu Chintaguntla >Priority: Major > Attachments: RATIS-279_WIP.patch, RATIS-279_v2.patch, > RATIS-279_v3.patch, RATIS-279_v4.patch, RATIS-279_v5.patch > > > We need to do basic things like: > * List all log streams > * Delete a log stream > * Truncate a log stream > This may overlap with functionality that actually should live in HBase. > Making that distinction is part of the tasks of this issue. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-279) Create administrative API for a log stream
[ https://issues.apache.org/jira/browse/RATIS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638363#comment-16638363 ] Rajeshbabu Chintaguntla commented on RATIS-279: --- [~elserj] Added the APIs with client request and responses. Added the test cases to verify the same and they are working fine. Please review. Ping [~vrodionov] [~sergey.soldatov]. > Create administrative API for a log stream > -- > > Key: RATIS-279 > URL: https://issues.apache.org/jira/browse/RATIS-279 > Project: Ratis > Issue Type: Sub-task > Components: LogService >Reporter: Josh Elser >Assignee: Rajeshbabu Chintaguntla >Priority: Major > Attachments: RATIS-279_WIP.patch, RATIS-279_v2.patch, > RATIS-279_v3.patch, RATIS-279_v4.patch, RATIS-279_v5.patch > > > We need to do basic things like: > * List all log streams > * Delete a log stream > * Truncate a log stream > This may overlap with functionality that actually should live in HBase. > Making that distinction is part of the tasks of this issue. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RATIS-336) LeaderState.isBootStrappingPeer may have NPE
[
https://issues.apache.org/jira/browse/RATIS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638290#comment-16638290
]
Shashikant Banerjee commented on RATIS-336:
---
The patch looks good to me . I am +1 on this.
> LeaderState.isBootStrappingPeer may have NPE
>
>
> Key: RATIS-336
> URL: https://issues.apache.org/jira/browse/RATIS-336
> Project: Ratis
> Issue Type: Bug
> Components: server
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
>Priority: Major
> Attachments: r336_20181001.patch
>
>
> {code}
> //LeaderState
> boolean isBootStrappingPeer(RaftPeerId peerId) {
> return inStagingState() && getStagingState().contains(peerId);
> }
> boolean inStagingState() {
> return stagingState != null;
> }
>
> ConfigurationStagingState getStagingState() {
> return stagingState;
> }
> {code}
> Since stagingState is volatile, it could be set to null between
> inStagingState() and contains(..).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RATIS-336) LeaderState.isBootStrappingPeer may have NPE
[
https://issues.apache.org/jira/browse/RATIS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638279#comment-16638279
]
Mukul Kumar Singh commented on RATIS-336:
-
Thanks for the updated patch [~szetszwo]. The latest patch look good to me. I
will commit this shortly
> LeaderState.isBootStrappingPeer may have NPE
>
>
> Key: RATIS-336
> URL: https://issues.apache.org/jira/browse/RATIS-336
> Project: Ratis
> Issue Type: Bug
> Components: server
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
>Priority: Major
> Attachments: r336_20181001.patch
>
>
> {code}
> //LeaderState
> boolean isBootStrappingPeer(RaftPeerId peerId) {
> return inStagingState() && getStagingState().contains(peerId);
> }
> boolean inStagingState() {
> return stagingState != null;
> }
>
> ConfigurationStagingState getStagingState() {
> return stagingState;
> }
> {code}
> Since stagingState is volatile, it could be set to null between
> inStagingState() and contains(..).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (RATIS-337) In RaftServerImpl, leaderState/heartbeatMonitor may be accessed without proper null check
[
https://issues.apache.org/jira/browse/RATIS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shashikant Banerjee updated RATIS-337:
--
Comment: was deleted
(was: Thanks [~szetszwo] for the patch. The patch does not apply anymore. Can
you please rebase?)
> In RaftServerImpl, leaderState/heartbeatMonitor may be accessed without
> proper null check
> -
>
> Key: RATIS-337
> URL: https://issues.apache.org/jira/browse/RATIS-337
> Project: Ratis
> Issue Type: Bug
> Components: server
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
>Priority: Major
> Attachments: r337_20181002.patch
>
>
> leaderState/heartbeatMonitor is declared as volatile. Some code like below
> won't work since leaderState may be set to null in between.
> {code:java}
> //RaftServerImpl.checkLeaderState(..)
> } else if (leaderState == null || !leaderState.isReady()) {
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RATIS-337) In RaftServerImpl, leaderState/heartbeatMonitor may be accessed without proper null check
[
https://issues.apache.org/jira/browse/RATIS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638267#comment-16638267
]
Shashikant Banerjee commented on RATIS-337:
---
Thanks [~szetszwo] for the patch. The patch does not apply anymore. Can you
please rebase?
> In RaftServerImpl, leaderState/heartbeatMonitor may be accessed without
> proper null check
> -
>
> Key: RATIS-337
> URL: https://issues.apache.org/jira/browse/RATIS-337
> Project: Ratis
> Issue Type: Bug
> Components: server
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
>Priority: Major
> Attachments: r337_20181002.patch
>
>
> leaderState/heartbeatMonitor is declared as volatile. Some code like below
> won't work since leaderState may be set to null in between.
> {code:java}
> //RaftServerImpl.checkLeaderState(..)
> } else if (leaderState == null || !leaderState.isReady()) {
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RATIS-279) Create administrative API for a log stream
[ https://issues.apache.org/jira/browse/RATIS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla updated RATIS-279: -- Attachment: (was: RATIS-279_v4.patch) > Create administrative API for a log stream > -- > > Key: RATIS-279 > URL: https://issues.apache.org/jira/browse/RATIS-279 > Project: Ratis > Issue Type: Sub-task > Components: LogService >Reporter: Josh Elser >Assignee: Rajeshbabu Chintaguntla >Priority: Major > Attachments: RATIS-279_WIP.patch, RATIS-279_v2.patch, > RATIS-279_v3.patch > > > We need to do basic things like: > * List all log streams > * Delete a log stream > * Truncate a log stream > This may overlap with functionality that actually should live in HBase. > Making that distinction is part of the tasks of this issue. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RATIS-279) Create administrative API for a log stream
[ https://issues.apache.org/jira/browse/RATIS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla updated RATIS-279: -- Attachment: RATIS-279_v4.patch > Create administrative API for a log stream > -- > > Key: RATIS-279 > URL: https://issues.apache.org/jira/browse/RATIS-279 > Project: Ratis > Issue Type: Sub-task > Components: LogService >Reporter: Josh Elser >Assignee: Rajeshbabu Chintaguntla >Priority: Major > Attachments: RATIS-279_WIP.patch, RATIS-279_v2.patch, > RATIS-279_v3.patch, RATIS-279_v4.patch > > > We need to do basic things like: > * List all log streams > * Delete a log stream > * Truncate a log stream > This may overlap with functionality that actually should live in HBase. > Making that distinction is part of the tasks of this issue. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
