VMware Blockchain 1.4.0.1 Release Notes

VMware Blockchain 1.4.0.1 | 20 JAN 2022 | Build 137 Check for additions and updates to these release notes.

What's New

VMware Blockchain is an enterprise-grade blockchain platform that meets the needs of business-critical multi-party workflows. This patch release includes the following fixes:

Updated Apache log4j to version 2.17 and Wavefront Proxy to version 10.12 to resolve CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105

For more information on these vulnerabilities and their impact on VMware products, see VMSA-2021-0028.

Component Versions

The supported domain versions include:

Domain	Version
VMware Blockchain Platform	1.4.0.1
VMware Blockchain Orchestrator	1.4.0.1
DAML SDK	1.17.2

_{^{The VMware products and solutions discussed in this document are protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. and its subsidiaries in the United States and other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.}}

Upgrade Considerations

When you upgrade from VMware Blockchain upgrade from 1.3.0.3 to 1.4.0.1 or 1.4 to 1.4.0.1, you can implement the in-place-based upgrade or clone-based upgrade process. See the Perform an In-Place-Based Upgrade or Perform Clone-Based Upgrade instructions in the Using and Managing VMware Blockchain Guide.

Resolved Issues

• New -

  Fixed a problem where the thin replica client metrics were not correctly exposed using Prometheus and therefore were not visible in Wavefront

  The implemented fix displays the thin replica client metrics in Wavefront.
• New -

  Fixed a problem where insufficient memory resources led to the Concord application failing and causing service disruptions

  Insufficient memory resources caused the Concord application to fail, leading to service disruptions such as failed transactions and transactions per second degradation. The implemented fix configures the system to allocate sufficient memory resources for the Concord application by tuning deployment parameters such as the number of Client nodes within a Client node group, Client node batch size, RocksDB cache size, and the maximum number of open files.

• New -

  Fixed memory limits that were not set correctly

  Incorrect memory limits resulted in a substantial amount of memory being allocated to various Concord containers affecting performance. The fix allows proper allocation of memory limits, improving performance. 

• New -

  Fixed a problem where the thin replica client metrics names were prefixed with the stream type and participant ID, causing the metrics to not appear in Wavefront

   The fix updated the Concord-BFT metrics wrapper for Prometheus to support labels for stream type and participant_id, which resulted in the thin replica client metrics appearing in Wavefront as metric names.
• New -

  Fixed a problem that occurred when the Daml Ledger API commands failed during command interpretation due to contention on Contract Key with an error message,Could not find a suitable ledger time after 0 retries

  The fix enables the Daml Ledger API to automatically retry the command interpretation multiple times in instances when a contention error is detected before sending the transaction to Concord, which significantly reduces the likelihood of the error.

Known Issues

• A staggered restart of Replica nodes might cause some nodes into state transfer or, in a rare occurrence, to become non-functional

  When Replica nodes are restarted one after the other, some Replica nodes might enter into state transfer which does not complete. In certain rare circumstances, the blockchain might become non-functional due to the Replica nodes not agreeing to a single view.

  Workaround: Selectively perform a backup and restore on Replica nodes that are stuck in state transfer or on all Replicas in case of non-functional blockchain.

• Using the ActiveContractsService without specifying a template filter to retrieve active contracts is slow on large index databases

  For large databases with more than one billion transaction events recorded in the index database, the query to retrieve all active contracts can take a long time to compute the results and respond to the application. As a result, applications with timeouts around the request to receive all active contracts might run into the timeout and abort the operation.

  Workaround: Applications must provide a template filter for requests to the active contracts service. The template filter guarantees that only necessary and expected data is loaded from the database and transmitted to the application.

• When a deployed VM is created, the VM might not have a private static IP address due to a race condition

  In a rare occurrence, a deployed VM might not have a private static IP address when it is created. The problem occurs due to a race condition in the underlying Photon OS.

  Workaround: Remove the deployed VMware Blockchain node VM and re-deploy the blockchain.