Rohan McGovern

Retry on server problems as much as possible

1

Currently we only robustly do the initial TCP connect. In theory we can also safely redo the whole request up to the point where we start writing the pack file...

Currently there is some very basic logging, only to stdout/stderr. The logging should be significantly improved. There should be a possibility of having parseable access logs to determine access patterns,...

Currently the proxy uses "git rev-list --no-walk " to determine whether or not the cache contains a given SHA1. This seems very inefficient, since it requires one process to be...

The current implementation for the proxy to write HAVE to the server uses the most basic available protocol. It should be updated to make use of multi_ack and/or multi_ack_detailed. The...

Currently the proxy simply hardcodes certain capabilities. It should have, at the very least, the ability to give a sensible fatal error when the client or server doesn't have the...

I note that futures are not slots-using classes. When analyzing memory usage of a program using a lot of futures, I see many dicts apparently linked to the futures created...

Add special-case handling to flatten the data structure when chaining multiple AND/OR together; for example, make f_and(f_and(x, y), z) work approximately in the same way as f_and(x, y, z). The...

Collapse f_and/f_or for better performance?

2

Consider the following: ```python f = f_and(f1, f2) f = f_and(f, something) f = f_and(f, other) f = f_and(f, foo) f = f_and(f, bar) # ... ``` That will create...

It is currently possible to induce a stack overflow in some cases of chained futures, e.g. a chain of `f_and` some thousands deep. In such cases, an exception will be...

RetryPolicy - deadline?

1

Consider adding a 'deadline' argument to ExceptionRetryPolicy. The current parameters center around the number of retries and the delay per retry, but that makes it a bit tough to figure...