Jds mempool enhancement 3#16
Conversation
As suggested in stratum-mining#772 (comment) A task that before was blocking now is moved as a separate task on main
As suggested in stratum-mining#772 (comment) This commit introduces a verification that all the transactions in a job are correctly recognized when a submit block message appears.
| // retrieved from the jd client | ||
| for txid in txids { | ||
| let transaction = client | ||
| .get_raw_transaction(&txid.to_string(), None) |
There was a problem hiding this comment.
before fetching txs you should check if they are already in the mempool
There was a problem hiding this comment.
another option could be to use an HashSet right after the receiver
There was a problem hiding this comment.
I am struggling to figure out a useful case for HashSet. If you propose to use it instead HashMap, then you cant store transactions only by their IDs. What do you mean with "right after the receiver"? Can you be a bit more specific? ^^
BTW already fixed in this commit
Error management when some transactions are missing. The jds should not break. Instead, tries to recover it by triggering the jds mempool to retrieve the transactions from its bitcoin node
lorbax
force-pushed
the
jds-mempool-enhancement-3
branch
from
1833c24 to
2d564a1
Compare
In the message handler the message the triggers the JDS mempool to fill the transactions is implemented in a bad way. Now it is fixed Add some documentation
apply Fi3 suggestion GitGab19#16 (comment)
| // the trasnactions sent to the mempool can be freed | ||
| let _ = self_mutex.safe_lock(|a| { | ||
| a.add_txs_to_mempool.add_txs_to_mempool_inner = AddTrasactionsToMempoolInner { | ||
| known_transactions: vec![], |
There was a problem hiding this comment.
better to use clear, no need to deallocate if we are going to fill it again
| } | ||
| JobDeclaration::SubmitSolution(_) => todo!(), | ||
| } | ||
| Self::send(self_mutex.clone(), m).await.unwrap(); |
There was a problem hiding this comment.
this always send the message also for the error cases
There was a problem hiding this comment.
if we get one of the error cases above something really strange is happening better to close the connection. Downstream will decide what to do
| Ok(transactions_list) | ||
| } | ||
|
|
||
| async fn send_txs_to_mempool(self_mutex: Arc<Mutex<Self>>) { |
There was a problem hiding this comment.
I think that you can use an &Arc<Mutex> here
| Ok(hex::encode(serialize(&block))) | ||
| } | ||
|
|
||
| fn are_all_job_transactions_present( |
There was a problem hiding this comment.
change the function name i something else, this seems just a condition check but it do collect txs.
you can use colletc_txs_for_job
| .unwrap(); | ||
| let sender_add_txs_to_mempool = add_txs_to_mempool.sender_add_txs_to_mempool; | ||
| let add_txs_to_mempool_inner = add_txs_to_mempool.add_txs_to_mempool_inner; | ||
| let _ = sender_add_txs_to_mempool |
| .send(add_txs_to_mempool_inner) | ||
| .await; | ||
| // the trasnactions sent to the mempool can be freed | ||
| let _ = self_mutex.safe_lock(|a| { |
| .clone() | ||
| .safe_lock(|a| a.mempool.clone()) | ||
| .unwrap(); | ||
| tokio::select! { |
There was a problem hiding this comment.
seems that you want to use a tokio::timeout here
| sender.clone(), | ||
| &config, | ||
| mempool.clone(), | ||
| // each downstream has its own sender (multi producer single consumer) |
There was a problem hiding this comment.
remove this comment you see it from the type
apply Fi3 suggestion #16 (comment)
apply Fi3 suggestion #16 (comment)
apply Fi3 suggestion GitGab19#16 (comment)
3 participants
apply part of the suggestions to this PR
stratum-mining#772