Date   

Possible configuration of first-come-first-serve ordering policy

Nikos Kapsoulis
 

Hi,

according to orderer documentation, in phase two the "the ordering service puts the transactions into a strict order". Where in the orderer's code (or anywhere else) is it possible to configure this "first-come-first-serve" policy? Thank you in advance.

With kind regards,

-Nikos




Re: #couchdb #fabric-chaincode #fabric-sdk-java #couchdb #fabric-chaincode #fabric-sdk-java

Marek Malik <info@...>
 

Hi Matthew,

 

Thank you!

I think I’m still not using that fix, the problem with the time is constant since I remember, it’s just depended on what the data volume is. The weirds thing is that FabCar is running smooth.
I didn’t tested uploading the data from outside the chaincode rather than on `initLedger`. If you need anything I’m on rocketchat @c0deh0use.

 



Marek Malik

 

Od: Matthew White <WHITEMAT@...>
Data: piątek, 15 maja 2020 14:31
Do: Marek Malik <info@...>
DW: "fabric@..." <fabric@...>
Temat: RE: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java

 

Hello; let me have a look at your repo... just to double check it couldn't be the perf issue fixes this week?

 

 

Regards, Matthew.


Matthew B White  IBM Blockchain Solutions Architect

 

Email me at WHITEMAT@...

Find me on StackOverflow, and generally at  calanais.me.uk

 

Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 

IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN


"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 

 

 

----- Original message -----
From: "Marek Malik" <info@...>
Sent by: fabric@...
To: Senthilnathan N <cendhu@...>
Cc: "fabric@..." <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java
Date: Fri, May 15, 2020 1:23 PM
 

Hello guys,

Sorry for being such a pain in the ass, but could one please help with that darn performance issue ?
I have tried to strip down my chaincode and do a copy-past of what the FabCar java chaincode has and do my chaincode on its based (both the setup and the chaincode build).

Not much have this helped, and I’m running out of points where my chaincode can differ from the sample fabcar.
I’m only interested in the getQueryResult
rich query feature in CouchDB.


Bellow you can access my repo with the two chaincodes setup and client apps to test the responses.
https://github.com/Marek00Malik/fabric-samples/tree/chaincode-performance-test


Besides the FabCar java chaincode there is a poc-services chaincode, and also a poc-services client app.
You can start the network and deploy both chaincodes by running 
` ./startFabric.sh fabcar` from the poc-services folder.
The chaincode is located in the chaincodes/poc-services folder as the fabcar one is.

The results differ by around 30 seconds.
FabCar                        - 3.5 seconds
My chaincode             - 31 seconds.


Can someone review and help me with this one, I don’t have any other ideas where the additional time difference could be sitting.


Best Regards,
Marek Malik

 

Od: <fabric@...> w imieniu użytkownika Marek Malik <info@...>
Data: piątek, 1 maja 2020 22:17
Do: Senthilnathan N <cendhu@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java

 

I didn’t tested placing the content in the root of the project, as usually the META-INF is placed in the app resource directory (as stated in the initial email).

Remarkably, this actually worked!
I assume that the process of setting up the couch db and any configuration/ doesn’t necessary have anything to do with the actual chain code deployment, it’s just packaged in the root with the code ?




Anyway, Thanks for your suggestion 😊

Best Regards,
Marek

Od: Senthilnathan N <cendhu@...>
Data: piątek, 1 maja 2020 19:32
Do: Marek Malik <info@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java

 

Regards,

Senthil

 

 

On Fri, May 1, 2020 at 10:44 PM <info@...> wrote:

I'm trying to create a CouchDB index while deploying the Java-based chain code.
I was following the documentation from there:
https://hyperledger-fabric.readthedocs.io/en/release-2.0/couchdb_tutorial.html#verify-index-was-deployed

I'm not able to get the index to be created while deploying the chaincode on the peer. I cannot see any log entry like "[couchdb] CreateIndex ->" when checking peer logs.

I’m trying to create a simple index, it’s stored in the following path: `root-dir/src/main/resources/META-INF/statedb/couchdb/indexes`
with the filename `pocServicesIdx.json` and content:

```
{

  "index": {

    "fields": [

      "projectId",

      "data_type"

    ]

  },

  "ddoc": "pocServicesDoc",

  "name": "pocServicesIdx",

  "type": "json"

}


```



I’m able to create an index manually doing it from the Fauxton admin console so the syntax should be valid.
The problem is that I’m not even getting any error logs related to creating indexes when deploying the chaincode when running the peer with flag FABRIC_LOGGING_SPEC

Using Fabric 2.0.0 version. 

Can anybody help or give some suggestions?

 

 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



Intercept Invoke call, rcp error #fabric-questions #network #hyperledger-fabric

Tenci <eagles01@...>
 

Hi,

I want to intercept an invoke call (fab1.4, first-network, disabled tls, working on CLI). My idea was to to make use of burp/mitmproxy (listening at 127.0.0.8080) to intercept the invoke call to change content of the gRPC msg.

Without TLS, the call started of the CLI Container:

root@52df464e4390:/etc#  peer chaincode invoke -o orderer.example.com:7050 -C mychannel -n mycc --peerAddresses 127.0.0.1:8080 -c '{"Args":["invoke","a","b","10"]}'

 

leads to the following error:

Error: error getting endorser client for invoke: endorser client failed to connect to 127.0.0.1:8080: failed to create new connection: connection error: desc = "transport: error while dialing: dial tcp 127.0.0.1:8080: connect: connection refused"

 

Expected: Arrival of gRPC stream at 127.0.0.8080, which normally is visible (eg. in using wireshark pb decoder) for peer0.org1.example.com here. All other IPs leads to the error msg above.

 

 


Re: #couchdb #fabric-chaincode #fabric-sdk-java #couchdb #fabric-chaincode #fabric-sdk-java

Matthew White
 

Hello; let me have a look at your repo... just to double check it couldn't be the perf issue fixes this week?
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
 
 
----- Original message -----
From: "Marek Malik" <info@...>
Sent by: fabric@...
To: Senthilnathan N <cendhu@...>
Cc: "fabric@..." <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java
Date: Fri, May 15, 2020 1:23 PM
 

Hello guys,

Sorry for being such a pain in the ass, but could one please help with that darn performance issue ?
I have tried to strip down my chaincode and do a copy-past of what the FabCar java chaincode has and do my chaincode on its based (both the setup and the chaincode build).

Not much have this helped, and I’m running out of points where my chaincode can differ from the sample fabcar.
I’m only interested in the getQueryResult
rich query feature in CouchDB.


Bellow you can access my repo with the two chaincodes setup and client apps to test the responses.
https://github.com/Marek00Malik/fabric-samples/tree/chaincode-performance-test


Besides the FabCar java chaincode there is a poc-services chaincode, and also a poc-services client app.
You can start the network and deploy both chaincodes by running 
` ./startFabric.sh fabcar` from the poc-services folder.
The chaincode is located in the chaincodes/poc-services folder as the fabcar one is.

The results differ by around 30 seconds.
FabCar                        - 3.5 seconds
My chaincode             - 31 seconds.


Can someone review and help me with this one, I don’t have any other ideas where the additional time difference could be sitting.


Best Regards,
Marek Malik

 

Od: <fabric@...> w imieniu użytkownika Marek Malik <info@...>
Data: piątek, 1 maja 2020 22:17
Do: Senthilnathan N <cendhu@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java

 

I didn’t tested placing the content in the root of the project, as usually the META-INF is placed in the app resource directory (as stated in the initial email).

Remarkably, this actually worked!
I assume that the process of setting up the couch db and any configuration/ doesn’t necessary have anything to do with the actual chain code deployment, it’s just packaged in the root with the code ?



Anyway, Thanks for your suggestion 😊

Best Regards,
Marek

Od: Senthilnathan N <cendhu@...>
Data: piątek, 1 maja 2020 19:32
Do: Marek Malik <info@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java

 

Regards,

Senthil

 

 

On Fri, May 1, 2020 at 10:44 PM <info@...> wrote:

I'm trying to create a CouchDB index while deploying the Java-based chain code.
I was following the documentation from there:
https://hyperledger-fabric.readthedocs.io/en/release-2.0/couchdb_tutorial.html#verify-index-was-deployed

I'm not able to get the index to be created while deploying the chaincode on the peer. I cannot see any log entry like "[couchdb] CreateIndex ->" when checking peer logs.

I’m trying to create a simple index, it’s stored in the following path: `root-dir/src/main/resources/META-INF/statedb/couchdb/indexes`
with the filename `pocServicesIdx.json` and content:

```
{
  "index": {
    "fields": [
      "projectId",
      "data_type"
    ]
  },
  "ddoc": "pocServicesDoc",
  "name": "pocServicesIdx",
  "type": "json"
}

```



I’m able to create an index manually doing it from the Fauxton admin console so the syntax should be valid.
The problem is that I’m not even getting any error logs related to creating indexes when deploying the chaincode when running the peer with flag FABRIC_LOGGING_SPEC

Using Fabric 2.0.0 version. 

Can anybody help or give some suggestions?

 

 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: #couchdb #fabric-chaincode #fabric-sdk-java #couchdb #fabric-chaincode #fabric-sdk-java

Marek Malik <info@...>
 

Hello guys,

Sorry for being such a pain in the ass, but could one please help with that darn performance issue ?
I have tried to strip down my chaincode and do a copy-past of what the FabCar java chaincode has and do my chaincode on its based (both the setup and the chaincode build).

Not much have this helped, and I’m running out of points where my chaincode can differ from the sample fabcar.
I’m only interested in the getQueryResult
rich query feature in CouchDB.


Bellow you can access my repo with the two chaincodes setup and client apps to test the responses.
https://github.com/Marek00Malik/fabric-samples/tree/chaincode-performance-test


Besides the FabCar java chaincode there is a poc-services chaincode, and also a poc-services client app.
You can start the network and deploy both chaincodes by running 
` ./startFabric.sh fabcar` from the poc-services folder.
The chaincode is located in the chaincodes/poc-services folder as the fabcar one is.

The results differ by around 30 seconds.
FabCar                        - 3.5 seconds
My chaincode             - 31 seconds.


Can someone review and help me with this one, I don’t have any other ideas where the additional time difference could be sitting.


Best Regards,
Marek Malik

 

Od: <fabric@...> w imieniu użytkownika Marek Malik <info@...>
Data: piątek, 1 maja 2020 22:17
Do: Senthilnathan N <cendhu@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java

 

I didn’t tested placing the content in the root of the project, as usually the META-INF is placed in the app resource directory (as stated in the initial email).

Remarkably, this actually worked!
I assume that the process of setting up the couch db and any configuration/ doesn’t necessary have anything to do with the actual chain code deployment, it’s just packaged in the root with the code ?


Anyway, Thanks for your suggestion 😊

Best Regards,
Marek

Od: Senthilnathan N <cendhu@...>
Data: piątek, 1 maja 2020 19:32
Do: Marek Malik <info@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #couchdb #fabric-chaincode #fabric-sdk-java

 

Regards,

Senthil

 

 

On Fri, May 1, 2020 at 10:44 PM <info@...> wrote:

I'm trying to create a CouchDB index while deploying the Java-based chain code.
I was following the documentation from there:

https://hyperledger-fabric.readthedocs.io/en/release-2.0/couchdb_tutorial.html#verify-index-was-deployed

I'm not able to get the index to be created while deploying the chaincode on the peer. 
I cannot see any log entry like "[couchdb] CreateIndex ->" when checking peer logs.



I’m trying to create a simple index, it’s stored in the following path: `root-dir/src/main/resources/META-INF/statedb/couchdb/indexes`

with the filename 
`pocServicesIdx.json` and content:

```
{
  "index": {
    "fields": [
      "projectId",
      "data_type"
    ]
  },
  "ddoc": "pocServicesDoc",
  "name": "pocServicesIdx",
  "type": "json"
}

```



I’m able to create an index manually doing it from the Fauxton admin console so the syntax should be valid.
The problem is that I’m not even getting any error logs related to creating indexes when deploying the chaincode when running the peer with flag FABRIC_LOGGING_SPEC

Using Fabric 2.0.0 version. 

Can anybody help or give some suggestions?


Confusion related to env variable ORDERER_TLS_CA

Abhijeet Bhowmik <abhijeet@...>
 

Hello wonderful people,

I hope all are doing well. As a beginner, I have a confusion that came to me while writing docker-compose files to build my own network. There is an env variable in the orderer section 
'
- ORDERER_GENERAL_TLS_ROOTCAS=[/etc/hyperledger/tls/orderer/ca.crt]
'

So while TLSing via Peer, I have been told to use orderer's /tls/ca.crt. That's where my confusion lies. If anyways we are gonna use orderer's tls/ca.crt, what's the purpose of having value of ORDERER_GENERAL_TLS_ROOTCAS as array. What other values could I mention there. And what will be their significance? Ideally while TLSing between Server-client, Server presents it's certificate (with public key) during the request and the client doesn't have it pre hand. So if we go by that scenario, maybe either the orderer should present it's cert during the request or else there must be a way that we can use peer side artifacts to do the TLS. I see no point in copying orderer's tls/ca.crt to every peer manually.

Definitely I could be wrong. I will be more than happy if someone throws some light on this. Looking forward to it.

Thanks and Regards
Abhijeet Bhowmik


Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 05/15/2020 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When:
Friday, 15 May 2020
6:00am to 7:00am
(GMT+01:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

Description:
Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error

Siddharth Jain
 

we have a network of Raft orderers. when we tried to created a channel we saw these warnings in the logs

2020-05-14 11:38:52.521 PDT [common.deliver] deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error

2020-05-14 11:38:52.521 PDT [comm.grpc.server] 1 -> INFO 04e streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=[::1]:52044 grpc.code=OK grpc.call_duration=203.915648ms

2020-05-14 11:38:52.727 PDT [common.deliver] deliverBlocks -> WARN 04f [channel: tracktrace] Rejecting deliver request for [::1]:52045 because of consenter error

2020-05-14 11:38:52.727 PDT [comm.grpc.server] 1 -> INFO 050 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=[::1]:52045 grpc.code=OK grpc.call_duration=203.352982ms

2020-05-14 11:38:52.929 PDT [common.deliver] deliverBlocks -> WARN 051 [channel: tracktrace] Rejecting deliver request for [::1]:52046 because of consenter error

2020-05-14 11:38:52.929 PDT [comm.grpc.server] 1 -> INFO 052 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=[::1]:52046 grpc.code=OK grpc.call_duration=200.740112ms


the channel still got created. we are not using ports 52044, 52045, 52046 at all. Not sure from where it is getting these ports. anyone knows what this is about?


ANNOUNCEMENT: Hyperledger Fabric v1.4.7 is now available!

David Enyeart
 

Hyperledger Fabric and Fabric CA v1.4.7 are now available. See details of the included fixes in the release notes:
https://github.com/hyperledger/fabric/releases/tag/v1.4.7
https://github.com/hyperledger/fabric-ca/releases/tag/v1.4.7


Dave Enyeart


Re: Error: Enrollment information does not exist

cridev
 

Thanks for the flag Chris,

I'll look into that, though I am not (yet) trying Kubernetes, just using the out-of-the-box fabcar example from fabric-samples.

Do you think this might be related to the client error I am getting in Explorer?

[INFO] FabricClient - Error : Failed to connect client peer,  please check the configuration and peer status

Many thanks

-CR


On 2020-05-14 20:58, Chris Gabriel wrote:

I always recommend reading the docs in the Hyperledger Fabric CA section which has been updated recently.  Additionally, I have a video tutorial on YouTube (https://www.youtube.com/watch?v=PbMxqH6bNB8) for running the FABRIC CA on Kubernetes where your specific question is covered at about the 8:50 mark of the video.  There is an accompanying public github repo with a comprehensive README here.  

On May 14, 2020, at 1:44 PM, Chris Gabriel via lists.hyperledger.org <alaskadd=gmail.com@...> wrote:

You are not in the client binary directory when issuing the command. You can fix this by exporting the FABRIC_CA_CLIENT_HOME variable and run the command again. This used to get me too, so we updated the CA docs with better instructions.

 

On May 14, 2020, at 1:35 PM, cridev@... wrote:

Hi all.

I am trying to interact with Fabric through the "fabric-ca-client" binary. I have launched the fabcar, compiled the javascript and node enrollAdmin and node registerUser without errors. However, when I try to launch fabric-ca-client identity list to query the identities that were enrolled and registered by the fabcar (through test-network) this fails and I get a:

ERROR] Enrollment check failed: Idemix enrollment information does not exist
Error: Enrollment information does not exist. Please execute enroll command first. Example:
 fabric-ca-client enroll -u http://user:userpw@serverAddr:serverPort

Note that from the logs I had seen the same exact comment had already went through.

fabric-ca-client enroll -u https://admin:adminpw@localhost:7054 --caname ca-org1 --tls.certfiles /path/to/fabric-ca/org1/tls-cert.pem

Am I missing something obvious here?



Re: Error: Enrollment information does not exist

Chris Gabriel <alaskadd@...>
 

I always recommend reading the docs in the Hyperledger Fabric CA section which has been updated recently.  Additionally, I have a video tutorial on YouTube (https://www.youtube.com/watch?v=PbMxqH6bNB8) for running the FABRIC CA on Kubernetes where your specific question is covered at about the 8:50 mark of the video.  There is an accompanying public github repo with a comprehensive README here.  

On May 14, 2020, at 1:44 PM, Chris Gabriel via lists.hyperledger.org <alaskadd=gmail.com@...> wrote:

You are not in the client binary directory when issuing the command. You can fix this by exporting the FABRIC_CA_CLIENT_HOME variable and run the command again. This used to get me too, so we updated the CA docs with better instructions.


On May 14, 2020, at 1:35 PM, cridev@... wrote:

Hi all.

I am trying to interact with Fabric through the "fabric-ca-client" binary. I have launched the fabcar, compiled the javascript and node enrollAdmin and node registerUser without errors. However, when I try to launch fabric-ca-client identity list to query the identities that were enrolled and registered by the fabcar (through test-network) this fails and I get a:

ERROR] Enrollment check failed: Idemix enrollment information does not exist
Error: Enrollment information does not exist. Please execute enroll command first. Example:
 fabric-ca-client enroll -u http://user:userpw@serverAddr:serverPort

Note that from the logs I had seen the same exact comment had already went through.

fabric-ca-client enroll -u https://admin:adminpw@localhost:7054 --caname ca-org1 --tls.certfiles /path/to/fabric-ca/org1/tls-cert.pem

Am I missing something obvious here?


Re: Error: Enrollment information does not exist

Chris Gabriel <alaskadd@...>
 

You are not in the client binary directory when issuing the command. You can fix this by exporting the FABRIC_CA_CLIENT_HOME variable and run the command again. This used to get me too, so we updated the CA docs with better instructions.


On May 14, 2020, at 1:35 PM, cridev@... wrote:

Hi all.

I am trying to interact with Fabric through the "fabric-ca-client" binary. I have launched the fabcar, compiled the javascript and node enrollAdmin and node registerUser without errors. However, when I try to launch fabric-ca-client identity list to query the identities that were enrolled and registered by the fabcar (through test-network) this fails and I get a:

ERROR] Enrollment check failed: Idemix enrollment information does not exist
Error: Enrollment information does not exist. Please execute enroll command first. Example:
 fabric-ca-client enroll -u http://user:userpw@serverAddr:serverPort

Note that from the logs I had seen the same exact comment had already went through.

fabric-ca-client enroll -u https://admin:adminpw@localhost:7054 --caname ca-org1 --tls.certfiles /path/to/fabric-ca/org1/tls-cert.pem

Am I missing something obvious here?


Documentation Workgroup: Agenda for Friday, 15 May

Anthony O'Dowd <a_o-dowd@...>
 

Hi All,

We will hold the documentation workgroup calls this Friday -- with both an Eastern hemisphere and Western hemisphere call. Please feel free to come along, you're always very welcome.

You can read about last week's calls at https://wiki.hyperledger.org/display/fabric/2020+05+08+DWG+Agenda You'll see significant minutes for both the Eastern and Western hemisphere calls, and recordings for both sessions.  The eastern hemisphere call focussed on a Malayalam language translation with a significant contribution from Aneena, Jubilant and other colleagues from India. We'll be returning to this topic in the eastern hemisphere call this week with a practical session on how to build Malayalam documentation. Our Western hemisphere call was equally busy. It included the now regular V2.x status update from Pam and Joe on new content. Excellent discussion followed on the deployment guide and CA instructions. There was a great review of Chris' demo.  There was significant discussion on the internals doc and how it can be best used and maintained. Finally, there was an informative discussion on Windows support. As always, two excellent sessions.

You can catch up with the full recordings and other sessions: https://wiki.hyperledger.org/display/fabric/Recordings

See https://wiki.hyperledger.org/display/fabric/2020+05+15+DWG+Agenda for this week's agenda. Again, on the Eastern hemisphere call we'll be holding a practical session on Malayalam language support, but of course it could equally well apply to other translations.

Please feel free to contribute using the wiki, including helping to build next week's agenda: https://wiki.hyperledger.org/display/fabric/2020+05+22+DWG+Agenda

Thanks!

Pam, Anthony,  Joe, Nik

Meeting Details
-------------
Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

The meeting times are as follows: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Meeting 128A: Friday 15 May
                   1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1100 Gulf Standard Time
                   1000 Moscow Standard Time
                   0700 Greenwich Mean Time
                   0800 Central European Time    

Meeting 128B: Friday 15 May
              1100 Central Daylight Time
                   1200 Eastern Daylight Time
                   0900 Pacific Daylight Time
                   1400 Brasil Time (BRT)
                   1600 Greenwich Mean Time
                   1700 Central European Time
                   1800 Moscow Standard Time



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Error: Enrollment information does not exist

cridev
 

Hi all.

I am trying to interact with Fabric through the "fabric-ca-client" binary. I have launched the fabcar, compiled the javascript and node enrollAdmin and node registerUser without errors. However, when I try to launch fabric-ca-client identity list to query the identities that were enrolled and registered by the fabcar (through test-network) this fails and I get a:

ERROR] Enrollment check failed: Idemix enrollment information does not exist
Error: Enrollment information does not exist. Please execute enroll command first. Example:
 fabric-ca-client enroll -u http://user:userpw@serverAddr:serverPort

Note that from the logs I had seen the same exact comment had already went through.

fabric-ca-client enroll -u https://admin:adminpw@localhost:7054 --caname ca-org1 --tls.certfiles /path/to/fabric-ca/org1/tls-cert.pem

Am I missing something obvious here?


Re: Private data logs in fabric version 2.0 #fabric #fabric-chaincode

Senthil Nathan
 

Hi,

   We compared the performance of both v1.4 and v.2.0 using public data, i.e., without collections. We have not observed any performance differences.

   Since the introduction of pvtdata feature, the gossip coordinator checks whether any transaction in a given block modified a collection's data. If any transaction does modify a collection's data, the coordinator would check for eligibility, i.e., whether the peer org is a member of the collection. If the peer org is a member, the coordinator fetches the missing pvtdata from either local transient store or remote peers. If transactions in a block have not modified any collection's data (as in your case), the coordinator wouldn't try to fetch it.

In v2.0, this part of the code got refactored and some additional logs such as the one you have mentioned above were added. Otherwise, there is not much change in the logic. It is surprising to hear that you notice a drop in performance. We will look at the log statements and convert them to either debug statements or put behind an if-then-else as appropriate.

To debug the performance drop, can you share the value of the following metrics for both v1.4 and v2.0?
  1. gossip_privdata_fetch_duration
  2. gossip_privdata_list_missing_duration
  3. gossip_privdata_pull_duration
  4. gossip_privdata_commit_block_duration
  5. gossip_state_commit_duration
Regards,
Senthil


On Thu, May 14, 2020 at 3:26 PM <susheeldighade@...> wrote:
Hello,
After the migration of our fabric setup from 1.4.4 version to 2.0, we have observed the private data logs getting appeared in the peer logs even though we are not using any private data collections in the chaincode. These logs weren't there for fabric 1.4.4 version. 

2020-05-07 12:36:42.909 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 3664 Successfully fetched all eligible collection private write sets for block [3128] channel=mychannel

Also the block_and_pvtdata_commit latency has increased after the migration. Please clarify if there is any private data check for each transaction getting committed to the ledger in fabric 2.0 version. If so, is there any configuration by which this check can be bypassed.

We feel this private data activity is adding an additional latency in our TPS test results.


Minifabric

email4tong@gmail.com
 

You can create new channels and only join peers you want them in these channels. To invoke a chaincode, you will have to know the chaincode method interface such as how many parameters and what each means etc. look at the source code you will see how these methods should be invoked. Adjust -p accordingly. Watch other videos in the series will help.




On Thursday, May 14, 2020, 12:09 AM, p.kirkinezis@... wrote:

First of all thanks for your info and your time  .

I have some extra question .

  1. Is there a configuration to make specific channel only between specific orgs . For example channel only between Org1 , Org2 and another channel between Org1 , Org3 ?
  2. I tried to add for example the fabcar chaincode but I can't run the invoke command it gives me json marsall error . Maybe i don't get how to input invoke parameters in the command ./minifab invoke -p.


Private data logs in fabric version 2.0 #fabric #fabric-chaincode

susheeldighade@...
 

Hello,
After the migration of our fabric setup from 1.4.4 version to 2.0, we have observed the private data logs getting appeared in the peer logs even though we are not using any private data collections in the chaincode. These logs weren't there for fabric 1.4.4 version. 

2020-05-07 12:36:42.909 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 3664 Successfully fetched all eligible collection private write sets for block [3128] channel=mychannel

Also the block_and_pvtdata_commit latency has increased after the migration. Please clarify if there is any private data check for each transaction getting committed to the ledger in fabric 2.0 version. If so, is there any configuration by which this check can be bypassed.

We feel this private data activity is adding an additional latency in our TPS test results.


Verify if the newly added orderer node has synced the blocks in Hyperledger Fabric #hyperledger-fabric #raft #fabric-orderer

chintanr97@...
 

I am adding a new orderer node by following the steps mentioned here: Reconfiguring the RAFT cluster.
 
In the 5th step we can see that following is mentioned:
 
Waiting for the Raft node to replicate the blocks from existing nodes for all channels its certificates have been added to. After this step has been completed, the node begins servicing the channel.
 
Now, I went through a few options to perform this step.
 
  1. Manually check the new orderer node logs.
  2. For automation purposes, we can see the orderer metrics. Of this, I feel consensus_etcdraft_committed_block_number is a good choice. We can fetch the given metric value from existing orderer and wait for the new node to reach at that block number. The issue arises when the network is dynamic. Meaning, for the time that the new node syncs old blocks, there might have been new updates to the channel in that duration.
So, my questions are:
 
  1. Should we wait for the new orderer node to sync those blocks as well which were committed in the ledger in the gap period of it being in sync with others?
  2. If yes, then we would have to keep fetching above metric value from an existing orderer and the new orderer until both of them reach at a sync stage (which I feel is too much overhead for production use). So, is there a better approach or an orderer metric which I might be missing, which could help us here?


Re: Private data collections recommended usage

David Enyeart
 

Yes, you can update multiple explicit and/or implicit private data collections in a single transaction. Each org-specific implicit private data collection has an endorsement policy of the associated organization. So a client from OrgA could submit an update for OrgA collection and OrgB collection, so long as they get an endorsement from an OrgA peer and OrgB peer. The updates would be applied atomically assuming the transaction is validated. The chaincode can have access control logic that either allows or disallows these cross-org updates, for example the chaincode can check that the client MSPID matches the endorsing peer's MSPID, if you want to restrict such cross-org updates for certain transactions, but allow it for other transactions.

You may be interested in a new sample that we are working on to demonstrate these concepts: https://github.com/hyperledger/fabric-samples/pull/174.
In the sample, private data associated with a transferred asset is deleted from seller's private data collection and added to buyer's private data collection in a single transaction that gets endorsed by both organizations.

In terms of the complexities associated with explicitly defined static private data collections, I was referring to same thing as you - managing an ever-growing number of collections that require approval from other organizations.

While it sounds like either existing approach would work in your scenario, it also sounds like the 'local collection' proposal (if implemented in the future) would simplify things for you, such that the private data hash is stored once in the common chaincode namespace, while the originating client chooses which organizations should receive the actual private data.


Dave Enyeart

omer.glam---05/13/2020 08:28:57 AM---Hi David, thank you for the prompt response. >

From: omer.glam@...
To: fabric@...
Date: 05/13/2020 08:28 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Private data collections recommended usage
Sent by: fabric@...





Hi David, thank you for the prompt response.

interesting, can we update multiple, cross organizations implicit collections in that same transaction (given all of the collection's organizations are endorsing the transaction ) ?
the goal is to be able to keep the data up to date across all collections where the data is shared, preferably doing so under a single transaction.
      I would suggest either pattern 1) or pattern 3). Pattern 2) will be challenging to manage if you have many pairs of organizations. Use pattern 1 for less duplication of data and more fine grained access control. Use pattern 3 if you want clients to query only their own org's peer. Your choice.

can you elaborate on the challenges of many collections may impose?
in our perspective the static nature of collections definitions might make operating large amount of collections complex since it require the other organization approval on the new or updated collection definition, but for our use case we can solve this as part of our process of bootstrapping a new organization to the channel (creating the per organization collection between the new organizations and existing organizations).
are there are any other issues we are overlooking here?

Thank you,
Omer




Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 05/15/2020 6:00am-7:00am #cal-reminder

fabric@lists.hyperledger.org Calendar <fabric@...>
 

Reminder: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When: Friday, 15 May 2020, 6:00am to 7:00am, (GMT+01:00) Europe/London

Where:https://zoom.us/j/6223336701

View Event

Organizer: Anthony O'Dowd a_o-dowd@... +441962816761

Description: Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

3241 - 3260 of 11518