I have configured hyperledger fabric 1.4 network with 2 organizations with 2 peers under each organization(1 endorsing peer) and 3 orderer. In my configtx.yaml file transaction related parameter are configured as below
OrdererType: etcdraft
Addresses:
- orderer1.example.com:7050
- orderer2.example.com:7050
- orderer3.example.com:7050
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 98 MB
PreferredMaxBytes: 512 KB
previously for commiting the transaction and creating a block it used to take 1-2 seconds but from last week I'm observing it is taking more than 15 seconds. can any one suggest what would be the issue and how to resolve it.
Related
I executed Hyperledger Fabric test network and it had no errors. When I benchmarked its performance with Hyperledger Caliper tool, it was successful. But when the transactions count is increased to 800 or 1000 or above it throws the below error,
2023.02.13-11:49:56.059 error [caliper] [connectors/peer-gateway/PeerGateway] Failed to perform submit transaction [Admin_createPatient] using arguments [Client3_CAR557,Toyota,S,brown,Shotaro,29,123456890], with error: EndorseError: 2 UNKNOWN: too many requests for /gateway.Gateway, exceeding concurrency limit (500)
To rectify the error I changed the value of gatewayService to 2500 from its default value 500, but still the error not rectified.
limits:
concurrency:
# endorserService limits concurrent requests to endorser service that handles chaincode deployment, query and invocation,
# including both user chaincodes and system chaincodes.
endorserService: 2500
# deliverService limits concurrent event listeners registered to deliver service for blocks and transaction events.
deliverService: 2500
# gatewayService limits concurrent requests to gateway service that handles the submission and evaluation of transactions.
gatewayService: 2500
In the error message I assume that it was updated to say 2500 ? If not then the change wasn't picked up. If it was picked up then you will need to increase the value further. The number corresponds to in flight transactions, so you can only have that many transactions submitted and not committed being processed. This should track with the unfinished transaction count that caliper outputs during a benchmark run.
we have done a migration of a Fabric network, from one tenant to another Azure Cloud. The nodes are on three IaaS and we have done a snpashot of them, the network did not stop . So, as a result when we use this snpashots on the new tenant, it looks like the peers have more blocks than the orderers. Orderers have RAFT consensus without problems and update their blocks. But they can't get the latest blocks from the peers.
I can run chaincode, and read values, but cannot insert new transanctions.
There is this error in the peers :
"2023-01-17 13:20:56.933 UTC [peer.blocksprovider] func1 -> WARN 269 Encountered an error reading from deliver stream: EOF channel=test orderer-address=orderer5.example.com:7050
2023-01-17 13:20:56.933 UTC [peer.blocksprovider] DeliverBlocks -> WARN 26a Got error while attempting to receive blocks: received bad status NOT_FOUND from orderer channel=test"
.
and on the orderer: " ERRO 05b [channel: test] Error reading from channel, cause was: NOT_FOUND".
It seems that the peer to request blocks the orderer does not know the channel, but when it starts it detects it and inserts the blocks it had pending from other orderers.
Can the orderers read the missing blocks from the peers, or the only way to start a network from snpashots from different IaaS is to stop the network first?
Here is the log of Hyperledger Fabric test network. There are 2 peer node(peer0.org1.example.com & peer0.org2.example.com) and 2 orderer node(orderer.example.com & orderer2.example.com).
My question is what 「writeBlock」,「StoreBlock」，「Validate」「commit」stage actually does? I know that at 「propose」stage, a chosen orderer(in this case, orderer.example.com) will create a block and then send the created block to other orderer such as orderer2.example.com. However, I don't understand what orderers does at「writeBlock」stage. Do they sign the created block at 「writeBlock」stage? Next, peer nodes received the block from who? orderer.example.com or orderer2.example.com? In my guess, I think it's from orderer.example.com but I'm not sure.
I don't understand what orderers does at「writeBlock」stage.
I'm not sure about those stages (writeBlock looks self-explanatory). I don't know about "StoreBlock", it isn't mentioned in the official docs. I'm wondering which Fabric version you are using.
Next, peer nodes received the block from who?
In a RAFT network you have a leader/follower model. You can think of a leader peer as an entry point/doorman for all communication coming from the ordering nodes. An ordering node sends blocks to the leading peer(s) of each organization; the leading peer is then responsible for distributing those blocks to other peers belonging to the same organization. Distribution is done using gossip protocol.
Hyperledger Fabric is a complex system, with many components and a lot of moving parts.
The log that you are referring to is the log of the orderer node - orderer.example.com. It's a part of the Fabric test network. You can see what's happening in detail by looking at the logs of other Fabric components, such as peer node logs.
The Fabric network has a set of orderer nodes, which are responsible for ordering the transactions and creating blocks in the blockchain.
The orderer nodes are configured to use a consensus algorithm (such as Solo or Kafka) to achieve a consensus about the order of the transactions.
A Fabric network has a set of peer nodes, which are responsible for executing the chaincode (smart contracts) and catching and validating the transactions.
The Fabric test network consists of one orderer node, which is configured to use Solo consensus algorithm. This orderer node is orderer.example.com.
The Fabric test network consists of two peer nodes, which are peer0.org1.example.com and peer0.org2.example.com.
The log that you are referring to is the log of the orderer node - ord
While adding a new organization to the hyper ledger fabric network, the peer logs shows the below error.
[gossip/service] updateAnchors -> ERRO 327 Tried joining channel
mychannel but our org( org4), isn't among the orgs of the channel:
[org1 org2 org3] , aborting.
And a warning like below.
[gossip/gossip] Gossip -> WARN 3d9 Failed obtaining gossipChannel of
[99 104 45 99 111 109 109 111 110] aborting.
Hyper ledger Fabric version : v1.1.0
Dynamic leader election properties added into peer-base.
I was following the instructions here.
Because the peer is being joined with the genesis block (which knows about the original members of the channel, but not the new members), these log statements are emitted.
Usually, these statements will be benign; so long as the peer is able to retrieve and commit blocks, you may ignore these messages. Eventually, the peer will receive the config block which adds its org, and gossip networking will begin working properly again.
This is a known issue, and in the future, we hope to allow peers to be joined to a channel using the latest configuration block, and not only the genesis block.
I built Fabric network using Kafka-based orderer service.
(2 peer, 1 orderer and 4 kafka)
When I invoke a chaincode, below message appears in peer's log.
[gossip/state] queueNewMessage -> WARN 7a24 Failed adding payload: Ledger height is at 5685, cannot enqueue block with sequence of 938
What is this message?
Can I ignore this warning?
This is probably because the second peer's height is much less than the first peer's height, and it (the second peer) pulls from the orderer blocks that the first peer doesn't need, and forwards to it as a token of good will.
The peer logs that he got a block he doesn't need.