1. 27 Mar, 2019 3 commits
    • David Enyeart's avatar
    • Artem Barger's avatar
      FAB-14838 properly clean IT test resources · d568cc02
      Artem Barger authored
      This commit moves code which takes care to free resources and stop peers
      and orderers processes after the integration test. Also need to make
      sure system channel is actually ready to pull configuration blocks, by
      actually waiting for leader to be selected.
      Change-Id: Iefb37732edbd2b375022190691667700840d2b52
      Signed-off-by: default avatarArtem Barger <bartem@il.ibm.com>
    • Jason Yellick's avatar
      FAB-11863 Assorted Raft serviceability fixes · 5fb1be95
      Jason Yellick authored
      This CR bundles four small serviceability fixes for Raft.
      1) It removes the newlines from a log message which made it difficult to
      consume and appeared to create a truncated list like this:
       INFO 17155f Entering, channel: testorgschannel1, nodes: [ID: 3
      2) It adds periods to all of the metric definitions in the cluster
      3) It converts the message send time in the cluster package to be
      seconds and clarifies the description with the unit 'seconds'.
      4) It clarifies that the number of leader changes is what this process
      has observed since start, and not the total number of leader changes for
      the network.
      Change-Id: Ic4ad6551af57497f174518188022bf4dfd04fc19
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
  2. 26 Mar, 2019 3 commits
  3. 25 Mar, 2019 2 commits
  4. 24 Mar, 2019 3 commits
  5. 23 Mar, 2019 2 commits
  6. 22 Mar, 2019 5 commits
  7. 21 Mar, 2019 4 commits
  8. 20 Mar, 2019 11 commits
  9. 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
  10. 18 Mar, 2019 1 commit