I have the same feeling as your reply 。 But in the blockchain-application-using-fabric-java-sdk I change the language of chaincode from golang to java making no sense 。 In practice ， there is always u

#fabric-chaincode #fabric-sdk-java #fabric-chaincode-evm

Hello - that really does look like it's still trying to use GO rather than Java Chaincode. I would suggest at you look at the Fabric-Samples github repo or the IBM Blockchain VSExtension tutorials...

#fabric-chaincode #fabric-sdk-java #fabric-chaincode-evm

some enviroment infomation : i am using the https://github.com/IBM/blockchain-application-using-fabric-java-sdk to learn how to create the channel and deploy and initiate the chaincode on the channel

#fabric-chaincode #fabric-sdk-java #fabric-chaincode-evm

I tested miniFabric with Java ABstore chaincode from HLF fabric-sample code. Maybe some need to know how :) I don`t find examples of using at minifab github pages. And this work! Tested. date;./minifa

#minifab #hyperledger-fabric #fabric-sdk-java #windows10 #minifabric

Hello Matthew, This is exactly the behavior, there is a single request with payload that has for example 146 records. In my service I’m doing 146 'putState' calls to store data to CouchDb. The 100Kb i

#fabric-chaincode #fabric-sdk-java #hyperledger-fabric

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 ha

#fabric-chaincode #fabric-sdk-java #hyperledger-fabric

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 gatew

#fabric-chaincode #fabric-sdk-java #hyperledger-fabric

You are correct that EventHub is the wrong thing to be using, and this is removed in the v2.x SDK. If possible, I would strongly recommend using fabric-gateway-java rather than fabric-sdk-java. It lay

#fabric-sdk-java #fabric-sdk-node #hyperledger-fabric

I am trying to use Fabric Java SDK to perform chaincode related operations. For this purpose, I wish to make use of the new Channel Event Hub functionality for listening to different events, mainly Bl

#fabric-sdk-java #fabric-sdk-node #hyperledger-fabric

Just for confirmation - spoke with Marek on rocketchat, and the fix for FABCJ-285 will resolve this... will look to put our a patch release in the coming week. Regards, Matthew. Matthew B White IBM Bl

#couchdb #fabric-chaincode #fabric-sdk-java

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 r

#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@

#couchdb #fabric-chaincode #fabric-sdk-java

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 chai

#couchdb #fabric-chaincode #fabric-sdk-java

Hi David, I have tried to replicate the same scenario you setup with FabCar, because your response was quite nice (3500ms for 140 records, this would entirely acceptable for my team at this stage). I

#fabric-sdk-java #fabric-questions

I've been able to reproduce the problem. I updated FabCar to initialize 140 cars instead of 10. Query all cars takes the following times: Go chaincode - 70ms Javascript chaincode - 90ms Java chaincode

#fabric-sdk-java #fabric-questions

Query results iterator max count is hard coded to 100. It makes sense that it sends in batch of 100. What doesn't make sense is why the pause. A Query results iterator is also returned when performing

#fabric-sdk-java #fabric-questions

One more thing that I found. I’ve loaded 600+ records. The query took: 259 seconds. But the mysterious: lockbasedtxmgr has been iterating over the data in 6 groups of 100 items and last that was 16 it

#fabric-sdk-java #fabric-questions

Hi Prasanth, Please check the logs I have send in the last email. You can search for log entries from Class: ByteStorageBaseService This is the class where I make the getQueryResult method call. Betwe

#fabric-sdk-java #fabric-questions

I think you need to focus only on chaincode. Why not try adding detailed logs in chaincode with time, from the first point of contact (from Invoke / Query) to the deepest function in the nest and see:

#fabric-sdk-java #fabric-questions

Hi David, Yes, this is also something that I noticed. In the logs you can find the following process peer0.org1.example.com|[36m2020-05-06 18:24:07.093 UTC [lockbasedtxmgr] Next -> DEBU 3078[0m queryR

#fabric-sdk-java #fabric-questions