[jira] [Updated] (RATIS-101) Use ByteString instead of byte[] in RaftId, ClientId, RaftGroupId and RaftPeerId
[ https://issues.apache.org/jira/browse/RATIS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo Nicholas Sze updated RATIS-101: -- Attachment: r101_20170804.patch r101_20170804.patch: using ByteString > Use ByteString instead of byte[] in RaftId, ClientId, RaftGroupId and > RaftPeerId > > > Key: RATIS-101 > URL: https://issues.apache.org/jira/browse/RATIS-101 > Project: Ratis > Issue Type: Improvement >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > Attachments: r101_20170804.patch > > > - We can avoid copying bytes by using ByteString. > - ByteString is immutable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (RATIS-101) Use ByteString instead of byte[] in RaftId, ClientId, RaftGroupId and RaftPeerId
[ https://issues.apache.org/jira/browse/RATIS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo Nicholas Sze updated RATIS-101: -- Description: - We can avoid copying bytes by using ByteString. - ByteString is immutable. was: - We can avoid copying bytes by using ByteBuffer. - ByteBuffer can be set to readonly. Summary: Use ByteString instead of byte[] in RaftId, ClientId, RaftGroupId and RaftPeerId (was: Use ByteBuffer instead of byte[] in RaftId) Using ByteString seems even better. Revising title and description ... > Use ByteString instead of byte[] in RaftId, ClientId, RaftGroupId and > RaftPeerId > > > Key: RATIS-101 > URL: https://issues.apache.org/jira/browse/RATIS-101 > Project: Ratis > Issue Type: Improvement >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > > - We can avoid copying bytes by using ByteString. > - ByteString is immutable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (RATIS-101) Use ByteBuffer instead of byte[] in RaftId
[ https://issues.apache.org/jira/browse/RATIS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo Nicholas Sze reassigned RATIS-101: - Assignee: Tsz Wo Nicholas Sze > Use ByteBuffer instead of byte[] in RaftId > -- > > Key: RATIS-101 > URL: https://issues.apache.org/jira/browse/RATIS-101 > Project: Ratis > Issue Type: Improvement >Reporter: Tsz Wo Nicholas Sze >Assignee: Tsz Wo Nicholas Sze > > - We can avoid copying bytes by using ByteBuffer. > - ByteBuffer can be set to readonly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (RATIS-101) Use ByteBuffer instead of byte[] in RaftId
Tsz Wo Nicholas Sze created RATIS-101: - Summary: Use ByteBuffer instead of byte[] in RaftId Key: RATIS-101 URL: https://issues.apache.org/jira/browse/RATIS-101 Project: Ratis Issue Type: Improvement Reporter: Tsz Wo Nicholas Sze - We can avoid copying bytes by using ByteBuffer. - ByteBuffer can be set to readonly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (RATIS-100) Test multiple raft groups with a state machine
[
https://issues.apache.org/jira/browse/RATIS-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114945#comment-16114945
]
Tsz Wo Nicholas Sze edited comment on RATIS-100 at 8/4/17 8:36 PM:
---
r100_20170804.patch: adds TestMultiRaftGroup.
Note that the new test may fail due to some existing bug that a RaftServer may
stay in STARTING state fever. Will fix the bug and upload a new patch later.
BTW, this fixes an existing bug that PendingRequests.addPendingRequest(..) may
throw IllegalStateException when addPendingRequest(..) is called right after
addConfRequest(..) since the index in last PendingRequest does not match. This
patch fixes the bug by setting {{last = pendingSetConf}} in addConfRequest(..).
was (Author: szetszwo):
r100_20170804.patch: adds TestMultiRaftGroup.
Note that the new test may fail due to some existing bug that a RaftServer may
stay in STARTING state fever. Will fix the bug and upload a new patch later.
BTW, this fixes an existing bug that PendingRequests.addPendingRequest(..) may
throw IllegalStateException when addPendingRequest(..) is called right after
addConfRequest(..) since the index in last PendingRequest does not match. This
patch fixes the buy by setting {{last = pendingSetConf}} in addConfRequest(..).
> Test multiple raft groups with a state machine
> --
>
> Key: RATIS-100
> URL: https://issues.apache.org/jira/browse/RATIS-100
> Project: Ratis
> Issue Type: Test
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r100_20170804.patch
>
>
> We propose to add a test similar to
> ReinitializationBaseTest.runTestReinitializeMultiGroups(..) with a state
> machine so that it can test if the states are recorded correctly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (RATIS-100) Test multiple raft groups with a state machine
[
https://issues.apache.org/jira/browse/RATIS-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tsz Wo Nicholas Sze updated RATIS-100:
--
Attachment: r100_20170804.patch
r100_20170804.patch: adds TestMultiRaftGroup.
Note that the new test may fail due to some existing bug that a RaftServer may
stay in STARTING state fever. Will fix the bug and upload a new patch later.
BTW, this fixes an existing bug that PendingRequests.addPendingRequest(..) may
throw IllegalStateException when addPendingRequest(..) is called right after
addConfRequest(..) since the index in last PendingRequest does not match. This
patch fixes the buy by setting {{last = pendingSetConf}} in addConfRequest(..).
> Test multiple raft groups with a state machine
> --
>
> Key: RATIS-100
> URL: https://issues.apache.org/jira/browse/RATIS-100
> Project: Ratis
> Issue Type: Test
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r100_20170804.patch
>
>
> We propose to add a test similar to
> ReinitializationBaseTest.runTestReinitializeMultiGroups(..) with a state
> machine so that it can test if the states are recorded correctly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (RATIS-97) Leader may not have majority after setConfiguration
[
https://issues.apache.org/jira/browse/RATIS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114789#comment-16114789
]
Tsz Wo Nicholas Sze commented on RATIS-97:
--
> Therefore I think the {{reinitialize}} API should first take {{RaftGroupId}}
> as its input. ...
Do you mean that the new node only take {{RaftGroupId}} without any members?
Then, they will learn the setConf call when replaying the log? It sounds like
a good idea! Let me change the patch.
> Leader may not have majority after setConfiguration
> ---
>
> Key: RATIS-97
> URL: https://issues.apache.org/jira/browse/RATIS-97
> Project: Ratis
> Issue Type: Bug
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r97_20170728.patch, r97_20170731.patch,
> r97_20170801b.patch, r97_20170801.patch
>
>
> Here is an example: Suppose a group has 3 servers and one of them is the
> leader. Use setConfiguration to add 6 more servers. The leader is still
> running as a leader although it does not has majority anymore. The 6 new
> servers may elect a new leader among them. Finally, there are two leaders in
> the group.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (RATIS-97) Leader may not have majority after setConfiguration
[
https://issues.apache.org/jira/browse/RATIS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114062#comment-16114062
]
Jing Zhao commented on RATIS-97:
Thanks for the patch, Nicholas! Looks like we may have two scenarios here:
# There are old members already in the RaftGroup, and we're adding new members.
For old members this whole change is actually a re-configuration call. The
original leader will understand who are the members in the old/new
configuration. For new members adding to the raft group, initially they only
need to understand that they now should handle requests belonging to this new
raft group (which means they are able to map incoming requests to the
corresponding raft group based on the group id information). Then while the
original leader trying to commit the conf(old, new) entry, these new members
will have the chance to learn all the old/new members in this group. I.e., the
knowledge about the old and new configuration should be learnt through the
conf(old, new) log entry instead of passed from the {{reinitialize}} API.
# We're creating a brand new raft group. In this case we can pass in the
initial raft configuration information through {{reinitialize}} (or a new
{{attendGroup}} API in the future).
Therefore I think the {{reinitialize}} API should first take {{RaftGroupId}} as
its input. Then for scenario #1, we do not need to pass the group member
information in this API. For scenario #2, we pass in the initial members of the
group. What do you think?
> Leader may not have majority after setConfiguration
> ---
>
> Key: RATIS-97
> URL: https://issues.apache.org/jira/browse/RATIS-97
> Project: Ratis
> Issue Type: Bug
>Reporter: Tsz Wo Nicholas Sze
>Assignee: Tsz Wo Nicholas Sze
> Attachments: r97_20170728.patch, r97_20170731.patch,
> r97_20170801b.patch, r97_20170801.patch
>
>
> Here is an example: Suppose a group has 3 servers and one of them is the
> leader. Use setConfiguration to add 6 more servers. The leader is still
> running as a leader although it does not has majority anymore. The 6 new
> servers may elect a new leader among them. Finally, there are two leaders in
> the group.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
