Author: Olivier Langlois 2013-10-02 03:20:53
Published on: 2013-10-02T03:20:53+00:00
In this context, Jeff Garzik and Olivier discuss the network activity during a test and the duration of locks being held. Garzik asks whether bitcoind was processing a block or sending a large transaction during the call with 5.99 locktime and suggests that there are valid reasons for locks being held for long periods during random network events. Olivier responds that not much information is available, but it appears that CTxMemPool::accept() was called while the rpc thread was between jreq.parse() and tableRPC.execute(). The logs surrounding the 5.99 sec lock wait show that CTxMemPool::accept() accepted multiple transactions, including cf34b31f26d3275b66adf081f84fca2d761e8e260b42243ba36638368c1633b1 and da6c8145c9f506ec0f146b37d57ef423098b584af8dbed9490002ed900228c27. Additionally, ThreadRPCServer method=getinfo was called at 1380610633.387730. The locktime was 5.996820, calltime was 0.000328, and totaltime was 5.997148.
Updated on: 2023-06-07T17:10:09.489474+00:00