-
Notifications
You must be signed in to change notification settings - Fork 617
Implemented exponential backoff and max retry with resumable uploads #4087
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
dd3fba3
08c5714
16cffe8
10308ff
7a9356c
a47f2dc
d24c56d
11f5f54
fdb61c9
ad8203e
6acea85
ea6d56a
c6ac2f1
1384235
0bf2349
047a780
da6b659
1304294
7f8772b
91c5403
ce95d65
277b03e
fc9c9ac
d37c628
7787770
254d8cc
1085b00
97520ea
91a72a5
d6da159
9ca073b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -32,6 +32,12 @@ | |||
public class TestUtil { | ||||
|
||||
static FirebaseApp createApp() { | ||||
/** | ||||
* Many tests require you to call the callback on the same thread that was initially | ||||
* instantiated. With the 5 second keepalive, after 5 seconds, the thread will get killed and | ||||
* eventually a new one will be created. Therefore causing many of the tests to fail. | ||||
*/ | ||||
StorageTaskScheduler.setCallbackQueueKeepAlive(90, TimeUnit.SECONDS); | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To add additional context: We call Line 63 in ed10eb5
However, in cases where we have long backoffs, this won't be the case, as the thread pool will terminate any threads that are not executed within the keepalive time, which is 5 seconds. Our alternative is to set the keepAlive, or disable the threads from being killed. A third option would be to remove this verification check. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we know why this check is necessary? I'm not familiar with the tradeoffs of keeping threads around for an extended period of time. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think in case the wrong executor gets called by Here's a quick StackOverflow answer that talks about the tradeoffs: |
||||
return FirebaseApp.initializeApp( | ||||
ApplicationProvider.getApplicationContext(), | ||||
new FirebaseOptions.Builder() | ||||
|
@@ -144,10 +150,10 @@ static void await(Task<?> task, int timeout, TimeUnit timeUnit) throws Interrupt | |||
} | ||||
|
||||
/** | ||||
* Awaits for a Task for 3 seconds, but flushes the Robolectric scheduler to allow newly added | ||||
* Awaits for a Task for 10 seconds, but flushes the Robolectric scheduler to allow newly added | ||||
* Tasks to be executed. | ||||
*/ | ||||
static void await(Task<?> task) throws InterruptedException { | ||||
await(task, 3, TimeUnit.SECONDS); | ||||
await(task, 10, TimeUnit.SECONDS); | ||||
maneesht marked this conversation as resolved.
Show resolved
Hide resolved
|
||||
} | ||||
} |
Uh oh!
There was an error while loading. Please reload this page.