forked from Qortal/qortal
918a331609
This is a serious change as it affects many callers. Controller.onNetworkTransactionMessager() -- should be OK to block as it's only one EPC thread TransactionsResource.processTransaction() -- should be OK to block as it's only one Jetty thread AND has its own 30s timeout wrapper anyway Implementations of AcctTradeBot.progress() e.g. BitcoinACCTv1TradeBot.progress() & LitecoinACCTv1TradeBot.progress() TradeBot.updatePresence() -- these are called via BlockMinter/Synchronizer when blockchain lock is already held, so will are unaffected AcctTradeBot.createTrade() and AcctTradeBot.startResponse() -- these are called via API and previously would only perform non-blocking blockchainLock.try() but now perform blocking blockchainLock.lock() thus preventing NO_BLOCKCHAIN_LOCK when creating/responding to trades especially after a (wasted) MESSAGE PoW compute but with potential downside that API response might be delayed e.g. by a very slow sync round Future work could look into removing the need for blockchain lock when calling Transaction.importAsUnconfirmed().