One of the possibilities ELOxc EWS presents to the administrator is that it allows each instance to run any number of processing threads on the Exchange server. In principle, with a sufficiently powerful server, you could run any number of parallel threads to maximize processing speed.

However, load tests have shown in practice that multi-threaded operation should be treated with caution.

Above a certain speed, requests sent by ELOxc EWS and the Indexserver cause the Exchange server to raise ServerBusyExceptions and ServiceRepsonseExceptions.

When these exceptions occur, Exchange cancels processing all parallel threads immediately. ELOxc will then return to an idle state and wait for the next job trigger.

These exceptions also provide a BackOff-Suggestion parameter, usually with a value of five minutes. Within this time window, it is not possible for ELOxc to perform operations on the Exchange server.

The only way to avoid these errors is to limit the number of threads. It is not possible to give a general guideline on the upper limit for this option, because it is dependent on a number of factors. However, three or less threads has not yet resulted in this type of error in testing.

Five parallel processing threads presents a moderate threat of this error type, and ten threads almost always results in errors.

ELOxc EWS throttling policies also play an important role in this relationship, and administrators can also adjust them to improve system stability and to improve system performance. However, since this measurement has a wien-ranging impact on the behavior of the Exchange server, ELO denies any responsibility for issues arising from adjustments made in this regard.

Check the worker logs to see if these errors have occurred in your enviornment.