On the mailbox connector, we expose two main settings for treating item failures: 1) item retries and 2) maximum item failures.
Item Retries
Item retries specifies how many times to retry and item if we encounter a failure. Each retry is performed in an exponential back-off fashion. If you don’t know what this means, here is a chart that will tell you:
| Retry Count |
Time Before Retry |
Total Time Lost |
| 1 |
0:01 |
0:01 |
| 2 |
0:04 |
0:05 |
| 3 |
0:09 |
0:14 |
| 4 |
0:16 |
0:30 |
| 5 |
0:25 |
0:55 |
| 6 |
0:36 |
1:31 |
| 7 |
0:49 |
2:20 |
| 8 |
1:04 |
3:24 |
| 9 |
1:21 |
4:45 |
| 10 |
1:40 |
6:25 |
As you can see, having large amounts of errors can significantly delay your migrations. Errors may or may not be in your controls. Some errors examples that are not in your control:
- Network errors outside of your data center
- Corrupt items
Some example errors that are in your control:
- Firewall rate limiting
- Server patches
- Hardware upgrades
- Data center network upgrades
Note that these retries are per mailbox. Meaning that if a mailbox is currently in a retry state, it doesn’t affect other mailboxes that are being migrated simultaneously. The default value is 3. In most migrations, you don’t have to change this setting.
Maximum Item Failure
The maximum item failure specifies how many items need to fail before we constitute the migration as a failure. If this many number of errors is hit, the mailbox migration will immediately stop and be considered a failure. The default value is 100.
If we hit 100 errors with the default retry of 3, the mailbox has been in idle for 20 hours and 3 minutes before we fail the mailbox. This gives you an idea of the impact when you change these values from the default values we recommend.
Like this:
Be the first to like this post.
Discussion
No comments yet.