Closed ghost closed 5 years ago
I am thinking your issue is that you are calling accept_transaction on your own thread and not on the main thread that it is expected to be called on. accept_transaction does all of its processing on the thread that calls it, so all of your transactions are being performed on your thread and then any blocks you produce/receive are produced/applied on the main thread. So the reason that your application worked just fine when it was a separate process from nodeos was because it was allowing the http_plugin to handle the incoming transactions on the main thread. So to get this to work, you will need to do something similar to txn_test_gen_plugin and drive your plugin using an http_pluggin input and a timer or else you will need to create a queue and have that queue synchronized and service the queue on the main thread to call accept_transaction.
Agree with @brianjohnson5972 , this is more likely to be threading issue. Try to do it on the main thread. If you have further question, please ask in https://eosio.stackexchange.com/
Thank you for your help and information provided
Hello,
I developed an EOS plugin, which acts as a tcp server that receives client requests, processes them, persists them in the blockchain by calling smart contracts which i created, and sends a response to the client. The plugin is started alongside nodeos with the --plugin option. The plugin then creates a thread (inside plugin_startup) which works as a tcp server waiting for clients to connect to a specified port and send their data. I tried by creating two versions of the plugin, in one version i created separate thread for every client request (concurrent writing into the blockchain from multiple threads), and in the other version 1 thread has been used for processing every connection(meaning sequential write into the blockchain from a single thread)
As part of my plugin, I use the following methods which i created by digging into the eos code, samples and tests to persist the data into the blockchain:
and second version: (as seen in txn_test_gen_plugin)
Then i set the action with trx.actions.emplace_back(...)
I sign the transaction with this method:
And finally i execute the transaction with this method:
I have also created a separate client application which sends a request to the plugin (server) and receives a response that the data has been saved in the blockchain. When i invoke the client in a for loop with (usually) more then 2000 iterations, after some short period of time in most of the cases i get one of the following errors:
In all of the cases above i can only restart nodeos by adding --delete-all-blocks (--hard-replay doesn't work).
I have the aforementioned problems in both plugin versions (the single threaded as well as the multithreaded). If i comment only the
cp.accept_transaction(...)
call in theexecute_transaction(chain::signed_transaction& trx)
method above, i have no problems at all, i can invoke the client in a for loop with even 10,000 iterations multiple times and the plugin works just fine (well except that it doesn't execute the prepared transaction).Also, i created a separate test application which calls my smart contract directly with 'push transaction...'. (the same smart contract which i am calling by trying to execute the transaction from the plugin) The test application can call the push transaction commands in a for loop with thousands of iterations (i have tried up to 10000) in 2 ways also, (one is singlethreaded, and the other is multithreaded), both ways work as expected without any exceptions or segfaults, so the only way i am getting the segfaults or the aforementioned exceptions is by calling accept_transaction from my plugin.
I am synchronized with the following git commit: 59626f1e6361df3b715e926ee13a9a8e84d177af and i use single node testnet.
Since i couldn't find any tutorial on eos plugin development, I would like to know if this is some known bug, or i am missing something at my side, maybe using the wrong api, or using it inappropriately?
Thank you.
p.s. I forgot to add one significant error that also appears often at the segfault: from the coredump file analyzed with lldb:
from the lldb terminal with attached nodeos process id: