Closed bgrambichlerpixelart closed 2 years ago
It has been introduced in the 8.0.0
Cool, thats excactly what i need! I worked with Release 8.0.0-beta.3 and i didn't see that before. The piece of code is new, isn't it? Thanks a lot
Yes it's new and shiny.
Also still not yet completely happy with it and still thinking about a possibility to get it working in a middleware. But as a matter of fact atm middlewares are running on the HTTP abstraction layer and don't know about the API abstraction layer which makes it harder to change the request itself.
I added now a new Middleware which is able to update the body with the new version number and uses failsafe for backoff and multiple retries.
Just released the 8.1.0 which adds the ConcurrentModificationMiddleware.
@jenschude Our ERROR logs are getting filled with 409 errors i.e.
ERROR POST https://api.australia-southeast1.gcp.commercetools.com/xyz-abc/payments/fbbb8a22-2f19-4108-aa0e-b09b25cc98a4 409
.
Since, we are handling this with a retry, can you suggest any way to make it a INFO
type log ?
I would configure this specific logger to only log higher error levels
Ah this may be not working as it comes from the LoggerMiddleware which by default logs all ApiHttpExceptions as errors.
I may introduce a new configuration for this as like as the response and deprecation log event to configure the level for specific exceptions
Please see 5f6df55
I added a configuration option for the InternalLogger to be able to globally configure the log level for exceptions and also on a per class level. Will be available with the next release
Thanks @jenschude
I would very helpful if you can add a example to configure InternalLogger
to disable 409 logs.
I downgraded the log from error to info for ConcurrentModificationExceptions by default and also fixed an issue with the exception level map
Hi @jenschude I am still seeing 409 ERROR logs in SDK 8.7 version. Do I need to change anything ?
Thanks
By default ConcurrentModification is LogLevel INFO. I added a small test to show how to configure the specific loglevels with the ApiRootBuilder
I found the culprit. When the import java.util.*
was added to the InternalLoggerMiddleware the exceptionLevelMap was initialized with java.util.ConcurrentModificationException
instead of the SDK one. Will add an additional test for it and release a patch version.
Just released the version 8.7.1 which fixes the issue
I need to implement a retry handling with an updated version if i get a "ConcurrentModification" - Exception.
In SDK v1 we did that with RetrySphereClientDecorate and RetryRule classes.
In SDK v2 i tried to implement this usecase with RetryMiddleware class but i found no way to delegate the ProjectApiRoot Client to set a new Request with the manipulated HttpRequest.
One way could be, to surround every API-Request where we faceing the ConcurrentModification Problem with a while-Loop and try-catch handling to send API-request several times with updated order-version?!?