Help Center/ Blockchain Service/ FAQs/ Enhanced Hyperledger Fabric/ Data Storage to the Blockchain/ What Can I Do When Transaction Connections Fail or Time Out?
Updated on 2023-03-01 GMT+08:00
View PDF
Share

What Can I Do When Transaction Connections Fail or Time Out?

Symptom

Transaction connections fail or time out.

Fault Locating

Check item 1: Check whether the transaction times out after the chaincode is instantiated for the first time.

Check item 2: Check whether the instance status is abnormal.

Check item 3: Check whether the Fabric SDK version used by the client matches the BCS instance version.

Check item 4: Check whether the ledger of the peer is updated.

Check item 5: Check whether the DB file exists.

Check item 6: If a BCS instance uses CouchDB of an earlier version for ledger storage, check whether BCS becomes unavailable after CouchDB restarts.

Check item 7: Check whether data can be stored to blockchain even though the request initiated from a blockchain client has timed out.

Solution

  • Check item 1: Check whether the transaction times out after the chaincode is instantiated for the first time.

    During chaincode instantiation of a v3.0.x BCS instance (corresponding to Fabric v1.4.0), the container of only one peer in each organization is started. Other peer containers are built and started at the first transaction endorsement. This process takes a long time, and the transaction may time out.

    Figure 1 Transaction times out

    If you use a Go SDK, this problem does not need to be handled. The SDK will wait for the chaincode container to start, and no timeout will occur.

    If you use a Java SDK, you can set req.setProposalWaitTime(), the timeout for a request to endorse, in your application. In the following figure, the timeout is set to 60 seconds to avoid transaction failure after the chaincode is instantiated for the first time.

    Figure 2 Transaction fails
  • Check item 2: Check whether the instance is abnormal.

    Log in to the BCS console and rectify the fault based on the instance status by following instructions provided in What Can I Do If a BCS Instance Is in the Abnormal State?

  • Check item 3: Check whether the Fabric SDK version used by the client matches the BCS instance version.

    Log in to the BCS console, go to the Instance Management page, and click the abnormal instance to view its version.

    Record the value of Version. Check whether the Fabric SDK version used by the client is the same as the BCS version. If the versions are inconsistent, transactions may fail or time out.

    Solution

    Download the Fabric SDK of the version that corresponds to the Hyperledger Fabric version of BCS.

    Download link: https://github.com/hyperledger/fabric

  • Check item 4: Check whether the ledger of the peer is updated.
    1. Log in to the BCS console. In the navigation pane, click Instance Management. On the card containing the abnormal instance, click Manage Blockchain. On the Block Browser page, select the abnormal channel, and view the block quantity on the Block List tab page.
      Figure 3 Block List page
    2. Log in to the ECS where the blockchain is deployed, run the docker ps|grep k8s_peer command to check the peer containers, and record the ID of the container where transactions time out.
      Figure 4 Checking the peer containers
    3. Run the docker exec -it Container ID /bin/bash command to access the container.
      Figure 5 Accessing the container
    4. Run the peer channel list command to query the channel to which the peer is added.
      Figure 6 Querying the channel to which the peer is added
    5. Run the peer channel getinfo -c {Channel name} command to check whether the ledger of the peer is updated.
      Figure 7 Checking whether the ledger of the peer is updated

      If the block quantity in the ledger of the peer is different from that displayed on the Block Browser page, query the block quantity again after 10 minutes. If the block quantity keeps unchanged, the ledger of the peer is not updated due to insufficient resources or high concurrency. As a result, transactions become abnormal.

    6. If the problem persists, submit a service ticket. In the upper right corner of the console, choose Service Tickets > Create Service Ticket. Specify the issue as required.
  • Check item 5: Check whether the DB file exists.
    1. Log in to the ECS where the blockchain is deployed, run the docker ps|grep k8s_peer command to check the peer containers, and record the ID of the container where transactions are abnormal.
      Figure 8 Checking the peer containers
    2. Run the docker exec -it Container ID /bin/bash command to access the container.
      Figure 9 Accessing the container
    3. Run the cd /var/log/baas-service/peer/ command to go to the directory where the logs of the peer are stored, and run the ll command to view all files.
      Figure 10 Viewing all files
    4. Obtain the hash value and sequence number of the peer.

      On the Block Browser page of the Blockchain Management console, view the domain name and sequence number of the peer in the Domain of Peer column in the Peer Status list.

      Figure 11 Peer Status list
    5. The peer log file is named in the following format: peer-{Hash value}-{Serial number}.trace. Run cat {File name}|grep -C 5 "Fail to recover DB: file does not exist" to search for exception information.

      If you see Fail to recover DB: file does not exist, the DB file of the peer does not exist. As a result, transactions are abnormal.

    6. If the problem persists, submit a service ticket. In the upper right corner of the console, choose Service Tickets > Create Service Ticket. Specify the issue as required.
  • Check item 6: If a BCS instance uses CouchDB of an earlier version for ledger storage, check whether BCS becomes unavailable after CouchDB restarts.

    If CloudDB is used for ledger storage for an instance of an earlier version, the status data is not stored in the SFS file system. If BCS is restarted, CouchDB will reload the block data to generate the status data, and BCS will be unavailable for a certain period of time.

    It takes about 2 hours to synchronize data of 150,000 blocks. During data synchronization, port 7051 of the peer cannot be accessed.

    Solution:

    1. Upgrade the BCS instance to the latest version to avoid this problem when you perform upgrade or restart.

      When a BCS instance is upgraded to the latest version for the first time, the CouchDB container mounts the web disk and synchronizes status data. As a result, the BCS instance is unavailable for a certain period of time. This duration increases linearly as the block quantity increases. It takes about 2 hours to synchronize data for every 150,000 blocks. The block quantity can be viewed on the Block Browser page of the Blockchain Management console.

    2. Log in to the BCS console. Choose More > Upgrade on the instance card.
    3. In the dialog box that is displayed, view the current instance version or upgrade the BCS instance to the latest version.
      • Instances are unavailable during version upgrade. In a consortium, if your blockchain upgrades, all consortium blockchains must also upgrade. Reach an agreement with consortium members before you perform upgrade to eliminate effects on their blockchains.
      • Do not initiate version upgrade when the chaincode is being installed or instantiated.
      • You can upgrade BCS from the version corresponding to Hyperledger Fabric v1.4 to the version corresponding to Hyperledger Fabric v2.2. If a blockchain in the consortium has upgraded, all consortium blockchains must also upgrade to the same version to ensure successful transactions.
      • BCS v4.x.x corresponds to Hyperledger Fabric v2.2.
      • You can only upgrade BCS from an earlier version to a later version. Rollback is supported only if the upgrade fails.
  • Check item 7: Check whether data can be stored to blockchain even though the request initiated from a blockchain client has timed out.

    If the error message request timed out or been cancelled is displayed on the client and UTC is more than 15mos apart from current server time is displayed in the organization node logs, ensure that the time and time zone of the client are the same as those of the organization node.