This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

VMware Blockchain 1.3.0.2 | 14 SEP 2021 | Build 80

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. The patch release includes the following upgrade and fix:

VMware Blockchain Platform is upgraded to the 1.3.0.2 version.

Fixed a problem that prevented Client nodes from resynchronizing data when the data size was greater than 2GB

The problem stopped Client nodes from resynchronizing data from the Replica nodes when the data was greater than 2GB and the data folder was removed due to data corruption. Therefore, any .dar file uploads caused the Client node DAML Ledger API to fail.

Component Versions

The supported domain versions include:

Domain Version
VMware Blockchain Platform 1.3.0.2 Build 80
VMware Blockchain Orchestrator 1.3.0.1 Build 73
DAML SDK 1.14.1

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 Consideration

  • When you upgrade from VMware Blockchain 1.3.0.1 to 1.3.0.2, 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.
  • When you upgrade from VMware Blockchain 1.2.0.2 to 1.3.0.2, implement the clone-based upgrade process. See the Perform Clone-Based Upgrade instructions in the Using and Managing VMware Blockchain Guide.

Resolved Issues

  • Client nodes are unable to resynchronize data when the data size is greater than 2GB

    Client nodes cannot resynchronize data from the Replica nodes when the data is greater than 2GB and the data folder is removed due to data corruption. Therefore, any .dar file uploads cause the Client node DAML Ledger API to fail.

  • Replica node pruning requires 256GB memory allocation for the pruning process to function without failure

    With 500,000 transactions or higher, 256GB memory allocation is required for Replica node pruning to execute successfully. Conversely, transactions that are less than 500,000 might succeed with a memory allocation of less than 256GB.

  • Upgrade from VMware Blockchain version 1.1 to 1.2 requires special consideration

    Special consideration is required when upgrading from VMware Blockchain 1.1 to 1.2. Contact your Blockchain support engineer.

  • Concord containers crash after a long-running continuous load

    In certain situations during a continuous-running load when using the expression Assert: expression '!isFetching(), Concord containers might exit, causing the Blockchain nodes to be down and out of the quorum.

  • In rare instances, the Concord containers are unable to start after failing due to metadata inconsistency

    Replica nodes might crash, leaving an inconsistent state between blocks and metadata. Replica nodes recover when the mismatch only affects a single block. In workloads when the mismatch spans multiple blocks and block accumulation is deactivated, the Replica node fails to start with the following error message in the logs: Detected more than one block needs to be deleted from the blockchain - unsupported.

  • Replica nodes crash during pruning of large data

    In certain circumstances, when there are many thin replica clients, there is high activity on the TRS gRPC channel resulting in a memory consumption problem that causes the Replica nodes to crash during the pruning operation.

  • Concord container health metrics service is not available and displays an error message

    Concord container health metrics service displays an error message for an otherwise healthy Concord container. The agent container logs show the following error message: Concord health check will not be unavailable.

Known Issues

  • DAML package uploads and Ledger configuration submissions with the same submission_id might cause conflict in the DAML Ledger API's index database, rendering the Client node to become unresponsive

     In certain situations, uploading DAML packages or setting the Ledger time model with a previously used submission_id can cause the Client node to become unresponsive. These operation changes can be executed only by Client node administrators with JSON Web Token containing the admin claim. See the DAML documentation, Access tokens and claims.

    Workaround: Use UUIDs as submission_id for all the DAML package uploads and Ledger configuration submissions. For DAML package uploads, if the UUID is left blank, the Ledger API generates a unique identifier for the submission_id.

  • The audit.log file overflows, causing the VMware Blockchain node VM to run out of storage space and make the environment unstable

     The /etc/audit/auditd.conf system file has a duplicate entry for max_log_file_action, one entry is ROTATE, and another entry is IGNORE. The duplicate entry values prevent log rotation and trigger the audit.log file to overflow.

    Workaround: Complete the following tasks:

    1. Open the /etc/audit/auditd.conf file on a VMware Blockchain node VM.
    2. Delete the entry, max_log_file_action = IGNORE.
    3. Repeat the deletion process on all the Replica and Client node VMs.

  • 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.

check-circle-line exclamation-circle-line close-line
Scroll to top icon