Date   
Re: invoke failed

Matthew White
 

Hello;
 
What's the relationship between ContractA and ContractB?  

Are they within the same chaincode?  
 
Different chaincode, same channel?
 
Or completely different channel?
 
 
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: "Roxana Danger" <roxana.danger@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] invoke failed
Date: Thu, Jul 9, 2020 12:44 PM
 

Hello,

I have a chaincode with two contracts such that the second contract invoke a transaction of the first one as follows:

class ContractA implements ContractInterface{
     .....
     @Transaction
     public boolean trans1(MyContext ctx, String data) {
         ...
         return result;
     }
}

class ContractB implements ContractInterface{
     .....
     @Transaction
     public boolean trans2(MyContext ctx, String data) {
         ...
         Chaincode.Response response = ctx.getStub().invokeChaincode(chaincodeId,
                    new String[]{ContractA:trans1, "data"});
         ...
     }
}

During the execution of trans2, the invokeChaincode fails with the error: "INVOKE_CHAINCODE failed: transaction ID exists". According to the documentation, no other transaction will be created by calling invokeChaincode, therefore, it is correct that the invocation is created with the same transaction ID.

Is it a bug or am I doing something incorrect in my design?

Many thanks in advance,

Roxana

 
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: Lag between initialization of call in Gateway and ContractRouter #fabric-chaincode #fabric-sdk-java #hyperledger-fabric

Matthew White
 

Hello Marek;
 
Just to check I understand your situation.
 
You're submitting a single transaction, that in effect, does a number of 'putState' calls. When that number gets to the ~140 the end-end time has increased.
When you say the payload is 100k, is that of the original transaction, or the data being stored in the states. 
 
How many orgs? 
What's the endorsement policy? 
 
 
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: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Lag between initialization of call in Gateway and ContractRouter #fabric-chaincode #fabric-sdk-java #hyperledger-fabric
Date: Fri, Jul 10, 2020 11:11 AM
 
Hello Guys, 
I have a problem with executing my chaincode when sending not that big payload (around 100Kb). 
There is a big, incremental time lag when waiting for the proposal response back to the gateway. 
The chaincode is very simple, I'm uploading records that are transformed on the chaincode and then stored in CouchDB.

I have played with the number of records that would be stored per request: 

 

  • 1 record took 2-3 sec.
  • 24 records took 9sec,
  • 88 records took 60 sec,
  • 146 records took 2.40-3 minutes.

I have set the BatchTimeout and MaxMessageCount to (10s and 500 records) but the times are not getting any better.
One thing that I noticed is when processing around 146 records the entire process in my chain code is finished in around 1.5 seconds (I’m logging the duration of the process on the finish). Also, when investigating log times I noticed that the process on the blockchain actually starts very late (logs from ContractRouter), more than 2 minutes after a proposal has been sent from the gateway. 

I'm checking the logs if there are any records that would point that the ordered or peer received the request but I don't see anything before the ContractRouter, but I'm still not that experienced in all the core libs, maybe one would be able to help here?


Does anyone have any ideas why the request would be taking that long?

I'm using java for both the gateway (2.1.4 version) and in the chaincode (2.2.0). I'm running it in a docker-compose network. 

Thanks

Mark

 
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

Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 07/10/2020 #cal-notice

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

Hyperledger Fabric Documentation Workgroup call - Western hemisphere

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

Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 07/10/2020 4:00pm-5:00pm #cal-reminder

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

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 10 July 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: How to selectively configure orderer nodes for particular channels?

Mr.Phuwanai Thummavet
 

Thank you very much. I'll have a look.


On Fri, 10 Jul 2020, 17:42 Gari Singh, <garis@...> wrote:
Have a look at https://hyperledger-fabric.readthedocs.io/en/release-2.2/raft_configuration.html#configuration

You'll see that each channel has its own Consenters section.  All Raft nodes must currently be added to the system channel, but each channel can be configured to use a subset of those Raft nodes

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

-----fabric@... wrote: -----
To: fabric <fabric@...>
From: "Mr.Phuwanai Thummavet"
Sent by: fabric@...
Date: 07/10/2020 01:31AM
Subject: [EXTERNAL] [Hyperledger Fabric] How to selectively configure orderer nodes for particular channels?

Dear all,

I have a requirement to selectively configure ordering service nodes for particular channels.
For example, there is a consortium of 5 OSN organizations and I want to create 2 channels.

For the first channel, 3 of them would be selectively configured, whereas
all the OSN nodes would be configured for the second channel.
How can I achieve that?

Thank you.--
Best Regards,
Phuwanai Thummavet
Blockchain Architect and Full-Stack Developer 

Re: How to selectively configure orderer nodes for particular channels?

Gari Singh
 

Have a look at https://hyperledger-fabric.readthedocs.io/en/release-2.2/raft_configuration.html#configuration

You'll see that each channel has its own Consenters section. All Raft nodes must currently be added to the system channel, but each channel can be configured to use a subset of those Raft nodes

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

-----fabric@... wrote: -----
To: fabric <fabric@...>
From: "Mr.Phuwanai Thummavet"
Sent by: fabric@...
Date: 07/10/2020 01:31AM
Subject: [EXTERNAL] [Hyperledger Fabric] How to selectively configure orderer nodes for particular channels?

Dear all,

I have a requirement to selectively configure ordering service nodes for particular channels.
For example, there is a consortium of 5 OSN organizations and I want to create 2 channels.

For the first channel, 3 of them would be selectively configured, whereas
all the OSN nodes would be configured for the second channel.
How can I achieve that?

Thank you.--
Best Regards,
Phuwanai Thummavet
Blockchain Architect and Full-Stack Developer

Lag between initialization of call in Gateway and ContractRouter #fabric-chaincode #fabric-sdk-java #hyperledger-fabric

Marek Malik
 

Hello Guys, 
I have a problem with executing my chaincode when sending not that big payload (around 100Kb). 
There is a big, incremental time lag when waiting for the proposal response back to the gateway. 
The chaincode is very simple, I'm uploading records that are transformed on the chaincode and then stored in CouchDB.

I have played with the number of records that would be stored per request: 

 

  • 1 record took 2-3 sec.
  • 24 records took 9sec,
  • 88 records took 60 sec,
  • 146 records took 2.40-3 minutes.

I have set the BatchTimeout and MaxMessageCount to (10s and 500 records) but the times are not getting any better.
One thing that I noticed is when processing around 146 records the entire process in my chain code is finished in around 1.5 seconds (I’m logging the duration of the process on the finish). Also, when investigating log times I noticed that the process on the blockchain actually starts very late (logs from ContractRouter), more than 2 minutes after a proposal has been sent from the gateway. 

I'm checking the logs if there are any records that would point that the ordered or peer received the request but I don't see anything before the ContractRouter, but I'm still not that experienced in all the core libs, maybe one would be able to help here?


Does anyone have any ideas why the request would be taking that long?

I'm using java for both the gateway (2.1.4 version) and in the chaincode (2.2.0). I'm running it in a docker-compose network. 

Thanks

Mark

Re: Chain code install approval and commit on existing channel .

p.kirkinezis@...
 

Yeah but lets say we have 2 orgs on different servers :
peer lifecycle chaincode commit -o <ORDERER_IP_ADDRESS > --channelID <CHANNEL_NAME>  --peerAddresses <SERVER1_PEER1_ORG1_IP_ADRESS>  --tlsRootCertFiles <SERVER1_PEER1_ORG1_PATH_TO_CA.CRT> --peerAddresses <SERVER2_PEER1_ORG2_IP_ADRESS>  --tlsRootCertFiles <SERVER2_PEER1_ORG2_PATH_TO_CA.CRT> --cafile <PATH_ORDERER_TLS_CA> --tls

Need all the peerAdresses of orgs in the channel .
And adidtionally needs the "ca.crt" TLS file for every org peer included in the commit command.
So i have to manually transfer tls keys from one server to the other where the "peer lifecycle chaincode commit" will run ?
Is there any other way ?

Re: Chain code install approval and commit on existing channel .

David Enyeart
 

No separate file for chaincode lifecycle approvals... the individual approval signatures are recorded on the channel ledger when each admin approves for their org on their own peer. Then when sufficient number of organizations have approved per the LifecycleEndorsement policy, the final commit transaction checks the approvals and activates the chaincode.


Dave Enyeart

p.kirkinezis---07/10/2020 02:29:01 AM---Is there any file produced whie approveformyorg is executed that i have to distribute to be approved

From: p.kirkinezis@...
To: fabric@...
Date: 07/10/2020 02:29 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Chain code install approval and commit on existing channel .
Sent by: fabric@...





Is there any file produced whie approveformyorg is executed that i have to distribute to be approved from all server .
I mean like the file produced in sign process when making channel configuration update ?



Re: Chain code install approval and commit on existing channel .

p.kirkinezis@...
 

Is there any file produced whie approveformyorg is executed that i have to distribute to be approved from all server .
I mean like the file produced in sign process when making channel configuration update ?

How to selectively configure orderer nodes for particular channels?

Mr.Phuwanai Thummavet
 

Dear all,

I have a requirement to selectively configure ordering service nodes for particular channels.
For example, there is a consortium of 5 OSN organizations and I want to create 2 channels.

For the first channel, 3 of them would be selectively configured, whereas 
all the OSN nodes would be configured for the second channel.
How can I achieve that?

Thank you.
--
Best Regards,
Phuwanai Thummavet
Blockchain Architect and Full-Stack Developer

Documentation Workgroup: Agenda for Friday, 10 July

Anthony O'Dowd
 

Hi All,

We will hold the documentation workgroup calls this Friday -- with both an Eastern hemisphere and Western hemisphere call. We hope our US colleagues had a fruitful  Independence Day! 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+07+03+DWG+Agenda You'll see significant minutes for both the Eastern and Western hemisphere calls, and recordings for both sessions. Our Eastern and Western hemisphere calls are very well attended at the moment -- thanks to all for your contributions and collaboration.

Our Eastern hemisphere had excellent contributions from the Japanese and Malayalam working group teams. Our Malayalam and Japanese workgroups are fully up and running, and very productive right now - thank you for your collaboration!.

Kondo-san and Nishijima-san from the Japanese workgroup shared details of their meet-up occurring  this week, and as a result of a most successful meeting, there has been wonderful increase in contributions to the Japanese translation this week. Thank you to the Japanese team, and looking forward to tomorrow's update.  

Aneena and the Malayalam team also provided a most impressive list of translation topics; the Malayalam translation is almost ready for publication.  Moreover,  Aneena and Saingits is organizing a Hyperledger study group for India, Japan, China and Australia Hyperledger users targeted for July 11;  contact Aneena for more details. She is also organizing a Women in Blockchain event -- with some great speakers.  We'll find out the latest on these activities on tomorrow's call. Thanks to Sangits College of Engineering for all their contributions.


Our Western hemisphere call kept us up to date with these as we approach 2.2! Anthony gave a quick update on the release. Renato took us through his Portuguese translation with an update on a potential Spanish translation. The Portugues translation is now ready for publication and we're working with Brett to iron out one remaining CI pipeline issue. We also did a review of the i18n repository.  It was a cosy, but productive session!


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+7+10+DWG+Agenda for this week's agenda for the eastern and western hemisphere calls.

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

Thanks!

Pam,  Joe, Anthony

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 136A: Friday 10 July
                   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 136B: Friday 10 July
              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

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 07/10/2020 #cal-notice

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

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When:
Friday, 10 July 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

Re: ANNOUNCEMENT: Hyperledger Fabric v2.2 LTS is now available!

David Enyeart
 

Hi David, the merged RFC is a summary of several of the contributor meeting discussions:
https://github.com/hyperledger/fabric-rfcs/blob/master/text/0005-lts-release-strategy.md


Dave Enyeart

"david liu" ---07/09/2020 09:27:41 PM---Congratulations! Dave, would you mind share the link about LTS lifecycle strategy explanation here?

From: "david liu" <david-khala@...>
To: David Enyeart <enyeart@...>, fabric <fabric@...>
Date: 07/09/2020 09:27 PM
Subject: [EXTERNAL] 回复: [Hyperledger Fabric] ANNOUNCEMENT: Hyperledger Fabric v2.2 LTS is now available!
Sent by: fabric@...





Congratulations! Dave, would you mind share the link about LTS lifecycle strategy explanation here?
I mean the one used in one of past contributor meetings.

Best Regards,
David Liu

发件人: David Enyeart
发送时间:
2020年7月10日 4:38
收件人:
fabric
主题:
[Hyperledger Fabric] ANNOUNCEMENT: Hyperledger Fabric v2.2 LTS is now available!

The Hyperledger Fabric maintainers are pleased to announce the availability of Fabric v2.2.0!

v2.2 continues to build on the v2.0 foundation with additional improvements and fixes. For details, check out the release notes:
https://github.com/hyperledger/fabric/releases/tag/v2.2.0

Additionally we are happy to announce that v2.2 is the next long-term support (LTS) release for Hyperledger Fabric. v2.2.x will be the target release for most fix backports, while the most important fixes will continue to be backported to v1.4.x as well.

More details of the LTS strategy can be found in the RFC that was merged earlier this year:
https://github.com/hyperledger/fabric-rfcs/blob/master/text/0005-lts-release-strategy.md

Finally, it is worth noting that the 'latest' tag on dockerhub images has been retired. We felt that the tag was too confusing, given that there is a combination of regular releases and LTS releases available now - the definition of 'latest' may not be the same for everyone.

Give v2.2 a try and let us know what you think!
https://hyperledger-fabric.readthedocs.io/en/release-2.2/install.html


The Hyperledger Fabric maintainers




回复: [Hyperledger Fabric] ANNOUNCEMENT: Hyperledger Fabric v2.2 LTS is now available!

david liu
 

Congratulations! Dave, would you mind share the link about LTS lifecycle strategy explanation here?
I mean the one used in one of past contributor meetings.

 

Best Regards,

David Liu

 

发件人: David Enyeart
发送时间: 2020710 4:38
收件人: fabric
主题: [Hyperledger Fabric] ANNOUNCEMENT: Hyperledger Fabric v2.2 LTS is now available!

 

The Hyperledger Fabric maintainers are pleased to announce the availability of Fabric v2.2.0!

v2.2 continues to build on the v2.0 foundation with additional improvements and fixes. For details, check out the release notes:
https://github.com/hyperledger/fabric/releases/tag/v2.2.0

Additionally we are happy to announce that v2.2 is the next long-term support (LTS) release for Hyperledger Fabric. v2.2.x will be the target release for most fix backports, while the most important fixes will continue to be backported to v1.4.x as well.

More details of the LTS strategy can be found in the RFC that was merged earlier this year:
https://github.com/hyperledger/fabric-rfcs/blob/master/text/0005-lts-release-strategy.md

Finally, it is worth noting that the 'latest' tag on dockerhub images has been retired. We felt that the tag was too confusing, given that there is a combination of regular releases and LTS releases available now - the definition of 'latest' may not be the same for everyone.

Give v2.2 a try and let us know what you think!
https://hyperledger-fabric.readthedocs.io/en/release-2.2/install.html


The Hyperledger Fabric maintainers

 

ANNOUNCEMENT: Hyperledger Fabric v2.2 LTS is now available!

David Enyeart
 

The Hyperledger Fabric maintainers are pleased to announce the availability of Fabric v2.2.0!

v2.2 continues to build on the v2.0 foundation with additional improvements and fixes. For details, check out the release notes:
https://github.com/hyperledger/fabric/releases/tag/v2.2.0

Additionally we are happy to announce that v2.2 is the next long-term support (LTS) release for Hyperledger Fabric. v2.2.x will be the target release for most fix backports, while the most important fixes will continue to be backported to v1.4.x as well.

More details of the LTS strategy can be found in the RFC that was merged earlier this year:
https://github.com/hyperledger/fabric-rfcs/blob/master/text/0005-lts-release-strategy.md

Finally, it is worth noting that the 'latest' tag on dockerhub images has been retired. We felt that the tag was too confusing, given that there is a combination of regular releases and LTS releases available now - the definition of 'latest' may not be the same for everyone.

Give v2.2 a try and let us know what you think!
https://hyperledger-fabric.readthedocs.io/en/release-2.2/install.html


The Hyperledger Fabric maintainers

Hyperledger Project Quarterly Update Due #tsc-project-update - Thu, 07/09/2020 #tsc-project-update #cal-notice

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

Hyperledger Project Quarterly Update Due #tsc-project-update

When:
Thursday, 9 July 2020

Organizer:
community-architects@...

Description:
Please file a project status report for the TSC here:

https://wiki.hyperledger.org/display/TSC/Project+Status+Updates

Re: Critical: Chaincode package Installation error in Openshift Platform with Fabric v2.1.0 using external chaincode service #fabric #externalbuilders

Brett T Logan
 

This is correct. Docker is still the default implementation if none of the externalBuilders you set pass validation. You would need to do more debugging to figure out why the externalBuidlers you specified in `core.yaml` were not picked up (and as such the peer fell back to its default behavior).
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: keerthycbe@...
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Critical: Chaincode package Installation error in Openshift Platform with Fabric v2.1.0 using external chaincode service #fabric #externalbuilders
Date: Thu, Jul 9, 2020 12:44 PM
 
Hi All,

We are trying to deploy fabric nodes with external chaincode service option in Openshift platform 4.3. As the Openshift platform doesn't have access to docker daemon for peer to create chaincode container, we are using the external chaincode service feature provided in version 2.0. All our nodes are running 2.1.0 but getting the following error while installing chaincode in peer nodes from the cli container. There should not be any docker dependency as we have moved to the external chainocde option. Please find below the screenshot for error details. Appreciate any help on this.
 


Thanks and Regards
Keerthi
 

Critical: Chaincode package Installation error in Openshift Platform with Fabric v2.1.0 using external chaincode service #fabric #externalbuilders

keerthycbe@...
 

Hi All,

We are trying to deploy fabric nodes with external chaincode service option in Openshift platform 4.3. As the Openshift platform doesn't have access to docker daemon for peer to create chaincode container, we are using the external chaincode service feature provided in version 2.0. All our nodes are running 2.1.0 but getting the following error while installing chaincode in peer nodes from the cli container. There should not be any docker dependency as we have moved to the external chainocde option. Please find below the screenshot for error details. Appreciate any help on this.
 


Thanks and Regards
Keerthi

Re: Chain code install approval and commit on existing channel .

p.kirkinezis@...
 

Yeah what about when 2 organizations  exist on separate servers ?
You have to exchange tls keys with secure copy and then run the commit command on one of the servers ?