I am running Hyperledger Fabric 1.4.0
I have 1 org (Org1), 2 peers (peer0, peer1) and two orderers (ord0, ord1). The peers use couchdb as a storage backend.
I am able to successfully install my chaincode, then instantiate it.
Looking at peer0 logs, the docker image is built and the container started. peer0 also receives and acknowledges the REGISTER request sent by the chaincode binary within the container:
2019-06-24 10:15:57.003 UTC [dockercontroller] createContainer -> DEBU b563 created container {"imageID": "nid1-peer0-mynet-mychain-v1-613158e6e99c2c9e7d567e8b57fe2dfb56444f7fdcbc263dd1f61626a374843d", "containerID": "nid1-peer0-mynet-mychain-v1"}
2019-06-24 10:15:57.160 UTC [dockercontroller] Start -> DEBU b564 Started container nid1-peer0-mynet-mychain-v1
2019-06-24 10:15:57.160 UTC [container] unlockContainer -> DEBU b565 container lock deleted(mychain-v1)
2019-06-24 10:15:57.181 UTC [chaincode] handleMessage -> DEBU b566 [] Fabric side handling ChaincodeMessage of type: REGISTER in state created
2019-06-24 10:15:57.181 UTC [chaincode] HandleRegister -> DEBU b567 Received REGISTER in state created
2019-06-24 10:15:57.182 UTC [chaincode] Register -> DEBU b568 registered handler complete for chaincode mychain:v1
2019-06-24 10:15:57.182 UTC [chaincode] HandleRegister -> DEBU b569 Got REGISTER for chaincodeID = name:"mychain:v1" , sending back REGISTERED
2019-06-24 10:15:57.182 UTC [chaincode] HandleRegister -> DEBU b56a Changed state to established for name:"mychain:v1"
2019-06-24 10:15:57.182 UTC [chaincode] sendReady -> DEBU b56b sending READY for chaincode name:"mychain:v1"
2019-06-24 10:15:57.182 UTC [chaincode] sendReady -> DEBU b56c Changed to state ready for chaincode name:"mychain:v1"
2019-06-24 10:15:57.182 UTC [chaincode] Launch -> DEBU b56d launch complete
2019-06-24 10:15:57.182 UTC [chaincode] Execute -> DEBU b56e Entry
2019-06-24 10:15:57.182 UTC [chaincode] handleMessage -> DEBU b56f [1a98f442] Fabric side handling ChaincodeMessage of type: COMPLETED in state ready
Despite this, the chaincode is not registered in couchdb:
$ peer chaincode list --instantiated -C mychannel
2019-06-24 11:26:29.317 BST [main] InitCmd -> WARN 001 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2019-06-24 11:26:29.332 BST [main] SetOrdererEnv -> WARN 002 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
Get instantiated chaincodes on channel mychannel:
peer0 logs immediately after submitting the list command:
2019-06-24 10:26:30.057 UTC [couchdb] ReadDocRange -> DEBU c02e [mychannel_lscc] HTTP/1.1 200 OK
Transfer-Encoding: chunked
Cache-Control: must-revalidate
Content-Type: application/json
Date: Mon, 24 Jun 2019 10:26:30 GMT
Server: CouchDB/2.1.1 (Erlang OTP/18)
X-Couch-Request-Id: 20d0beb9c3
X-Couchdb-Body-Time: 0
2a
{"total_rows":0,"offset":0,"rows":[
]}
0
If I try to invoke a method on the chaincode, I get this error:
Error: endorsement failure during invoke. response: status:500 message:"make sure the chaincode mychain has been successfully instantiated and try again: chaincode mychain not found"
which just confirms that the chaincode has not been registered within the network.
Update
I realised I had missed an important detail: the peer logs repeatedly report errors connecting to the orderer, e.g.:
2019-06-24 11:30:35.931 UTC [ConnProducer] NewConnection -> ERRO 100e6 Failed connecting to ord0.mynet.example.com , error: context deadline exceeded
which might be the reason why the "chaincode instantiated" message doesn't get propagated...
After much debugging, it turned out the issue was pretty simple: the peers could not communicate with the orderers.
In my particular case the addresses of the orderers were wrong in configtx.yaml. Fixing them resulted in the chaincode instantiation process tu fully succeed.
Related
I am following the below link which outlines a GO example and runs fine, I am trying to alter it to run a nodejs smart contract.
https://hyperledger-fabric.readthedocs.io/en/latest/peer-chaincode-devmode.html#build-the-chaincode
For GO - works fine
go build -o simpleChaincode ./integration/chaincode/simple/cmd
CORE_CHAINCODE_LOGLEVEL=debug CORE_PEER_TLS_ENABLED=false
CORE_CHAINCODE_ID_NAME=mycc:1.0 ./simpleChaincode -peer.address
127.0.0.1:7052
For Nodejs
cd ./chaincode/asset-transfer-basic/chaincode-typescript
CORE_CHAINCODE_LOGLEVEL=debug CORE_PEER_TLS_ENABLED=false
CORE_CHAINCODE_ID_NAME=$CORE_CHAINCODE_ID_NAME npm run
start:server-debug -peer.address 127.0.0.1:7052
For Nodejs - in the peer logs
# 2022-04-05 16:30:56.427 PDT 013b DEBU [chaincode] CheckInvocation -> [0cda8fd8] getting chaincode data for cscc on channel
# 2022-04-05 16:30:56.427 PDT 013c DEBU [chaincode] Execute -> Entry
# 2022-04-05 16:30:56.428 PDT 013d INFO [ledgermgmt] CreateLedger -> Creating ledger [ch1] with genesis block
# 2022-04-05 16:30:56.429 PDT 013e DEBU [chaincode] handleMessage -> [0cda8fd8] Fabric side handling ChaincodeMessage of type: COMPLETED in state ready
# 2022-04-05 16:30:56.429 PDT 013f DEBU [chaincode] Notify -> [0cda8fd8] notifying Txid:0cda8fd80e6b204e45bfc10716924e689da5a2e50fc5c03de36692e3845a22a9, channelID:
# 2022-04-05 16:30:56.429 PDT 0140 DEBU [chaincode] Execute -> Exit
# 2022-04-05 16:30:56.429 PDT 0141 INFO [endorser] callChaincode -> finished chaincode: cscc duration: 1ms channel= txID=0cda8fd8
# 2022-04-05 16:30:56.429 PDT 0142 INFO [comm.grpc.server] 1 -> unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=127.0.0.1:55599 grpc.code=OK grpc.call_duration=1.393458ms
Below messages for Peer are listed in GO but not in NodeJS
# 2022-04-05 16:30:56.822 PDT 0143 DEBU [chaincode] handleMessage -> [] Fabric side handling ChaincodeMessage of type: REGISTER in state created
# 2022-04-05 16:30:56.822 PDT 0144 DEBU [chaincode] HandleRegister -> Received REGISTER in state created
# 2022-04-05 16:30:56.822 PDT 0145 DEBU [chaincode] Register -> registered handler complete for chaincode mycc:1.0
# 2022-04-05 16:30:56.822 PDT 0146 DEBU [chaincode] HandleRegister -> Got REGISTER for chaincodeID = mycc:1.0, sending back REGISTERED
# 2022-04-05 16:30:56.822 PDT 0147 DEBU [chaincode] HandleRegister -> Changed state to established for mycc:1.0
# 2022-04-05 16:30:56.822 PDT 0148 DEBU [chaincode] sendReady -> sending READY for chaincode mycc:1.0
# 2022-04-05 16:30:56.822 PDT 0149 DEBU [chaincode] sendReady -> Changed to state ready for chaincode mycc:1.0
When I try to invoke the Nodejs chaincode
CORE_PEER_ADDRESS=127.0.0.1:7051 peer chaincode invoke -o
127.0.0.1:7050 -C ch1 -n $CC_NAME -c '{"Args":["InitLedger"]}' --isInit
I receive the below error which indicates that the peer is expecting the chaincode to installed in peer, but for devmode it should happen automatically.
Error: endorsement failure during invoke. response: status:500 message:"error in simulation: failed to execute transaction edd6e811393cf4938a02b8d7773be85e57b5053ab5bfb2b38c06e8f88044d340: could not launch chaincode mycc-node:1.0: error building chaincode: error building image: failed to get chaincode package for external build: could not get legacy chaincode package 'mycc-node:1.0': open /var/hyperledger/production/chaincodes/mycc-node.1.0: no such file or directory"
Any suggestions or guidance will be greatly appreciated.
Thanks
Currently I am using Hyperledger Fabric 1.4, and I am trying to modify the basic-network. I am trying to add an org2 with one peer. Whenever I try to invoke the chaincode from the peer on the second organization (Org2) I get the following error:
Error: Error endorsing chaincode: rpc error: code = Unknown desc = access denied: channel [] creator org [Org2MSP]
My current network components are:
org1, with two peers
org2, with one peer
CA1
CA2
Ordere
CLI
and a channel called "mychannel"
I am able to create the channel "mychannel" and join the 3 peers from the two organizations. Also, I am able to install the chaincode on three of the peers from both organizations. And I am instantiating the chaincode on peer0 in Org1
Part of the Ordere logs:
2019-05-13 13:17:42.384 UTC [fsblkstorage] newBlockfileMgr -> INFO 003 Getting block information from block storage
2019-05-13 13:17:42.970 UTC [orderer.commmon.multichannel] Initialize -> INFO 004 Starting system channel 'testchainid' with genesis block hash f1bcfe55588bd24faaa699bc740045455283b63950436a36d5cf473f4b3d8f81 and orderer type solo
2019-05-13 13:17:42.970 UTC [orderer.common.server] Start -> INFO 005 Starting orderer:
Version: 1.4.1
Commit SHA: 87074a7
Go version: go1.11.5
OS/Arch: linux/amd64
2019-05-13 13:17:42.970 UTC [orderer.common.server] Start -> INFO 006 Beginning to serve requests
2019-05-13 13:21:30.921 UTC [comm.grpc.server] 1 -> INFO 007 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Broadcast grpc.peer_address=172.20.0.6:36544 grpc.code=OK grpc.call_duration=27.428231ms
2019-05-13 13:21:30.927 UTC [fsblkstorage] newBlockfileMgr -> INFO 008 Getting block information from block storage
2019-05-13 13:21:31.038 UTC [orderer.commmon.multichannel] newChain -> INFO 009 Created and starting new chain mychannel
2019-05-13 13:21:31.044 UTC [comm.grpc.server] 1 -> INFO 00a streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=172.20.0.6:36542 grpc.code=OK grpc.call_duration=152.538972ms
2019-05-13 13:22:11.867 UTC [common.deliver] Handle -> WARN 00b Error reading from 172.20.0.6:36578: rpc error: code = Canceled desc = context canceled
2019-05-13 13:22:11.867 UTC [comm.grpc.server] 1 -> INFO 00c streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=172.20.0.6:36578 error="rpc error: code = Canceled desc = context canceled" grpc.code=Canceled grpc.call_duration=5.757971ms
2019-05-13 13:22:22.295 UTC [orderer.common.broadcast] Handle -> WARN 00d Error reading from 172.20.0.8:34272: rpc error: code = Canceled desc = context canceled
2019-05-13 13:22:22.295 UTC [comm.grpc.server] 1 -> INFO 00e streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Broadcast grpc.peer_address=172.20.0.8:34272 error="rpc error: code = Canceled desc = context canceled" grpc.code=Canceled grpc.call_duration=7.238573847s
2019-05-13 13:23:46.748 UTC [orderer.common.broadcast] Handle -> WARN 00f Error reading from 172.20.0.8:34362: rpc error: code = Canceled desc = context canceled
2019-05-13 13:23:46.748 UTC [comm.grpc.server] 1 -> INFO 010 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Broadcast grpc.peer_address=172.20.0.8:34362 error="rpc error: code = Canceled desc = context canceled" grpc.code=Canceled grpc.call_duration=49.20235ms
In summery, I can not invoke the chaincode from the second organization (Org2) because of channel access error.
Note:
I am generating the CA and I have checked the files and it seems to be correct
If anyone can help I would appreciate it.
Thanks in advance
This can be caused by wrong MSPID name for example "orgMSP" is wrong as it starts with lowercase "o"
to solve the problem use correct MSPID
export CORE_PEER_LOCALMSPID="Org1MSP"
It would be easy to answer if you have shared the peer logs.
The error could be because of the Certificates to sign the transaction.Double check your certificate received from CA and also checked the certificates and path used inside the docker container of peer1.
The instantiation command completes successfully, but when analyzing peer logs, you may notice this:
2019-04-17 17:25:52.581 UTC [gossip.state] commitBlock -> DEBU 48c [canal-contrato] Committed block [1] with 1 transaction(s)
2019-04-17 17:25:52.581 UTC [common.deliver] deliverBlocks -> DEBU 48d [channel: canal-contrato] Delivering block for (0xc00023f9c0) for 192.168.16.1:48230
2019-04-17 17:25:52.581 UTC [fsblkstorage] waitForBlock -> DEBU 48e Going to wait for newer blocks. maxAvailaBlockNumber=[1], waitForBlockNum=[2]
2019-04-17 17:25:52.586 UTC [common.deliver] deliverBlocks -> DEBU 48f Context canceled, aborting wait for next block
2019-04-17 17:25:52.586 UTC [common.deliverevents] func1 -> DEBU 490 Closing Deliver stream
2019-04-17 17:25:52.586 UTC [comm.grpc.server] 1 -> INFO 491 streaming call completed {"grpc.start_time": "2019-04-17T17:25:50.441Z", "grpc.service": "protos.Deliver", "grpc.method": "DeliverFiltered", "grpc.peer_address": "192.168.16.1:48230", "error": "context finished before block retrieved: context canceled", "grpc.code": "Unknown", "grpc.call_duration": "2.144399922s"}
Can anyone orient me what I'm possibly doing wrong and what are the consequences of this error?
Notes:
The orderer logs don't present any type of error
All containers are running correctly
I'm using node version 8.9.0 (with npm 5.5.1)
I have 1 organization with 1 peer, 1 CA and 1 ordered (just to test)
I'm using hyperlegder fabric version 1.4
This is not an error. You are using an SDK that connects to the peer and waits for the instantiate to finish. The block is received by the peer, and when it does - the SDK closes the gRPC stream because it doesn't need it anymore, and the peer logs this to notify you why it closed the stream from the server side.
Orderer logs show following error(highlighted) during broadcast even though the transaction is successful and committed to all peers:
2018-12-19 13:43:42.724 UTC [policies] Evaluate -> DEBU 997 == Done Evaluating *policies.implicitMetaPolicy Policy /Channel/Writers
2018-12-19 13:43:42.724 UTC [orderer/common/broadcast] Handle -> DEBU 998 [channel: mychannel] Broadcast has successfully enqueued message of type ENDORSER_TRANSACTION from 172.19.0.7:40978
2018-12-19 13:43:42.724 UTC [orderer/common/blockcutter] Ordered -> DEBU 999 Enqueuing message into batch
2018-12-19 13:43:42.724 UTC [orderer/consensus/solo] main -> DEBU 99a Just began 2s batch timer
2018-12-19 13:43:42.730 UTC [grpc] infof -> DEBU 99b transport: loopyWriter.run returning. connection error: desc = "transport is closing"
2018-12-19 13:43:42.730 UTC [orderer/common/broadcast] Handle -> WARN
99c Error reading from 172.19.0.7:40978: rpc error: code = Canceled
desc = context canceled
2018-12-19 13:43:42.731 UTC [orderer/common/server] func1 -> DEBU 99d Closing Broadcast stream
2018-12-19 13:43:44.724 UTC [orderer/consensus/solo] main -> DEBU 99e Batch timer expired, creating block
2018-12-19 13:43:44.724 UTC [msp] GetDefaultSigningIdentity -> DEBU 99f Obtaining default signing identity
Fabric Config: All configs and setup same as specified in Build you First Network tutorial at https://hyperledger-fabric.readthedocs.io/en/release-1.3/build_network.html
Query
What is meant by this error? What does orderer read from cli(IP of cli: 172.19.0.7:40978) during broadcast?
I am not sure if the community is aware of this problem but I tried to run the balance-transfer application under [fabric samples]: https://github.com/hyperledger/fabric-samples. Everything seems to run smoothly. However, when running a query or an invoke operation, the docker container containing the chaincode crashes and gets restarted. You can check it out by running
docker ps -a. The status will show that the container had just started.
I looked up the logs of the peer that was queried and it seems the problem resides somewhere here:
2018-01-17 07:06:33.654 UTC [container] lockContainer -> DEBU 891 waiting for container(dev-peer0.org1.example.com-mycc-v0) lock
2018-01-17 07:06:33.654 UTC [container] lockContainer -> DEBU 892 got container (dev-peer0.org1.example.com-mycc-v0) lock
2018-01-17 07:06:33.655 UTC [dockercontroller] Start -> DEBU 893 Cleanup container dev-peer0.org1.example.com-mycc-v0
****2018-01-17 07:06:33.693 UTC [chaincode] processStream -> ERRO 894 Error handling chaincode support stream: rpc error: code = Canceled desc = context canceled****
2018-01-17 07:06:33.693 UTC [chaincode] deregisterHandler -> DEBU 895 Deregister handler: mycc:v0
2018-01-17 07:06:34.343 UTC [dockercontroller] stopInternal -> DEBU 896 Stopped container dev-peer0.org1.example.com-mycc-v0
2018-01-17 07:06:34.343 UTC [dockercontroller] stopInternal -> DEBU 897 Kill container dev-peer0.org1.example.com-mycc-v0 (API error (409): {"message":"Cannot kill container: dev-peer0.org1.example.com-mycc-v0: Container d818357f76068ab0a9efbf70be9b9a19fd7f6cc7bbe11eaba95c0a61d208ceac is not running"}
)
2018-01-17 07:06:34.459 UTC [dockercontroller] stopInternal -> DEBU 898 Removed container dev-peer0.org1.example.com-mycc-v0
2018-01-17 07:06:34.459 UTC [dockercontroller] Start -> DEBU 899 Start container dev-peer0.org1.example.com-mycc-v0
2018-01-17 07:06:34.459 UTC [dockercontroller] createContainer -> DEBU 89a Create container: dev-peer0.org1.example.com-mycc-v0
2018-01-17 07:06:34.724 UTC [dockercontroller] createContainer -> DEBU 89b Created container: dev-peer0.org1.example.com-mycc-v0-f021beca29998638e0bb7caa7af8fda7f1e709518214a3181d259abcb2347093
Any idea what is going on?
There exist two types of chaincode
System chaincode (part of peer binary)
Application chaincode (developed by smart contract/chaincode developers)
System chaincodes are part of the peer binary itself, whereas application chaincodes are instantiated in docker containers. There are various system chaincodes like LSCC, CSCC, QSCC, etc.
LSCC refers to the Life cycle system chaincode, it manages the life cycle of application chaincode.
LSCC contains various chaincode related logics like installation logic, instantiation logic, up-gradation logic, invoking and querying logic.
So, the point is
If
the chaincode container is already up and running
then, The Query/Invoke function get executed and the result is returned to the
caller.
else
due to any reason if the chaincode container is killed and not running to serve
the requests over gRPC
then,
the LSCC invoking/querying logic launches the chaincode container again until
it's ready to serve the requests make by the caller.