Using Transaction Receipt Processors with Web3j

Transaction Receipt Processors

When interacting with smart contracts or for simple account to account transactions, after a transaction is sent to the geth node to initiate the tranction , the default behaviour from web3j is to start waiting for the transaction receipt for this new transaction, when you use the default transaction manager provvided by web3j.

Here is an example , with the default behaviour

Web3j web3j = Web3j.build(new HttpService(envConfiguration.getEthereumServerUrl()));
BigInteger gasLimit = BigInteger.valueOf(90000);
BigInteger gasPrice = web3j.ethGasPrice().send().getGasPrice();
BelriumToken token = BelriumToken.load(contractAddress, web3j,credentials,gasPrice, gasLimit);
TransactionReceipt receipt = token.transfer(toAddress, amount).send();
if (Optional.ofNullable(receipt).isPresent()) {
logger.info("transfer BET via api txn mined " + receipt.getTransactionHash());}

Here when calling the load function for the smart contract we need to interact with, we are not passing a Transaction Manager instance and hence the default transaction manager is used by web3j.

The default transaction manager is an instance of the Raw Transaction Manager , with no Transaction Receipt processor specified. Hence you end up with a default Raw Transaction Manager with the default transaction receipt processor - which is the PollingTransactionReceiptProcessor, with the default polling time for the transaction you submitted as 15 seconds and the number of polling attempts as 40 i.e. a total of 10 minutes and until this time you have no details related to transaction available to you.

To overcome this, there are two other TransactionReceiptProcessor variants available in WEb3j namely -

1) QueuingTransactionReceiptProcessor - What this does is, add all the transactions submitted to the network in a queue maintained by itself and polls all the transactions in this queue specified in the instance constructor. 
So for example if you submit two transactions at an interval of 60 seconds , with the help of this instance (and polling time of 60 seconds and polling frequency of 10), the receipt processor will wait a maximum of 660 seconds before providing you the status of transaction if it gets mined, or will end up in TransactionException.

There are two advantages of this methods
a) It provides you the transaction hash of the transaction submitted immediately via a EmptyTransactionReceipt object, so that you can store the transaction details immediately.
b) It provides a callback functionality, with the success and failure methods that you can override according to your code.
c) You can also use this to wait for transaction receipt a little longer than the default receipt processor. 

2) NoOpProcessor - You use this method , when you just want the transaction hash for the transaction you just submitted , instead of waiting for any processing done by the web3j itself.

Here is how you alter the default receipt processor 

TransactionManager rtm =  new RawTransactionManager(web3j,credentials,ChainId.NONE,transactionReceiptProcessor);
BelriumToken token = BelriumToken.load(envConfiguration.getBelriumContractAddress(), web3j,rtm,gasPrice, gasLimit);
TransactionReceipt emptyTxReceipt = token.transfer(orgWalletAddress,amount.toBigInteger()).send();