Date   

Document that lists all the International Standards relating to Fabric

JH Ohm
 

Hi,

Is there any document or webpage that lists all the International Standards which is relevant to any part/component of Fabric and its governing body as well?
Or can anybody guess the number of such standards at least?
There will be lot, maybe unlimited number of them but I particularly focus on some of them which can be accepted as something officially&widely adapted in Fabric...for example the below would be those relating to cryptography part.
Is there anything relating to quality assurance as well?  This kind of list would be requested by clients sometimes for sure.....

Best,
JH


Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 02/12/2021 #cal-notice

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

Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When:
Friday, 12 February 2021
11:00am to 12:00pm
(GMT-05:00) America/New York

Where:
https://zoom.us/my/hyperledger.community.backup?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09

Organizer:
pama@...

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

Join Zoom Meeting
https://zoom.us/j/6223336701?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09
 
Meeting ID: 622 333 6701
Passcode: 475869


Re: Fabric 2.0: commit readiness returns false but approvalformyorg returned success

Manindra Singh
 

Hi All,

Just to close this thread, I had restarted the network and ran through the steps again and it worked fine without making any fix. Could not reproduce the issue again. Thanks.


Re: Chaincode logs

Santiago Figueroa Lorenzo
 

 Thanks for the response,

Regarding log storage for monitoring, do you know of any projects that are in this direction to contribute?

Regards,

Santiago.

On Thu, Feb 11, 2021 at 10:15 AM Matthew White <WHITEMAT@...> wrote:
Hello;
 
Each chaincode language uses a 'natural-to-the-language' logging library, eg java.util.Logging or winston.  The user's implementation likewise can hook into these libraries. 
For a typical K8S deployment the logs will be written to STDOUT to be picked up the tooling of your choice.  
 
There's no in-built mechanism to store the logs or hashes on ledger..  Though that it self could be coded in a separate chaincode. 
 
 
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: "Santiago Figueroa Lorenzo" <santiagofigueroalorenzo@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Chaincode logs
Date: Wed, Feb 10, 2021 8:47 PM
 
Hi Fabric experts,

I am attempting to develop a methodology to retrieve logs from the chaincode, in order to visualize in Kibana through ELK infrastructure. At the moment, I am retrieving chaincode logs using the logrus (https://github.com/sirupsen/logrus) library. As part of the log is included relevant information such as channel id, chaincode name, method implemented and the type of log (information, error, etc). For instance:

image.png
 
In this regards, I have two questions:

1. Is there another more efficient way to retrieve logs?

2. Although the information at the time of retrieval is reliable (from chaincode container), with this method, once the data are in transit to Kibana I would have no way to trust on this data. Is there some mechanism, similar to what Ethereum does with its events, that allows to leave some mark in the ledger for these logs?


Thanks in advance,

Santiago.
 
 
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: Weird "panic: runtime error" after multiple transactions

Manish
 

I would have expected more in the leveldb logs after opening, as you get this crash after a while. Anyways, looking at goleveldb code, the other possibility is that in the Fabric code, under some circumstances, we end up invoking this Release function in parallel goroutine.

I'll suggest opening a Jira for this and attach the Fabric logs and leveldb logs.

Thanks,
Manish

On Thu, Feb 11, 2021 at 5:09 PM Tomás Peixinho <tom.peixinho@...> wrote:
After checking the logs (with some help from Dave Enyart), I don't see any "db@close". I see the "db@open" and the hours seem correct. 

18:49:21.592582 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
18:49:21.696795 db@open opening
18:49:21.698575 version@stat F·[] S·0B[] Sc·[]
18:49:21.702405 db@janitor F·2 G·0
18:49:21.702453 db@open done T·5.62227ms

I assume the "db@close" would be an entry if the peer had exited correctly, or am I thinking about it wrong? 


De: Manish Sethi <manish.sethi@...>
Enviado: quarta-feira, 10 de fevereiro de 2021 21:21
Para: Tomás Peixinho <tom.peixinho@...>
Cc: David Enyeart <enyeart@...>; fabric@... <fabric@...>
Assunto: Re: [Hyperledger Fabric] Weird "panic: runtime error" after multiple transactions
 
Hi Tomás,

I had seen something similar in a test flake in the past and the issue was a race condition between the closing of the levelDB and acquiring an iterator. I am not sure if that's app;icable here still, to clear any doubts, can you check your leveldb logs (located at {peer.fileSystemPath in core.yaml}/ledgersData/stateLeveldb/LOG near the time of this panic. Do you see something like this - "db@close"? If not, sharing the log may help further.

Thanks,
Manish

On Wed, Feb 10, 2021 at 2:57 PM Tomás Peixinho <tom.peixinho@...> wrote:
I was reading about similar issues in fabric version 1.4.2 (the images I'm using on my containers are 1.4.1, so I'm not sure if it is related at all or not), and how it was related to a certain timeout when one of the containers stops (from an issue on Jira from August 2019, https://jira.hyperledger.org/browse/FAB-16292). Don't know if that's what is happening. Last execution, it stopped after approximately 15 minutes, but I've seen it crash sooner and later.


The full error message is as follows:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x1c pc=0xb4e221]

goroutine 1265 [running]:
github.com/hyperledger/fabric/protos/peer._ChaincodeSupport_Register_Handler(0x118c540, 0xc00054c360, 0x13bbe80, 0xc0005769a0, 0x1fc5e60, 0xc0032ef230)
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processStreamingRPC(0xc00031c000, 0x13bf540, 0xc002258a80, 0xc0003f3000, 0xc0003487b0, 0x1ea8a40, 0xc0032ef200, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:684 +0xa1



De: David Enyeart <enyeart@...>
Enviado: quarta-feira, 10 de fevereiro de 2021 19:31
Para: Tomás Peixinho <tom.peixinho@...>
Cc: fabric@... <fabric@...>
Assunto: Re: [Hyperledger Fabric] Weird "panic: runtime error" after multiple transactions
 

You would need to provide the full stack trace from the panic message in order to troubleshoot.


Dave Enyeart

"Tomás Peixinho" ---02/10/2021 01:34:13 PM---Good afternoon fellow colleagues, I'm developing an application using Hyperledger Fabric and I've fo

From: "Tomás Peixinho" <tom.peixinho@...>
To: "fabric@..." <fabric@...>
Date: 02/10/2021 01:34 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Weird "panic: runtime error" after multiple transactions
Sent by: fabric@...





Good afternoon fellow colleagues, I'm developing an application...
This Message Is From an External Sender
This message came from outside your organization.
Good afternoon fellow colleagues,

I'm developing an application using Hyperledger Fabric and I've found a weird error that I'm not sure how to fix.

I'm running everything on just one machine, with two orgs, one peer on each, and one orderer. My application receives a file with multiple lines (right now, around 5000), which correspond to one transaction each (technically, two transactions each, because I have to do a query by partial key, and then a separate transaction for the actual update, as per recommendation of Dave Enyart, from a previous question of mine). So, 5000 lines, around 10000 transactions. They are being handled concurrently using threads. And the peers are being alternated, so that one doesn't happen to take all the load, while the other does nothing.

My problem now is that it usually ends with one of the peers randomly crashing with an Exit Code 2, and the logs from that peer saying "panic: runtime error: invalid memory address or nil pointer dereference". I say randomly because it can happen after a 1000 lines (2000 transactions) or 4000 lines (8000 transactions), which is what I find weird!

I've read that it could be because of problems with certificates or with misconfigured paths for them, but I feel that if that were the case, it would happen much sooner, or actually right at the start.

My question now is (and I know that I haven't provided much information or any logs, and that it's difficult to find the problem like this) if there is any obvious situation in which this might happen? Or if there are a few cases that might lead to this error? Something that might point me in the right direction of what I need to be looking at to see if I have any configuration problems. Or could it simply be a problem of my physical machine? Could it be just a memory problem, which crashes the peer if the traffic gets too heavy?

These errors are really not obvious sometimes, and I was just wondering if someone might have some insight as to what the problem might be, based on previous experiences or something.

Thanks in advance

Tomás




Re: Weird "panic: runtime error" after multiple transactions

Tomás Peixinho
 

After checking the logs (with some help from Dave Enyart), I don't see any "db@close". I see the "db@open" and the hours seem correct. 

18:49:21.592582 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
18:49:21.696795 db@open opening
18:49:21.698575 version@stat F·[] S·0B[] Sc·[]
18:49:21.702405 db@janitor F·2 G·0
18:49:21.702453 db@open done T·5.62227ms

I assume the "db@close" would be an entry if the peer had exited correctly, or am I thinking about it wrong? 


De: Manish Sethi <manish.sethi@...>
Enviado: quarta-feira, 10 de fevereiro de 2021 21:21
Para: Tomás Peixinho <tom.peixinho@...>
Cc: David Enyeart <enyeart@...>; fabric@... <fabric@...>
Assunto: Re: [Hyperledger Fabric] Weird "panic: runtime error" after multiple transactions
 
Hi Tomás,

I had seen something similar in a test flake in the past and the issue was a race condition between the closing of the levelDB and acquiring an iterator. I am not sure if that's app;icable here still, to clear any doubts, can you check your leveldb logs (located at {peer.fileSystemPath in core.yaml}/ledgersData/stateLeveldb/LOG near the time of this panic. Do you see something like this - "db@close"? If not, sharing the log may help further.

Thanks,
Manish

On Wed, Feb 10, 2021 at 2:57 PM Tomás Peixinho <tom.peixinho@...> wrote:
I was reading about similar issues in fabric version 1.4.2 (the images I'm using on my containers are 1.4.1, so I'm not sure if it is related at all or not), and how it was related to a certain timeout when one of the containers stops (from an issue on Jira from August 2019, https://jira.hyperledger.org/browse/FAB-16292). Don't know if that's what is happening. Last execution, it stopped after approximately 15 minutes, but I've seen it crash sooner and later.


The full error message is as follows:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x1c pc=0xb4e221]

goroutine 1265 [running]:
github.com/hyperledger/fabric/protos/peer._ChaincodeSupport_Register_Handler(0x118c540, 0xc00054c360, 0x13bbe80, 0xc0005769a0, 0x1fc5e60, 0xc0032ef230)
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processStreamingRPC(0xc00031c000, 0x13bf540, 0xc002258a80, 0xc0003f3000, 0xc0003487b0, 0x1ea8a40, 0xc0032ef200, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:684 +0xa1



De: David Enyeart <enyeart@...>
Enviado: quarta-feira, 10 de fevereiro de 2021 19:31
Para: Tomás Peixinho <tom.peixinho@...>
Cc: fabric@... <fabric@...>
Assunto: Re: [Hyperledger Fabric] Weird "panic: runtime error" after multiple transactions
 

You would need to provide the full stack trace from the panic message in order to troubleshoot.


Dave Enyeart

"Tomás Peixinho" ---02/10/2021 01:34:13 PM---Good afternoon fellow colleagues, I'm developing an application using Hyperledger Fabric and I've fo

From: "Tomás Peixinho" <tom.peixinho@...>
To: "fabric@..." <fabric@...>
Date: 02/10/2021 01:34 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Weird "panic: runtime error" after multiple transactions
Sent by: fabric@...





Good afternoon fellow colleagues, I'm developing an application...
This Message Is From an External Sender
This message came from outside your organization.
Good afternoon fellow colleagues,

I'm developing an application using Hyperledger Fabric and I've found a weird error that I'm not sure how to fix.

I'm running everything on just one machine, with two orgs, one peer on each, and one orderer. My application receives a file with multiple lines (right now, around 5000), which correspond to one transaction each (technically, two transactions each, because I have to do a query by partial key, and then a separate transaction for the actual update, as per recommendation of Dave Enyart, from a previous question of mine). So, 5000 lines, around 10000 transactions. They are being handled concurrently using threads. And the peers are being alternated, so that one doesn't happen to take all the load, while the other does nothing.

My problem now is that it usually ends with one of the peers randomly crashing with an Exit Code 2, and the logs from that peer saying "panic: runtime error: invalid memory address or nil pointer dereference". I say randomly because it can happen after a 1000 lines (2000 transactions) or 4000 lines (8000 transactions), which is what I find weird!

I've read that it could be because of problems with certificates or with misconfigured paths for them, but I feel that if that were the case, it would happen much sooner, or actually right at the start.

My question now is (and I know that I haven't provided much information or any logs, and that it's difficult to find the problem like this) if there is any obvious situation in which this might happen? Or if there are a few cases that might lead to this error? Something that might point me in the right direction of what I need to be looking at to see if I have any configuration problems. Or could it simply be a problem of my physical machine? Could it be just a memory problem, which crashes the peer if the traffic gets too heavy?

These errors are really not obvious sometimes, and I was just wondering if someone might have some insight as to what the problem might be, based on previous experiences or something.

Thanks in advance

Tomás




Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads

David Enyeart
 

Yes.


Dave Enyeart

"Tomás Peixinho" ---02/11/2021 01:44:53 PM---My query functions are being called from the "invoke" function. Does that mean that they are seen as

From: "Tomás Peixinho" <tom.peixinho@...>
To: David Enyeart <enyeart@...>
Cc: "fabric@..." <fabric@...>
Date: 02/11/2021 01:44 PM
Subject: [EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by: fabric@...





My query functions are being called from the "invoke" function....
This Message Is From an External Sender
This message came from outside your organization.
My query functions are being called from the "invoke" function. Does that mean that they are seen as invokes as well? Is that why they are being put into the blocks?



De: David Enyeart <enyeart@...>
Enviado:
quinta-feira, 11 de fevereiro de 2021 18:17
Para:
David Enyeart <enyeart@...>
Cc:
fabric@... <fabric@...>; Tomás Peixinho <tom.peixinho@...>
Assunto:
Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads

Typo fixed:

"peer chaincode query" will execute chaincode and return results to client. No block transaction.
"peer chaincode invoke" will execute chaincode and submit results to ordering into a block transaction.
It doesn't matter if the chaincode attempts to read or write or read/write.


Dave Enyeart

"David Enyeart" ---02/11/2021 01:16:38 PM---"peer channel query" will execute chaincode and return results to client. No block transaction.

From:
"David Enyeart" <enyeart@...>
To:
"Tomás Peixinho" <tom.peixinho@...>
Cc:
"fabric@..." <fabric@...>
Date:
02/11/2021 01:16 PM
Subject:
[EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by:
fabric@...





"Tomás Peixinho" ---02/11/2021 01:05:35 PM---Do queries by partial composite key work differently? Because judging by the number of blocks that a

From:
"Tomás Peixinho" <tom.peixinho@...>
To:
David Enyeart <enyeart@...>
Cc:
"fabric@..." <fabric@...>
Date:
02/11/2021 01:05 PM
Subject:
[EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by:
fabric@...




Do queries by partial composite key work differently? Because...
This Message Is From an External Sender
This message came from outside your organization.
Do queries by partial composite key work differently? Because judging by the number of blocks that are being stored in my case, it appears that the query transactions are being stored in the blocks, as well as the second transactions with the actual updates.



De:
fabric@... <fabric@...> em nome de David Enyeart <enyeart@...>
Enviado:
quinta-feira, 11 de fevereiro de 2021 14:12
Para:
Samyak Jain | TraceX <samyakj@...>
Cc:
fabric@... <fabric@...>
Assunto:
Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads

Every transaction has to be submitted from a client application, it could be a different client application though. Calling it a '2nd transaction' was misleading on my part though... the '1st' one was just a read-only query, not actually a transaction. The subsequent one would do any updates.


Dave Enyeart

"Samyak Jain | TraceX" ---02/11/2021 04:09:42 AM---Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be

From:
"Samyak Jain | TraceX" <samyakj@...>
To:
fabric@...
Date:
02/11/2021 04:09 AM
Subject:
[EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by:
fabric@...





Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be initiated from the client application?
Thanks, Samyak Jain









Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads

Tomás Peixinho
 

My query functions are being called from the "invoke" function. Does that mean that they are seen as invokes as well? Is that why they are being put into the blocks?


De: David Enyeart <enyeart@...>
Enviado: quinta-feira, 11 de fevereiro de 2021 18:17
Para: David Enyeart <enyeart@...>
Cc: fabric@... <fabric@...>; Tomás Peixinho <tom.peixinho@...>
Assunto: Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
 

Typo fixed:

"peer chaincode query" will execute chaincode and return results to client. No block transaction.
"peer chaincode invoke" will execute chaincode and submit results to ordering into a block transaction.
It doesn't matter if the chaincode attempts to read or write or read/write.


Dave Enyeart

"David Enyeart" ---02/11/2021 01:16:38 PM---"peer channel query" will execute chaincode and return results to client. No block transaction.

From: "David Enyeart" <enyeart@...>
To: "Tomás Peixinho" <tom.peixinho@...>
Cc: "fabric@..." <fabric@...>
Date: 02/11/2021 01:16 PM
Subject: [EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by: fabric@...





"Tomás Peixinho" ---02/11/2021 01:05:35 PM---Do queries by partial composite key work differently? Because judging by the number of blocks that a

From:
"Tomás Peixinho" <tom.peixinho@...>
To:
David Enyeart <enyeart@...>
Cc:
"fabric@..." <fabric@...>
Date:
02/11/2021 01:05 PM
Subject:
[EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by:
fabric@...




Do queries by partial composite key work differently? Because...
This Message Is From an External Sender
This message came from outside your organization.
Do queries by partial composite key work differently? Because judging by the number of blocks that are being stored in my case, it appears that the query transactions are being stored in the blocks, as well as the second transactions with the actual updates.



De:
fabric@... <fabric@...> em nome de David Enyeart <enyeart@...>
Enviado:
quinta-feira, 11 de fevereiro de 2021 14:12
Para:
Samyak Jain | TraceX <samyakj@...>
Cc:
fabric@... <fabric@...>
Assunto:
Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads

Every transaction has to be submitted from a client application, it could be a different client application though. Calling it a '2nd transaction' was misleading on my part though... the '1st' one was just a read-only query, not actually a transaction. The subsequent one would do any updates.


Dave Enyeart

"Samyak Jain | TraceX" ---02/11/2021 04:09:42 AM---Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be

From:
"Samyak Jain | TraceX" <samyakj@...>
To:
fabric@...
Date:
02/11/2021 04:09 AM
Subject:
[EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by:
fabric@...





Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be initiated from the client application?
Thanks, Samyak Jain







Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads

David Enyeart
 

Typo fixed:

"peer chaincode query" will execute chaincode and return results to client. No block transaction.
"peer chaincode invoke" will execute chaincode and submit results to ordering into a block transaction.
It doesn't matter if the chaincode attempts to read or write or read/write.


Dave Enyeart

"David Enyeart" ---02/11/2021 01:16:38 PM---"peer channel query" will execute chaincode and return results to client. No block transaction.

From: "David Enyeart" <enyeart@...>
To: "Tomás Peixinho" <tom.peixinho@...>
Cc: "fabric@..." <fabric@...>
Date: 02/11/2021 01:16 PM
Subject: [EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by: fabric@...





"Tomás Peixinho" ---02/11/2021 01:05:35 PM---Do queries by partial composite key work differently? Because judging by the number of blocks that a

From:
"Tomás Peixinho" <tom.peixinho@...>
To:
David Enyeart <enyeart@...>
Cc:
"fabric@..." <fabric@...>
Date:
02/11/2021 01:05 PM
Subject:
[EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by:
fabric@...




Do queries by partial composite key work differently? Because...
This Message Is From an External Sender
This message came from outside your organization.
Do queries by partial composite key work differently? Because judging by the number of blocks that are being stored in my case, it appears that the query transactions are being stored in the blocks, as well as the second transactions with the actual updates.



De:
fabric@... <fabric@...> em nome de David Enyeart <enyeart@...>
Enviado:
quinta-feira, 11 de fevereiro de 2021 14:12
Para:
Samyak Jain | TraceX <samyakj@...>
Cc:
fabric@... <fabric@...>
Assunto:
Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads

Every transaction has to be submitted from a client application, it could be a different client application though. Calling it a '2nd transaction' was misleading on my part though... the '1st' one was just a read-only query, not actually a transaction. The subsequent one would do any updates.


Dave Enyeart

"Samyak Jain | TraceX" ---02/11/2021 04:09:42 AM---Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be

From:
"Samyak Jain | TraceX" <samyakj@...>
To:
fabric@...
Date:
02/11/2021 04:09 AM
Subject:
[EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by:
fabric@...





Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be initiated from the client application?
Thanks, Samyak Jain







Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads

David Enyeart
 

"peer channel query" will execute chaincode and return results to client. No block transaction.
"peer channel invoke" will execute chaincode and submit results to ordering into a block transaction.
It doesn't matter if the chaincode attempts to read or write or read/write.


Dave Enyeart

"Tomás Peixinho" ---02/11/2021 01:05:35 PM---Do queries by partial composite key work differently? Because judging by the number of blocks that a

From: "Tomás Peixinho" <tom.peixinho@...>
To: David Enyeart <enyeart@...>
Cc: "fabric@..." <fabric@...>
Date: 02/11/2021 01:05 PM
Subject: [EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by: fabric@...





Do queries by partial composite key work differently? Because...
This Message Is From an External Sender
This message came from outside your organization.
Do queries by partial composite key work differently? Because judging by the number of blocks that are being stored in my case, it appears that the query transactions are being stored in the blocks, as well as the second transactions with the actual updates.



De: fabric@... <fabric@...> em nome de David Enyeart <enyeart@...>
Enviado:
quinta-feira, 11 de fevereiro de 2021 14:12
Para:
Samyak Jain | TraceX <samyakj@...>
Cc:
fabric@... <fabric@...>
Assunto:
Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads

Every transaction has to be submitted from a client application, it could be a different client application though. Calling it a '2nd transaction' was misleading on my part though... the '1st' one was just a read-only query, not actually a transaction. The subsequent one would do any updates.


Dave Enyeart

"Samyak Jain | TraceX" ---02/11/2021 04:09:42 AM---Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be

From:
"Samyak Jain | TraceX" <samyakj@...>
To:
fabric@...
Date:
02/11/2021 04:09 AM
Subject:
[EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by:
fabric@...





Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be initiated from the client application?
Thanks, Samyak Jain






Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads

Tomás Peixinho
 

Do queries by partial composite key work differently? Because judging by the number of blocks that are being stored in my case, it appears that the query transactions are being stored in the blocks, as well as the second transactions with the actual updates.


De: fabric@... <fabric@...> em nome de David Enyeart <enyeart@...>
Enviado: quinta-feira, 11 de fevereiro de 2021 14:12
Para: Samyak Jain | TraceX <samyakj@...>
Cc: fabric@... <fabric@...>
Assunto: Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
 

Every transaction has to be submitted from a client application, it could be a different client application though. Calling it a '2nd transaction' was misleading on my part though... the '1st' one was just a read-only query, not actually a transaction. The subsequent one would do any updates.


Dave Enyeart

"Samyak Jain | TraceX" ---02/11/2021 04:09:42 AM---Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be

From: "Samyak Jain | TraceX" <samyakj@...>
To: fabric@...
Date: 02/11/2021 04:09 AM
Subject: [EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by: fabric@...





Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be initiated from the client application?

Thanks, Samyak Jain





Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 02/12/2021 11:00am-12:00pm #cal-reminder

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

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 12 February 2021, 11:00am to 12:00pm, (GMT-05:00) America/New York

Where:https://zoom.us/my/hyperledger.community.backup?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09

View Event

Organizer: Pam Andrejko pama@...

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

Join Zoom Meeting
https://zoom.us/j/6223336701?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09
 
Meeting ID: 622 333 6701
Passcode: 475869


Re: Weird "panic: runtime error" after multiple transactions

David Enyeart
 

For finding the peer files, I find it easier to change the peer's volume in docker-compose-test-net.yaml (if using test network) to a local directory like this (last entry):

volumes:
- /var/run/docker.sock:/host/var/run/docker.sock
- ../organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp
- ../organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls:/etc/hyperledger/fabric/tls
- /tmp/fabric/data/peer0.org1.example.com:/var/hyperledger/production

Then even after peer crash you'll find the statedb files at:
/tmp/fabric/data/peer0.org1.example.com/ledgersData/stateLeveldb

core.yaml can be found within the peer container at /etc/hyperledger/fabric/core.yaml (it is not mapped to an external volume).

Since this thread is getting involved, I'd encourage you to open a Jira bug where you can post the files - https://jira.hyperledger.org/issues/?filter=13110


Dave Enyeart

"Tomás Peixinho" ---02/10/2021 05:24:29 PM---I can't seem to find that file. I can't check from inside the peer, because the peer exited. If I tr

From: "Tomás Peixinho" <tom.peixinho@...>
To: Manish Sethi <manish.sethi@...>
Cc: "fabric@..." <fabric@...>
Date: 02/10/2021 05:24 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Weird "panic: runtime error" after multiple transactions
Sent by: fabric@...





I can't seem to find that file. I can't check from inside the peer,...
This Message Is From an External Sender
This message came from outside your organization.
I can't seem to find that file. I can't check from inside the peer, because the peer exited. If I try to run "docker-compose run" with the peer id, it says "service not found", which seems expected, and I can't exec to it because it is down. And from the outside, I can't seem to find any logs in "/var/lib/docker/volumes/network_peer1.org1.example.com/_data", which I think is the right path. That last folder should have a ledgersData subfolder in it but it's completely empty. Am I looking in the wrong place?

As for the logs, the one from the peer, apart from the final stack trace which I have already shared, don't really show me anything, it's just blocks being received and transactions being commited. From the orderer, there's nothing out of the ordinary, it's just grpc calls from what I assume are the blocks being sent to the peers.

Also, I can't seem to find the core.yaml file. Any idea where it might be?



De: Manish Sethi <manish.sethi@...>
Enviado:
quarta-feira, 10 de fevereiro de 2021 21:21
Para:
Tomás Peixinho <tom.peixinho@...>
Cc:
David Enyeart <enyeart@...>; fabric@... <fabric@...>
Assunto:
Re: [Hyperledger Fabric] Weird "panic: runtime error" after multiple transactions

Hi Tomás,

I had seen something similar in a test flake in the past and the issue was a race condition between the closing of the levelDB and acquiring an iterator. I am not sure if that's app;icable here still, to clear any doubts, can you check your leveldb logs (located at {peer.fileSystemPath in core.yaml}/ledgersData/stateLeveldb/LOG near the time of this panic. Do you see something like this - "db@close"? If not, sharing the log may help further.

Thanks,
Manish

On Wed, Feb 10, 2021 at 2:57 PM Tomás Peixinho <tom.peixinho@...> wrote:




Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads

David Enyeart
 

Every transaction has to be submitted from a client application, it could be a different client application though. Calling it a '2nd transaction' was misleading on my part though... the '1st' one was just a read-only query, not actually a transaction. The subsequent one would do any updates.


Dave Enyeart

"Samyak Jain | TraceX" ---02/11/2021 04:09:42 AM---Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be

From: "Samyak Jain | TraceX" <samyakj@...>
To: fabric@...
Date: 02/11/2021 04:09 AM
Subject: [EXTERNAL] Re: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads
Sent by: fabric@...





Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be initiated from the client application?

Thanks, Samyak Jain





Failed validating identity message MSP

DAVID VIEJO POMATA
 

Hello,

A peer out of a network of 3 is having problems validating the messages from the gossip protocol:

Failed validating identity message: Peer Identity {
    "CN": "XXXXXXXXXXXXXXXXXXXXXX",
    "Issuer-CN": "ca.XXXXXXXXXXXXXXXXXXXXXX",
    "Issuer-L-ST-C": "XXXXXXXXXXXXXXXXXXXXXX",
    "Issuer-OU": [
        "XXXXXXXXXXXXXXXXXXXXXX"
    ],
    "L-ST-C": "XXXXXXXXXXXXXXXXXXXXXX",
    "MSP": "XXX",
    "OU": [
        "XXXXXXXXXXXXXXXXXXXXXX",
        "peer"
    ]
} cannot be validated. No MSP found able to do that.


The rest of the peers are throwing warnings:

2021-02-11T10:14:54.198189112Z 2021-02-11 10:14:54.197 UTC [gossip.privdata] reconcile -> WARN de8d93 missing private data is not available on other peers

I'm not sure what can be causing this problem, the private data collection is set with this configuration:
    "requiredPeerCount": 1,
    "maxPeerCount": 3,
    "blockToLive": 0,


The peers are set as static leaders since synchronization through gossip protocol is very slow, more information about this subject in this JIRA https://jira.hyperledger.org/browse/FAB-18371.

Any idea? Someone that has stomped through this issue?

Thanks in advance!!
David Viejo.




Re: Chaincode logs

Matthew White
 

Hello;
 
Each chaincode language uses a 'natural-to-the-language' logging library, eg java.util.Logging or winston.  The user's implementation likewise can hook into these libraries. 
For a typical K8S deployment the logs will be written to STDOUT to be picked up the tooling of your choice.  
 
There's no in-built mechanism to store the logs or hashes on ledger..  Though that it self could be coded in a separate chaincode. 
 
 
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: "Santiago Figueroa Lorenzo" <santiagofigueroalorenzo@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Chaincode logs
Date: Wed, Feb 10, 2021 8:47 PM
 
Hi Fabric experts,

I am attempting to develop a methodology to retrieve logs from the chaincode, in order to visualize in Kibana through ELK infrastructure. At the moment, I am retrieving chaincode logs using the logrus (https://github.com/sirupsen/logrus) library. As part of the log is included relevant information such as channel id, chaincode name, method implemented and the type of log (information, error, etc). For instance:

image.png
 
In this regards, I have two questions:

1. Is there another more efficient way to retrieve logs?

2. Although the information at the time of retrieval is reliable (from chaincode container), with this method, once the data are in transit to Kibana I would have no way to trust on this data. Is there some mechanism, similar to what Ethereum does with its events, that allows to leave some mark in the ledger for these logs?


Thanks in advance,

Santiago.
 
 
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: ENC: [Hyperledger Fabric] Commit Phase Re-Validation - Phantom Reads

Samyak Jain | TraceX
 

Hi Dave, Follow up question to the approach you suggested - does the 2nd transaction then have to be initiated from the client application?

Thanks, Samyak Jain


Preventing double spends in Fabric and avoiding MVCC #fabric #hyperledger-fabric #fabric-chaincode

Samyak Jain | TraceX
 

Dear Community,

We are designing an application with a chaincode that holds asset information including product quantity. One of the functions the chaincode needs to support is aggregating multiple input products into an output and creating a new asset. Once this executes, the original input batches must be reduced with the corresponding quantity so that they cannot be double-spent. My concern is whether having multiple getStates (to compare remaining quantity of an input batch) and putStates (to save the updated quantity) in a function will lead to a MVCC error? If so, what will be the correct way of designing such a logic?

Thanks, Samyak Jain


Fabric Peer ledger Crashed when load Increase #fabric-sdk-node #fabric-chaincode #docker #fabric-kubernetes #network

inzamam ansari
 

Hi Team,

I have a kubernetes setup of HLF2.2 with Golang Chaincode and Nodejs SDK.
I am performing load test on the network, when i try with 250 Concurrent thread, it shows unexpectedly chaincode installation Error. (Error: Chaincode definiation exist but not found, make sure it's Installed properly)

Node SDK not able to find any endorsement peer for provided chaincode and throw Exception.

After inspecting I found that

  • 3 out 4 Peer's ledger were crashed.
  • Peer disconnects from channel.
  • It was not showing installed Chain-code. 
  • unable to Query or Invoke from Cli.

I tried restarting the cluster but no luck.

Then I had to re-Install new version of chaincode on Peer's, and it's working fine now.

I am bit worried about the robustness of HLF network and which is not giving me enough confidence to use it in production.

And also there is no mechanism to monitor container of Chaincode in kubernetes, as it does not show-up in the pods list. And even i am not sure how much of load is on Chain-code when performing load test.

I have allocated 4GB RAM and 2-Core CPU to each Peer. is that enough for production level setup.
How can we ensure that Chain-code's container gets enough resource allocation. Should I increase my peers RAM further.

 

I have already raise the same issue on jira on below link

https://jira.hyperledger.org/browse/FABCG-15


Re: ValidateLSCCInvocation failed error

jay park
 

Thank you for your help.
I was in wrong place. Yes, you are right. The container just started once we invoke.

Thanks again,
Jay.



From: David Enyeart <enyeart@...>
Sent: Wednesday, February 10, 2021 5:37 PM
To: jay park <jungil.park@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] ValidateLSCCInvocation failed error
 

You should not upgrade a 2nd or 3rd time.
Again - 'Upgrade' is a transaction on the channel, therefore you only need to do it once for the whole channel, not per peer or per organization.
The chaincode image will be built on each peer and chaincode container will spin up automatically when needed. When you invoke chaincode on the 3rd peer, are you getting some error message that leads you to believe that it can't start the container?


Dave Enyeart

"jay park" ---02/10/2021 07:53:09 AM---Hi David, Thank you for your response.

From: "jay park" <jungil.park@...>
To: David Enyeart <enyeart@...>
Cc: "fabric@..." <fabric@...>
Date: 02/10/2021 07:53 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] ValidateLSCCInvocation failed error
Sent by: fabric@...





Hi David, Thank you for your response. If you see below log, I first...
This Message Is From an External Sender
This message came from outside your organization.
Hi David,

Thank you for your response.

If you see below log, I first install on 4 peers.
And then upgrade two peers with success.
And third one is failed.

Actually, my problem is I have only two chaincode containers, I need one more for a different peer.
Could you advise how to do it?


===================== Chaincode is installed on peer1.org2 =====================
Upgrading chaincode on peer0.org1...
CORE_PEER_LOCALMSPID=Org1MSP
CORE_LOGGING_LEVEL=DEBUG
CORE_PEER_ID=cli
CORE_PEER_ADDRESS=peer0.org1.example.com:7051
CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/server.crt
CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/server.key
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@.../msp
CORE_PEER_TLS_ENABLED=true
+ peer chaincode upgrade -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n chaincode -l golang -v 2.55133w -c '{"Args":["init","1","0"]}' -P 'OR ('\''Org1MSP.peer'\'','\''Org2MSP.peer'\'')'
2021-02-10 11:49:58.434 UTC [main] InitCmd -> WARN 001 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2021-02-10 11:49:58.437 UTC [main] SetOrdererEnv -> WARN 002 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2021-02-10 11:49:58.445 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2021-02-10 11:49:58.445 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
+ res=0
+ set +x
2021-02-10 11:49:49.403 UTC [main] InitCmd -> WARN 001 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2021-02-10 11:49:49.406 UTC [main] SetOrdererEnv -> WARN 002 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2021-02-10 11:49:49.415 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2021-02-10 11:49:49.415 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2021-02-10 11:49:58.386 UTC [chaincodeCmd] submitInstallProposal -> INFO 005 Installed remotely: response:<status:200 payload:"OK" >
===================== Chaincode is upgraded on org1 peer0 =====================

Upgrading chaincode on peer0.org2...
CORE_PEER_LOCALMSPID=Org2MSP
CORE_LOGGING_LEVEL=DEBUG
CORE_PEER_ID=cli
CORE_PEER_ADDRESS=peer0.org2.example.com:7051
CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/server.crt
CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/server.key
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@.../msp
CORE_PEER_TLS_ENABLED=true
+ peer chaincode upgrade -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n chaincode -l golang -v 2.55133w -c '{"Args":["init","2","0"]}' -P 'OR ('\''Org1MSP.peer'\'','\''Org2MSP.peer'\'')'
2021-02-10 11:49:59.039 UTC [main] InitCmd -> WARN 001 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2021-02-10 11:49:59.042 UTC [main] SetOrdererEnv -> WARN 002 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2021-02-10 11:49:59.069 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2021-02-10 11:49:59.069 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
+ res=0
+ set +x
2021-02-10 11:49:49.403 UTC [main] InitCmd -> WARN 001 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2021-02-10 11:49:49.406 UTC [main] SetOrdererEnv -> WARN 002 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2021-02-10 11:49:49.415 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2021-02-10 11:49:49.415 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2021-02-10 11:49:58.386 UTC [chaincodeCmd] submitInstallProposal -> INFO 005 Installed remotely: response:<status:200 payload:"OK" >
===================== Chaincode is upgraded on org2 peer0 =====================

Upgrading chaincode on peer1.org1...
CORE_PEER_LOCALMSPID=Org1MSP
CORE_LOGGING_LEVEL=DEBUG
CORE_PEER_ID=cli
CORE_PEER_ADDRESS=peer1.org1.example.com:7051
CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/server.crt
CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/server.key
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@.../msp
CORE_PEER_TLS_ENABLED=true
+ peer chaincode upgrade -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n chaincode -l golang -v 2.55133w -c '{"Args":["init","1","1"]}' -P 'OR ('\''Org1MSP.peer'\'','\''Org2MSP.peer'\'')'
2021-02-10 11:49:59.778 UTC [main] InitCmd -> WARN 001 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2021-02-10 11:49:59.781 UTC [main] SetOrdererEnv -> WARN 002 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2021-02-10 11:49:59.795 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2021-02-10 11:49:59.795 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
Error: could not assemble transaction, err proposal response was not successful, error code 500, msg version already exists for chaincode with name 'chaincode'
+ res=1
+ set +x
2021-02-10 11:49:49.403 UTC [main] InitCmd -> WARN 001 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2021-02-10 11:49:49.406 UTC [main] SetOrdererEnv -> WARN 002 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2021-02-10 11:49:49.415 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2021-02-10 11:49:49.415 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2021-02-10 11:49:58.386 UTC [chaincodeCmd] submitInstallProposal -> INFO 005 Installed remotely: response:<status:200 payload:"OK" >
!!!!!!!!!!!!!!! Chaincode upgrade on org1 peer1 has Failed !!!!!!!!!!!!!!!!
========= ERROR !!! FAILED to execute End-2-End Scenario ===========








From: David Enyeart <enyeart@...>
Sent:
Tuesday, February 9, 2021 6:29 PM
To:
jay park <jungil.park@...>
Cc:
fabric@... <fabric@...>
Subject:
Re: [Hyperledger Fabric] ValidateLSCCInvocation failed error

It looks like you are using legacy chaincode. 'Upgrade' is a transaction on the channel, therefore you only need to do it once for the whole channel, not per peer or per organization.


Dave Enyeart

"jay park" ---02/08/2021 05:07:42 PM---Hi Team, I have two organizations and two peers each. For some reason, we just upgraded only one pee

From:
"jay park" <jungil.park@...>
To:
David Enyeart <enyeart@...>
Cc:
"fabric@..." <fabric@...>
Date:
02/08/2021 05:07 PM
Subject:
[EXTERNAL] [Hyperledger Fabric] ValidateLSCCInvocation failed error
Sent by:
fabric@...





Hi Team, I have two organizations and two peers each. For some...
This Message Is From an External Sender
This message came from outside your organization.
Hi Team,

I have two organizations and two peers each. For some reason, we just upgraded only one peer in each organization (but installed chaincode all peers).
Now I need to run all 4 peers but I have got error like below.
Does anyone know what could be the reason? And let me know how to fix it?

HF version : 2.1


Log :


2021-02-08 21:56:41.254 UTC [
BAAS-peer1.org1.example.com] [vscc] Validate -> ERRO 586 VSCC error: ValidateLSCCInvocation failed, err Existing version of the cc on the ledger (2.009) should be different from the upgraded one
2021-02-08 21:56:41.254 UTC [
BAAS-peer1.org1.example.com] [committer.txvalidator] ValidateWithPlugin -> DEBU 587 Transaction 58c925c7e278c656fac4638c3dd4b64e99a99cb3c1e0257ad17a0f6946b8e0fa appears to be invalid: Existing version of the cc on the ledger (2.009) should be different from the upgraded one
2021-02-08 21:56:41.254 UTC [
BAAS-peer1.org1.example.com] [committer.txvalidator] validateTx -> ERRO 588 VSCCValidateTx for transaction txId = 58c925c7e278c656fac4638c3dd4b64e99a99cb3c1e0257ad17a0f6946b8e0fa returned error: Existing version of the cc on the ledger (2.009) should be different from the upgraded one

Best Regards,
Jungil.







1641 - 1660 of 11218