1. 23 Mar, 2019 2 commits
  2. 22 Mar, 2019 5 commits
  3. 21 Mar, 2019 4 commits
  4. 20 Mar, 2019 11 commits
  5. 19 Mar, 2019 6 commits
    • Matthew Sykes's avatar
      [FAB-14709] update orderer sample configuration · 999a1b39
      Matthew Sykes authored
      Change-Id: I07833487adc9ee26a0058192247ffd17536fb7a1
      Signed-off-by: default avatarMatthew Sykes <sykesmat@us.ibm.com>
    • David Enyeart's avatar
      [FAB-14698] Update fabric to baseimage 0.4.15 · 1e4c3eff
      David Enyeart authored
      Change-Id: Idf90487ecc145bc0213d355a7d4b6e6c3f7770b8
      Signed-off-by: default avatarDavid Enyeart <enyeart@us.ibm.com>
    • Jason Yellick's avatar
    • yacovm's avatar
      [FAB-14697] Piggyback orderer metadata signature · 1a7b3262
      yacovm authored
      This change set makes the orderer include the:
      - Last config block
      - Consensus metadata
      In the same value that is used as the block signature value,
      and this way it paves a way for orderers to be able to sign
      both the block and the last config and the consensus metadata
      in one signature invocation.
      Change-Id: If5f331a7f7e859251af221937f2a3259e615369f
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
    • yacovm's avatar
      [FAB-14691] Add to msgStore and puller atomically · c00203f8
      yacovm authored
      When adding a block to the message store, if it is added and
      not rejected - it is then added to the block puller.
      When the block is removed from the message store, a callback
      is triggered to remove the block from the block puller.
      However, these 2 operations are not atomic.
      Since we can add a block to the message store from both AddToMsgStore
      (which is invoked by Gossip() ) and from HandleMessage,
      we can have the following schedule:
        1) A block with sequence of 100 is gossiped by the upper
          layer of the peer, and AddToMsgStore is called, which
          adds the block to the message store, and the CPU is preempted.
        2) A block message 210 is received via HandleMessage and it causes
           the block 100 to be evicted from the message store, and the
          callback to remove the message from the block puller is called,
          but it is not removed because it is not there yet.
        3) The block 210 is added to the block puller, since it was added
           to the message store.
        4) The CPU is back to perform AddToMsgStore, and adds block 100
           to the block puller.
      Now the block puller has block 100, and the message store doesn't
      have block 100 anymore - which means it will never be evicted from
      the block puller.
      To prevent this we need to make these 2 operations be atomic.
      Change-Id: I3b7d0d013ce8da5d9a0e40f8b0cdbc3edaed22c9
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
    • Yacov Manevich's avatar
  6. 18 Mar, 2019 4 commits
  7. 17 Mar, 2019 4 commits
    • yacovm's avatar
      [FAB-14690] Debug logs in gossip pull · c51d6a90
      yacovm authored
      This change set adds some more debug logs in the gossip pull
      for blocks.
      Change-Id: I9f2d3609c2ba5aba3e06d3741c061ce6e7bc90f0
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
      (cherry picked from commit ceef61fb282e645dc2b6b5d043ef5b45b7e41ffe)
    • Artem Barger's avatar
    • Jason Yellick's avatar
      FAB-14094 Clarify implicitmeta error message · 00df45f9
      Jason Yellick authored
      This CR replaces the old rather opaque and unclear:
       Failed to reach implicit threshold of 1 sub-policies: required 1 \
       implicit policy evaluation failed - 0 sub-policies were satisfied, \
        but this policy requires 1 of the 'Readers' sub-policies to be \
      Although the message is a bit verbose, and likely could be made to be
      even clearer, this attempts to strike a reasonable balance between
      verbosity, and information leakage about policy structures to users
      which are unauthorized and might simply be attempting to probe the
      system for information on membership, etc.
      Change-Id: Icd53e4438117936ca7254d08040e9fad27e24163
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
    • yacovm's avatar
      [FAB-14688] Check inner, not outer block msg · ed8f4f87
      yacovm authored
      The gossip code that handles pull block data updates
      has an optimization that first performs a simulation
      of adding an inner block message to the message store,
      and only if the simulation is successful  -
      it then verifies the message.
      The problem is that the simulation is done against the outer
      message, and thus the optimization does not occur.
      This change set fixes this.
      Change-Id: I71c94e9b1cad2bfa6e9cfce700d8bd3209e9b5e7
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
  8. 16 Mar, 2019 2 commits
    • yacovm's avatar
      [FAB-14687] Only add to puller if needed · ede53fc6
      yacovm authored
      The gossip channel's method AddToMsgStore adds a block message
      to both the block store and to the block puller.
      However, it can be that the message isn't added to the block store
      due to it being too old.
      In such a case we must not add it to the block puller, because it is evicted
      by the invalidation trigger of the block store which is programmed to
      remove it from the block puller.
      Change-Id: I64e7f4e64a337df5593a58a5d52a821b376b2bfb
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
    • Jay Guo's avatar
      FAB-14593 Refine etcdraft parameters · 2a4e15e9
      Jay Guo authored
      - MaxInflightMsgs is internal to etcd/raft and should be exposed
      to users with a more appropriate name: MaxInflightBlocks
      - MaxSizePerMsg is also internal to etcd/raft, and it's defaulted
      to PreferredMaxBytes in BatchSize, so that if a big block is created,
      it is sent in a its own etcd/raft message, instead of being batched
      with other blocks. This parameter takes effect when a batch of entries
      is sent to lagged node. During normal replication, each block is
      sent in its own message.
        It's not necessary to expose this config option to users.
      - SnapInterval is renamed to SnapshotIntervalSize
      FAB-14593 #done
      Change-Id: Icaf2848a41c5f0f0a02f4b0b4a80ba852fddd584
      Signed-off-by: default avatarJay Guo <guojiannan1101@gmail.com>
  9. 15 Mar, 2019 2 commits