It is an important responsibility of the user of the library to instantiate a sphereClient
that does the following:
-
Limits the number of concurrent requests done to CTP. This can be done by decorating the
sphereClient
with QueueSphereClientDecorator -
Retries on 5xx errors with a retry strategy. This can be achieved by decorating the
sphereClient
with the RetrySphereClientDecorator
If you have no special requirements on the sphere client creation, then you can use the ClientConfigurationUtils#createClient
util which applies the best practices for SphereClient
creation.
The sync library is not meant to be executed in a parallel fashion. For example:
final ProductSync productSync = new ProductSync(syncOptions);
final CompletableFuture<ProductSyncStatistics> syncFuture1 = productSync.sync(batch1).toCompletableFuture();
final CompletableFuture<ProductSyncStatistics> syncFuture2 = productSync.sync(batch2).toCompletableFuture();
CompletableFuture.allOf(syncFuture1, syncFuture2).join;
The aforementioned example demonstrates how the library should NOT be used. The library, however, should be instead used in a sequential fashion:
final ProductSync productSync = new ProductSync(syncOptions);
productSync.sync(batch1)
.thenCompose(result -> productSync.sync(batch2))
.toCompletableFuture()
.join();
By design, scaling the sync process should not be done by executing the batches themselves in parallel. However, it can be done either by:
- Changing the number of max parallel requests within the
sphereClient
configuration. It defines how many requests the client can execute in parallel. - or changing the draft batch size. It defines how many drafts can one batch contain.
The current overridable default configuration of the sphereClient
is the recommended good balance for stability and performance for the sync process.
In order to exploit the number of max parallel requests
, the batch size
should have a value set which is equal or higher.