Event batching queue #16

New Issue

2022-12-27T18:53:46+03:00

gozzy commented

2022-12-27 18:53:46 +03:00

(Migrated from development.tornadocash.community)

After undertaking efforts to implement asyncronous RPC event fetching for withdrawal and deposit events, it is still proving to be a tedious process over median latency connections.

Currently, events are being fetched in parallel batches of 10 and with a minimum and maximum retry buffer of 2 to 10 seconds, over 5 attempts. If the request in a batch fails, request parameters are stored for a final reattempt (includes retry buffering and batch seperation) after the initial batches are fulfilled.

The goal here is once an request is marked as successful or failed, subsitute it with the next pending. In contrast to the current implementation requiring all 10 requests to resolve before continuing to the next batch, thus acting as a queue or stream of requests.

After undertaking efforts to implement asyncronous RPC event fetching for withdrawal and deposit events, it is still proving to be a tedious process over median latency connections. Currently, events are being fetched in parallel batches of 10 and with a minimum and maximum retry buffer of 2 to 10 seconds, over 5 attempts. If the request in a batch fails, request parameters are stored for a final reattempt (includes retry buffering and batch seperation) after the initial batches are fulfilled. The goal here is once an request is marked as successful or failed, subsitute it with the next pending. In contrast to the current implementation requiring all 10 requests to resolve before continuing to the next batch, thus acting as a queue or stream of requests.

Sign in to join this conversation.