Date   

Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 05/15/2020 4:00pm-5:00pm #cal-reminder

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

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 15 May 2020, 4:00pm to 5:00pm, (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


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

Nikos Kapsoulis
 

Gari, thank you for your answer. I am answering inline.

What are you trying / hoping to do?
Modify the following - keep reading please.
There is no "policy" per se and strictly speaking there is no guarantee that the transactions will be ordered in the exact order in which they were sent.

Agreed.

However, I think that after the transactions are sent to the orderer and the orderer puts them in a strict order, then the peers will use the same order when validating and committing transactions. Thus, I suppose that somewhere in the orderer's code exists the point or function where the orderer sends the transactions to the peers, and hopefully it could be somewhat configured or modified. (For instance, in a way of sorting them by Header or something else.).

That being said, it is currently generally this case that transactions are ordered in the order received as they are processed from a gRPC stream which does queue messages in the order in which they are received.

Again, correct me if I am wrong, I am trying to locate this exact point in code where the transactions are received, ordered and then sent to the peers (1 of the 3 points will do I guess), and hopefully configure a custom orderer. Thank you in advance.

With kind regards,

-Nikos

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: "Nikos Kapsoulis" 
Sent by: fabric@...
Date: 05/15/2020 08:44AM
Subject: [EXTERNAL] [Hyperledger Fabric] Possible configuration of first-come-first-serve ordering policy

                   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: deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error

Jason Yellick <jyellick@...>
 

The address you are seeing there is the source address and port, not the port the service is listening on.

It's also normal to see those warnings about consenter errors shortly after channel creation because the client may begin polling for the genesis block before the consenters have had a chance to form a quorum.

~Jason
 

----- Original message -----
From: "Siddharth Jain" <siddjain@...>
Sent by: fabric@...
To: "fabric@..." <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] deliverBlocks -> WARN 04d [channel: tracktrace] Rejecting deliver request for [::1]:52044 because of consenter error
Date: Thu, May 14, 2020 5:16 PM
 
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?
 


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

Gari Singh <garis@...>
 

What are you trying / hoping to do?

There is no "policy" per se and strictly speaking there is no guarantee that the transactions will be ordered in the exact order in which they were sent.
That being said, it is currently generally this case that transactions are ordered in the order received as they are processed from a gRPC stream which does queue messages in the order in which they are received.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: "Nikos Kapsoulis"
Sent by: fabric@...
Date: 05/15/2020 08:44AM
Subject: [EXTERNAL] [Hyperledger Fabric] Possible configuration of first-come-first-serve ordering policy

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


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.

3141 - 3160 of 11422