You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are currently adding split.io to one of our backend services, but we don't have the API key yet, so we added a dummy value.
Upon startup of the container, we observed a huge amount of error logs like this:
RefreshableSplitFetcher failed: Problem fetching splitChanges: Could not retrieve splitChanges; http return code 400
This log message is repeated every second (causing quota issues with our logging solution).
We assume that the problematic place in the code is in SyncManagerImp.start(), where upon receiving any exception, there is only a sleep of 1000ms and then a retry is performed.
The expected behavior would be to have some kind of exponential backoff in place, so that ever if Split.io is down or returns an error, our services can start up without producing tons of error logs.
Thx for having a look!
The text was updated successfully, but these errors were encountered:
Hi @tom-mi let me consult this with our engineering team and I'll get back to you as soon as possible.
In the meantime, may I suggest you use "localhost" as your dummy key? This will cause the SDK to initialize in the locahost mode (see: https://help.split.io/hc/en-us/articles/360020405151-Java-SDK#localhost-mode), where it will not attempt to connect to Split and will not log any of those error messages.
Hi @tom-mi,
we fixed another issue that it's related to this one in the Java SDK version 4.4.6. Can you try the new version? please.
I'll be waiting for a response if you still have the same problem.
Hi @nmayorsplit ,
thanks for the update. The situation has improved, as now the log message is only printed every 10 seconds instead of every second. I'd prefer an even longer max wait time, especially as in our case the error was a client error which will never recover by itself.
However, for our purposes the current value of 10s would probably already be sufficently high to prevent hitting our log quotas.
We are currently adding split.io to one of our backend services, but we don't have the API key yet, so we added a dummy value.
Upon startup of the container, we observed a huge amount of error logs like this:
This log message is repeated every second (causing quota issues with our logging solution).
We assume that the problematic place in the code is in
SyncManagerImp.start()
, where upon receiving any exception, there is only a sleep of 1000ms and then a retry is performed.The expected behavior would be to have some kind of exponential backoff in place, so that ever if Split.io is down or returns an error, our services can start up without producing tons of error logs.
Thx for having a look!
The text was updated successfully, but these errors were encountered: