1. 26 Mar, 2019 3 commits
  2. 25 Mar, 2019 2 commits
  3. 24 Mar, 2019 3 commits
  4. 23 Mar, 2019 2 commits
  5. 22 Mar, 2019 5 commits
  6. 21 Mar, 2019 4 commits
  7. 20 Mar, 2019 11 commits
  8. 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
  9. 18 Mar, 2019 4 commits