1. 28 Jul, 2017 1 commit
    • Jason Yellick's avatar
      [FAB-5525] Fix configtx memory allocation bug · b3c14300
      Jason Yellick authored
      
      
      The configtx code uses an 'append(...)' against a slice, and records the
      new slice address when computing the config map.  Through sheer dumb
      luck, this code works for config groups which are only nested 2 levels
      deep, because the append call triggers a true new memory allocation.
      However, for config groups 3 levels deep (such as consortium groups),
      the append call actually re-uses the underlying memory for the slice.
      
      This causes the path to be corrupted internally for the consortium group
      items, and cause the wrong policy to be resolved when checking for a
      policy which has been specified relatively.
      
      This fix manually allocates new memory, copies it, and then appends the
      element.
      
      Change-Id: I0f4df619e006cdfebba60173156bda597d42a544
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      b3c14300
  2. 27 Jul, 2017 8 commits
  3. 26 Jul, 2017 15 commits
  4. 25 Jul, 2017 6 commits
    • Jason Yellick's avatar
      [FAB-5459] Recompute configmap instead of updating · 6eab9cf6
      Jason Yellick authored
      
      
      The configtx validation code works by transforming the ConfigGroup tree
      structure into a map, where each config element has a fully qualified
      key like:
      
        [Groups] /Channel/Application
      
      or
      
        [Policy] /Channel/Application/Readers
      
      This flattened structure makes it easier to check which elements have
      been modified, as the maps may simply be iterated over, rather than
      walking the config tree.
      
      After applying a config update, the current config map is copied, and
      the elements which were updated are overlayed onto the old config.  This
      map is then converted back into a tree structure and serialized to be
      the new config tree.
      
      The current code adopts the updated config map as the current config
      map.  However, this produces the bug described in 5459.  Because the
      updated config map is the overlay of the new config onto the old
      config, the updated config may contain orphaned nodes which appear in
      the map, but which do not appear in the config tree.
      
      Consequently, when a subsequent update arrives, it is validated not
      only against the current config, but also against the orphaned nodes
      which are still in the updated config map.
      
      This CR changes the logic to discard the updated config map (which may
      contain this orphaned nodes) and instead has the config map recomputed
      every time a new config is adopted.  This is more obviously
      deterministic and mimics the way a new ordering node would initialize
      the config after being restarted.
      
      Note: There is no accompanying test case with this.  I had originally
      written a test case which demonstrated that nodes were orphaned in the
      updated config.  However, this is expected and not a useful test case.
      Similarly, forcing the update config map to have updated nodes, then
      testing that that map is not adopted does not provide a valuable test
      case.
      
      So, instead of a test, this CR opts for some code comments and this
      lengthly commit explaining the change.
      
      Change-Id: Idc847cd5e237531e4a8b978f3465e30a909eb94f
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      6eab9cf6
    • Will Lahti's avatar
      [FAB-5391]Prevent concurrent invokes launching cc cont · 2232d0ec
      Will Lahti authored
      
      
      This CR prevents concurrent invokes from launching a chaincode
      container at the same time (e.g. during performance testing). The first
      invoke should succeed (and launch the container) while subsequent
      invokes should fail until the container has finished launching.
      
      Note: This does not change any behavior as subsequent invokes should
      have failed but it now sends a clear error message that the chaincode
      container is already launching.
      
      Change-Id: Ic1772a5f25dd0e4c34278e6e7bdb8507f16269c8
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
      2232d0ec
    • Jay Guo's avatar
      [FAB-5236] Add orderer benchmark tests. · f83e0b3b
      Jay Guo authored
      
      
      Change-Id: Ib255d0f1601864bdaac9e6e272fa2fdc89b4f76b
      Signed-off-by: default avatarJay Guo <guojiannan1101@gmail.com>
      f83e0b3b
    • Gari Singh's avatar
    • Jay Guo's avatar
      [FAB-5236] System channel ID should be configurable · 452c7eb8
      Jay Guo authored
      
      
      System channel ID is hardcoded to 'testchainid' when using provisional
      genesis method. This should be configurable so that we could run multiple
      tests against a stateful service, e.g. Kafka, without cleaning up the
      environment after each run. Otherwise, after the first run, later ones
      would recognize 'testchainid' and recover states from it. Also, we meant
      to deprecate this hardcoded manner anyway.
      
      Note: this is for testing purpose only, so we don't expose it in the
      orderer config yaml.
      
      Change-Id: I60590f52c304e003e3dd74c27aa0f3bec3bb996a
      Signed-off-by: default avatarJay Guo <guojiannan1101@gmail.com>
      452c7eb8
    • Jason Yellick's avatar
      [FAB-5416] Remove bad common.Configuration doc · f9922518
      Jason Yellick authored
      
      
      The configtxlator doc references the common.Configuration type which
      does not exist.  Instead, it intends to refer to common.Config.
      
      This CR fixes this in both the rst and the md.
      
      Change-Id: I10bf0b6013e81411006c53b548afd7060021bac0
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      f9922518
  5. 24 Jul, 2017 6 commits
  6. 23 Jul, 2017 2 commits
  7. 22 Jul, 2017 2 commits
    • Artem Barger's avatar
      [FAB-5353]: Qualify sys. failure vs validation error · 0cf4c35a
      Artem Barger authored
      
      
      Currently as stated in [FAB-5353], there is no clear separation during
      transaction validation during block commmit, between invalid transaction
      and some system failure which migh lead to inability to validate the
      transaction. For example db is down or file system is unavailable. This
      might lead to inconsistency of the state accross peers, therefore this
      commit takes care to distinguish between real case of invalid
      transaction versus system failure, later the error propagated down to
      the committer and forces peer to stop with panic, so admin will be able
      to take manual control and fix the problem therefore preventing peer
      state to diverge.
      
      Change-Id: I384e16d37e2f2b0fe144d504f566e0b744a5095c
      Signed-off-by: default avatarArtem Barger <bartem@il.ibm.com>
      0cf4c35a
    • Christopher Ferris's avatar
      3a4b1f2b