Tags: chain/Core
Tags
core: allow block period to be configured Some applications may want to change the block frequency based on their traffic patterns. For example, a value of 250 milliseconds (a factor of four) improved performance in one application we observed. This variable can set to any value that can be parsed by https://golang.org/pkg/time/#ParseDuration such as `250ms`.
sdk/java: version 1.1.4 with TLS 1.2 default Closes #1339
cmd/cored: tick version to 1.1.5 Closes #1340
cmd/cored: tick version to 1.1.5 Closes #1340
sdk/java: version 1.2.1 with TLS 1.2 default Closes #1341
database/raft: wait for ConfChange to be applied When adding a new node to the cluster, wait for the conf change to be committed and applied before taking a state snapshot and responding to the new node. Previously, Join had a race condition between the application of the conf change entry and the taking of the snapshot. If the snapshot was taken before the conf change was committed or applied, the new node would try to boot its state machine from a state that did not include itself in the configuration. It could mistakeningly think that it is a single-node cluster and try to elect itself, panicking when its node id doesn't exist in the progress list: See issue #1330. Waiting for the conf change to be applied ensures that: * The /raft/join endpoint only returns if adding the node to the cluster was committed. * The snapshot returned from the /raft/join endpoint includes the new node in its configuration. This is a backport fix for the 1.2.x release line. Closes #1335
database/raft: wait for ConfChange to be applied When adding a new node to the cluster, wait for the conf change to be committed and applied before taking a state snapshot and responding to the new node. Previously, Join had a race condition between the application of the conf change entry and the taking of the snapshot. If the snapshot was taken before the conf change was committed or applied, the new node would try to boot its state machine from a state that did not include itself in the configuration. It could mistakeningly think that it is a single-node cluster and try to elect itself, panicking when its node id doesn't exist in the progress list: See issue #1330. Waiting for the conf change to be applied ensures that: * The /raft/join endpoint only returns if adding the node to the cluster was committed. * The snapshot returned from the /raft/join endpoint includes the new node in its configuration. This is a backport fix for the 1.2.x release line. Closes #1335
database/raft: wait for ConfChange to be applied When adding a new node to the cluster, wait for the conf change to be committed and applied before taking a state snapshot and responding to the new node. Previously, Join had a race condition between the application of the conf change entry and the taking of the snapshot. If the snapshot was taken before the conf change was committed or applied, the new node would try to boot its state machine from a state that did not include itself in the configuration. It could mistakeningly think that it is a single-node cluster and try to elect itself, panicking when its node id doesn't exist in the progress list: See issue #1330. Waiting for the conf change to be applied ensures that: * The /raft/join endpoint only returns if adding the node to the cluster was committed. * The snapshot returned from the /raft/join endpoint includes the new node in its configuration. This is a backport fix for the 1.2.x release line. Closes #1335
PreviousNext