I want to use dynamic and central configuration strategy for my microservices (MS) (multiple instances of same type having same configuration) and I'm using Azure App Configuration (AAC). I want to minimize calls to AAC so when one MS is starting I would like to read configuration from AAC and keep that until changes made i.e I dont want for every call to Configuration["Env:service:some-param"] generate calls to AAC. The notification part I have solved via eventgrid and servicebus-events so all MSs reaches notification that changes have been made but I really cant find any good solution to force to reload Configuration from AAC on demand.
In Program.cs I hook up AAC via:
config.AddAzureAppConfiguration(options =>
options
.Connect(connection)
.ConfigureRefresh(refresh =>
{
refresh.Register(environment + ":" + service + ":<Some-param>",true)
.SetCacheExpiration(TimeSpan.FromDays(1));
_environmentRefresher = options.GetRefresher();
})
why I set SetCacheExpiration(TimeSpan.FromDays(1)) is because I dont want to make unnecessary calls to AAC and I thought that if I fetch the refresher and triggers it when event occurs configuration would be reloaded but thats seems not to be the case due to SetCacheExpiration seems to override everything so my question is ... Is given scenario not solvable in .net core or can I achieve this in some way?
Make sure to call IConfigurationRefresher.SetDirty if you want to force the cache expiration to occur using an event based refresh model. Otherwise you'll encounter the problem you mention where the cache hasn't been invalidated yet and the refresh call will be a no-op.
Related
In our Firebase application there is a list with lots of items in Realtime Database. Every create, update and delete operation on single item is processed by Firebase Cloud Function with onWrite trigger (in simplest case this function just counts items). But sometimes there is a need for bulk operation on items without need for individual processing. Let's say we want in single transaction remove all items and reset counters.
Earlier it worked just fine. Due to the limit of 1000 for number of Cloud Functions triggered by a single write (https://firebase.google.com/docs/database/usage/limits), no functions where triggered at all and it was desired outcome.
Now, without any change to application code we have an error
Error: TOO_MANY_TRIGGERS: This request would cause too many functions to be triggered.
Same error appears in client application, Admin API and even when importing json using the web interface. Only option that works for us is processing of items in batches. But it is not transactional and takes up to tens of minutes instead of milliseconds as before.
What options do we have to bypass this error? Optimally this would be some switch to skip function triggering in case of exceeding the limit.
For anybody reading this question post-2018, there is now an option to disable strict enforcement for trigger limits.
Strict validation is enabled by default for write operations that trigger events. Any write operations that trigger more than 1000 Cloud Functions or a single event greater than 1 MB in size will fail and return an error reporting the limit that was hit. This might mean that some Cloud Functions aren't triggered at all if they fail the pre-validation.
If you're performing a larger write operation (for example, deleting your entire database), you might want to disable this validation, as the errors themselves might block the operation.
To turn off strictTriggerValidation, follow these steps:
Get your Database secret from the Service accounts tab of your Project settings in the Firebase console.
Run the following CURL request from your command line:
curl -X PUT -d "false" https://NAMESPACE.firebaseio.com/.settings/strictTriggerValidation/.json?auth\=SECRET
See here for the docs: https://firebase.google.com/docs/database/usage/limits
There is currently no way to prevent triggers from running in special circumstances. The only way around this is to undeploy all your triggers, perform your updates, then deploy all your triggers again.
I would encourage you to file a feature request for this.
I just got this error message in an older, Flutter project that I hadn't touched in quite some time.
[firebase_database/unknown] TOO_MANY_TRIGGERS: This request would cause too many functions to be
triggered.
It turned out that here it was caused by the fact that my Cloud Functions were still set to use Node v8, which was retired in early 2021.
Upgrading the Cloud Functions to use Node v12 (no other changes needed) removed the error message for me.
Turning off strictTriggerValidation is solved my issue.
if you are using firebase tool you can follow these steps.
Turn off strictTriggerValidation for entire project:
MAC
sudo firebase database:settings:set strictTriggerValidation false --project *my_project_id*
If you need to turn off for particular instance:
MAC
sudo firebase database:settings:set strictTriggerValidation false --project *my_project_id* --instance *my_instance_name*
check instances
sudo firebase database:instances:list --project *my_project_id*
Note: windows user please try without sudo
FYR:
Limitations: https://firebase.google.com/docs/database/usage/limits
Firebase CLI Commands: https://firebaseopensource.com/projects/firebase/firebase-tools/
Even with debug enabled for RemoteConfig, I still managed to get the following:
Error fetching remote config values Optional(Error Domain=com.google.remoteconfig.ErrorDomain Code=8002 "(null)"
UserInfo={error_throttled_end_time_seconds=1483110267.054194})
Here is my debug code:
let debug = FIRRemoteConfigSettings(developerModeEnabled: true)
FIRRemoteConfig.remoteConfig().configSettings = debug!
Shouldn't the above prevent throttling?
How long will the throttle error remain in effect?
I've experienced the same error due to throttling. I was calling FIRRemoteConfig.remoteConfig().fetchWithExpirationDuration with an expiry that was less than 60 seconds.
To immediately get around this issue during testing, use an alternative device. The throttling occurs against a particular device. e.g. move from your simulator to a device.
The intention is not to have a single client flooding the server with fetch requests every second. Make sensible use of the caching it offers out of the box and fetch only when necessary.
When you receive this error, plug the value of error_throttled_end_time_seconds into an epoch converter (like this one at https://www.epochconverter.com) and it will tell you the time when throttling ends. I've tested this myself, and the throttling remains in effect for 1 hour from the first moment you are throttled. So either wait an hour or try some of the other recommendations given here.
UPDATE: Also, if you continue making config requests and receive the throttle error, the expire timeout does not increase (i.e. "you are not further penalized").
The quick and easy hack to get your app running is to delete the application and reinstall it. Firebase identifies your device as new device on reinstalling.
Hope it helps and save your time.
Since the Drive SDK v3 we are able to receive push notifications from Google Drive whenever a file has changed. At the moment I'm working on a Drive application in Python and I would like to receive such notifications. Do I really need a web server for this or can I implement this maybe with a socket or something like this?
I know that I can get changes by polling the changes.list method but I want to avoid this because of so many API calls. Is there maybe a better way to get informed if a file has changed?
EDIT: I captured my web traffic and saw, that the original Google Drive Client for Windows uses push notifications. So in some way it must be possible to get push notifications in a desktop application but is this maybe some sort of Google magic which we can't use with the current API
For Google Drive apps that need to keep track of changes to files, the Changes collection provides an efficient way to detect changes to all files, including those that have been shared with a user. The collection works by providing the current state of each file, if and only if the file has changed since a given point in time.
Retrieving changes requires a pageToken to indicate a point in time to fetch changes from.
# Begin with our last saved start token for this user or the
# current token from getStartPageToken()
page_token = saved_start_page_token;
while page_token is not None:
response = drive_service.changes().list(pageToken=page_token,
fields='*',
spaces='drive').execute()
for change in response.get('changes'):
# Process change
print 'Change found for file: %s' % change.get('fileId')
if 'newStartPageToken' in response:
# Last page, save this token for the next polling interval
saved_start_page_token = response.get('newStartPageToken')
page_token = response.get('nextPageToken')
I have a Meteor app that is based on the Meteor simple todos tutorial. I noticed, that the second node-process (smaller one) on the server, started later when the app is started up, increases its memory usage steadily, even when there is no activity at all but at least one client is logged on to the server. I trace the RSS-Memory value with
pmap -x $PID_node | tail -1 | awk '{ print $4 }'
but it is also visible with 'top'. The RSS number is increasing steadily when doing nothing at all on the client side. I added the app here for reproducing the behavior.
When I remember correctly it is the original state as I finished the tutorial without doing any custom changes.
When the client is disconnected the memory still remains and is not reduced by any means.This goes on until the app is closed on the server when reaching the memory limit. I encounter similar behavior with the official todos-example. I start the apps with
meteor --port 61100
I found in other posts that this could be related to a public folder which I even do not have in the simple todos so there must be something different. I also updated to the latest version of meteor 1.3.4.1 which does not change the behavior.
Is this a normal meteor behavior or has to be considered a meteor bug? Or is there any bad style code in the examples?
I currently have over 1k realtime users setup on a MySQL server(only 10-20 users will register simulatneously) for Asterisk. The problem is the sip is not registering evertime. Sometimes I get 'registration timeout'. Is there a setup guide or a setting which I need to configure in order to have >99% successful registrations?
Never faced the issue as I have fewer users.
But according to the aterisk documentation:
If you have problems with your network connection going up and down (e.g. an unreliable cable connection) and you keep losing your sip registry, you may want to add registerattempts and registertimeout settings to the general section above the register definitions.
Setting registerattempts=0 will force Asterisk to attempt to reregister until it can (the default is 10 tries).
registertimeout sets the length of time in seconds between registration attempts (the default is 20 seconds).
About achieving 99% success:
I think you have to study your system and apply setting to the above variables accordingly (dynamically). I suggest using Markovian models like mm1 simulation if your system is not complicated.