Before we implement this ticket, however, we should create a performance test to see what impact doing balance updates in a separate thread has under load. This is because I think the spirit of this ticket is just that we should return the fulfill/reject regardless of what happens to our balance update. Generally, if the balancetracker is just down, the except will be caught and the packet returned regardless. So, the real value in implementing this ticket would be latency improvements in packet responses and making sure we respond with a packet in a timely manner even if the balance tracker is latent or hangs.
Replicate the quick return logic found in the Rust implementation: https://github.com/emschwartz/interledger-rs/issues/92
The specific code in Rust is here (https://github.com/interledger-rs/interledger-rs/pull/90/files#diff-d8b400d83a08276fe9aa7835652c6a4dR114). To pull this off in Java, we would want to execute the BalanceTracker update in a separate thread.
Before we implement this ticket, however, we should create a performance test to see what impact doing balance updates in a separate thread has under load. This is because I think the spirit of this ticket is just that we should return the fulfill/reject regardless of what happens to our balance update. Generally, if the balancetracker is just down, the except will be caught and the packet returned regardless. So, the real value in implementing this ticket would be latency improvements in packet responses and making sure we respond with a packet in a timely manner even if the balance tracker is latent or hangs.