[FAB-17523] Endorsing peer was not honoring RequiredPeerCount #716
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cendhu
reviewed
Feb 24, 2020
gossip/privdata/distributor.go
Outdated
| // With the shift to per peer dissemination in FAB-15389, we must first check | ||
| // that there are enough eligible peers to satisfy RequiredPeerCount. | ||
| if (len(eligiblePeers)) < colAP.RequiredPeerCount() { | ||
| return nil, fmt.Errorf("required to disseminate to at least %d peers, but know of only %d eligible peers", colAP.RequiredPeerCount(), len(eligiblePeers)) |
There was a problem hiding this comment.
We seem to have a good set of methods to ensure that pvtData is never lost and also the block commit performance is not impacted.
- PvtData should be disseminated to the
requiredPeerCountnumber of peers. Otherwise, the endorsement is rejected (fixed by this PR). - As per the collection's endorsement policy, by default, the PvtData is replicated across the transient stores.
- If a peer does not find PvtData in the transient store during the commit time, it would fetch from other peers. If the peer could not fetch the required pvtData from any other peers, it would record that particular pvtData is missing and proceed with the commit. Later, the reconciler fetches the missing pvtData from other peers.
- Most BaaS platforms also provide HA — one from IBP https://cloud.ibm.com/docs/blockchain-sw?topic=blockchain-sw-ibp-console-ha
As there could be duplicate communications (i.e., every endorser disseminating the pvt data even to the peer which already has the pvtData -- happens when there are multiple endorsers), such an approach in WAN could be bad for the performance. Anyway, this needs to be benchmarked to see whether it is really a problem. If we find this to be a problem, we can keep track of the previous senders and reduce the number of dissemination (for the future).
There was a problem hiding this comment.
I think the onus is on the admin to configure requiredPeerCount and maxPeerCount depending on the endorsement policy to avoid duplicate transmissions.
There was a problem hiding this comment.
Makes sense. I'm looking forward to your private data perf test results.
If there were not enough known eligible peers to meet a private data collection RequiredPeerCount, endorsement was succeeding rather than returning an error. This was a regression caused by FAB-15389 in v1.4.4. FAB-15389 shifted entirely to per-peer dissemination where required peers were tagged up front before dissemination, however there was no overall check to ensure that RequiredPeerCount was met. Prior to FAB-15389, the check was handled deeper in the gossip dissemination. Gossip still checks that each selected required peer disseminates the private data. This fix adds the overall RequiredPeerCount check for cases where there are not enough known eligible peers. Also, improvements are made to variable names, error messages, and comments to make dissemination code easier to understand. Signed-off-by: David Enyeart <enyeart@us.ibm.com>
manish-sethi
approved these changes
Feb 24, 2020
manish-sethi
pushed a commit
that referenced
this pull request
Feb 24, 2020
…729) If there were not enough known eligible peers to meet a private data collection RequiredPeerCount, endorsement was succeeding rather than returning an error. This was a regression caused by FAB-15389 in v1.4.4. FAB-15389 shifted entirely to per-peer dissemination where required peers were tagged up front before dissemination, however there was no overall check to ensure that RequiredPeerCount was met. Prior to FAB-15389, the check was handled deeper in the gossip dissemination. Gossip still checks that each selected required peer disseminates the private data. This fix adds the overall RequiredPeerCount check for cases where there are not enough known eligible peers. Also, improvements are made to variable names, error messages, and comments to make dissemination code easier to understand. Signed-off-by: David Enyeart <enyeart@us.ibm.com>
manish-sethi
pushed a commit
that referenced
this pull request
Feb 25, 2020
…733) If there were not enough known eligible peers to meet a private data collection RequiredPeerCount, endorsement was succeeding rather than returning an error. This was a regression caused by FAB-15389 in v1.4.4. FAB-15389 shifted entirely to per-peer dissemination where required peers were tagged up front before dissemination, however there was no overall check to ensure that RequiredPeerCount was met. Prior to FAB-15389, the check was handled deeper in the gossip dissemination. Gossip still checks that each selected required peer disseminates the private data. This fix adds the overall RequiredPeerCount check for cases where there are not enough known eligible peers. Also, improvements are made to variable names, error messages, and comments to make dissemination code easier to understand. Signed-off-by: David Enyeart <enyeart@us.ibm.com>
C0rWin
pushed a commit
to C0rWin/fabric
that referenced
this pull request
Sep 15, 2020
…edger#716) (hyperledger#733) If there were not enough known eligible peers to meet a private data collection RequiredPeerCount, endorsement was succeeding rather than returning an error. This was a regression caused by FAB-15389 in v1.4.4. FAB-15389 shifted entirely to per-peer dissemination where required peers were tagged up front before dissemination, however there was no overall check to ensure that RequiredPeerCount was met. Prior to FAB-15389, the check was handled deeper in the gossip dissemination. Gossip still checks that each selected required peer disseminates the private data. This fix adds the overall RequiredPeerCount check for cases where there are not enough known eligible peers. Also, improvements are made to variable names, error messages, and comments to make dissemination code easier to understand. Signed-off-by: David Enyeart <enyeart@us.ibm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Type of change
Description
If there were not enough known eligible peers to meet a private data
collection RequiredPeerCount, endorsement was succeeding rather
than returning an error.
This was a regression caused by FAB-15389 in v1.4.4.
FAB-15389 shifted entirely to per-peer dissemination where required
peers were tagged up front before dissemination, however there was
no overall check to ensure that RequiredPeerCount was met. Prior
to FAB-15389, the check was handled deeper in the gossip dissemination.
Gossip still checks that each selected required peer disseminates
the private data.
This fix adds the overall RequiredPeerCount check for cases where
there are not enough known eligible peers.
Also, improvements are made to variable names, error messages, and
comments to make dissemination code easier to understand.
Related issues
https://jira.hyperledger.org/browse/FAB-17523
Signed-off-by: David Enyeart enyeart@us.ibm.com