When I try to purge cache for multiple files on Cloudflare I often get error response:
{"request":{"act":"zone_file_purge"},"result":"error","msg":"File purge rate limited."}
What can I do to not get this error?
I noticed that there was 50 purge URLs/minute limit.
I also found that this limit is only there for old API calls (which I used) - URL:
https://www.cloudflare.com/api_json.html
Upgrading to https://api.cloudflare.com/client/v4/ fixed the issue.
Related
While performing management api operations such as removing app servers from a MarkLogic cluster, it becomes unstable resetting hosts.xml to default/localhost setting.
Logs shows something like:
MarkLogic: Slow send xx.xx.34.113:57692-xx.xx.34.170:7999, 4.605 KB in 1.529 sec; check host xxxx
Consider infrastructure is slow or not slow, but automatic recovery is still not happening.
How to overcome this situation?
Anyone who can provide more info on how management api is working under the hood?
Adding further details:
DELETE http://${BootstrapHost}:8002${serveruri}
POST http://${BootstrapHost}:8002${forest}?state=detach
DELETE http://${BootstrapHost}:8002${forest}?replicas=delete&level=full
DELETE http://${BootstrapHost}:8001/admin/v1/host-config?remote-host=${hostname}
When removing servers 1st request or removing host 4th request, few nodes in the cluster restarts and we check for nodes availability. However this is uncertain and sometimes hosts.xml resets to a default xml which says it is not part of any cluster.
How we fix, we copy hosts.xml from another host to this faulty host and it starts working again.
We found that it was very less likely to come in MarkLogic 8, but with MarkLogic 9 this problem is frequent and if it is on AWS it is even more frequent.
I am getting an intermittent HTTP error when I try to load the contents of files in Azure Databricks from ADLS Gen2. The storage account has been mounted using a service principal associated with Databricks and has been given Storage Blob Data Contributor access through RBAC on the data lake storage account. A sample statement to load is
df = spark.read.format("orc").load("dbfs:/mnt/{storageaccount}/{filesystem}/{filename}")
The error message I get is:
Py4JJavaError: An error occurred while calling o214.load. : java.io.IOException: GET https://{storageaccount}.dfs.core.windows.net/{filesystem}/{filename}?timeout=90``` StatusCode=412 StatusDescription=The condition specified using HTTP conditional header(s) is not met.
ErrorCode=ConditionNotMet ErrorMessage=The condition specified using HTTP conditional header(s) is not met.
RequestId:51fbfff7-d01f-002b-49aa-4c89d5000000
Time:2019-08-06T22:55:14.5585584Z
This error is not with all the files in the filesystem. I can load most of the files. The error is just with some of the files. Not sure what the issue is here.
This has been resolved now. The underlying issue was due to a change at Microsoft end. This is the RCA I got from Microsoft Support:
There was a storage configuration that is turned on incorrectly during the latest storage tenant upgrade. This type of error would only show up for the namespace enabled account on the latest upgraded tenant. The mitigation for this issue is to turn off the configuration on the specific tenant, and we had kicked off the super sonic configuration rollout for the all the tenants. We have since added additional Storage upgrade validation for ADLS Gen 2 to help cover this type of scenario.
I had the same problem on one file today. Downloading the file, deleting it from storage and putting it back solved the problem.
Tried to rename file -> didn't work.
Edit: we have it on more files, random.
We worked around the problem by copying the entire folder to a new folder and rename it to original. Jobs run without problems again.
Still the question remains, why did the files end up in this situation?
Same issue here. After some research, it seems it was probably an If-Match eTag condition failure in the http GET request. Microsoft talk about how they will return error 412 when this happens in this post: https://azure.microsoft.com/de-de/blog/managing-concurrency-in-microsoft-azure-storage-2/
Regardless, Databricks seem to have resolved the issue on their end now.
I have a problem with our subversion server. Doing small commits works fine, but as soon as someone tried to commit a large collection sizeable files the commit stalls halfway through and the client finally time out. My test set consists of roughly 2000 files and the total size of the commit is about 1 GB. When I commit the files the file uploading starts but about halfway through the transfer rate drops to 0kb/s and the commit just stalls and never recovers. If I splitting the commit into smaller pieces (<150 Mb) everything works just fine, but that breaks the atomicity of the commit structure and is something I really want to avoid.
When I look at the logs generate by Apache there is no error messages.
When I bumped the loglevel from debug to trace6 on the Apache server, there is some errors appearing at the moment when the upload stalls:
...
OpenSSL: I/O error, 2229 bytes expected to read on BIO
OpenSSL: read 1460/2229 bytes from BIO
...
Versions used:
We are running the connection to the subversion via apache, mod_dav, mod_dav_svn, mod_authz_svn and mod_auth_digest. The client connects via https.
Server:
OpenSuse 42.3
svnserve: 1.9.7
Apache: 2.4.23
Client:
Windows 10 enterprise
svn client: 1.10.0-dev.
What I tried so far:
I have tried increasing the TimeOut value in the apache configuration. The only difference is that the client ends up in stalled mode longer before posting the timeout message.
I have tried increasing the MaxKeepAliveRequests from 100 to 1000. No change.
I have tried adding SVNAllowBulkUpdates Prefer to the svn settings. No change.
Have anyone got any hints on how to debug these types of errors?
I'm using the ServiceStack Redis Client and I was hoping that I could get a clarification on what might cause the following error ... "Unable to Connect: sPort: 50071"? I'm using the "PooledRedisClientManager" object for connections. Thanks for any assistance.
IF YOU ARE USING A SELF HOSTED REDIS SERVER AND USING THE Service Stack Redis Client THEN BUYER BEWARE
As of 9/23/2015
Service Stack does license validation in the client code (rather than the server). If you are ripping through a lot of messages 6000+ an hour you will get. The resulting error is
Unable to Connect: sPort:
However, it is not handling their custom LicenseExpection and exposing the error correctly. The error would be something like this:
The free-quota limit on '6000 Redis requests per hour' has been reached. Please see https://servicestack.net to upgrade to a commercial license or visit https://github.com/ServiceStackV3/ServiceStackV3 to revert back to the free ServiceStack v3.
I doubt you have imposed such a limit on your server :-)
This could be a time out issue, try increasing it:
pooledRedisClientManager.ConnectTimeout = 1000
You need to check that you are not creating a new PooledRedisClientManager for each request / usage. You will quickly run out of ports. Use a singleton approach in a web environment.
My server fired every week a 510 HTTP error. After reboot the apache, the problem was solve.
But this is more a workaround as a solution for this problem.
Any ideas, how to solve this problem?
Got the same issue , one of sites that im holding got the same story - many errors in firebug "510 Not extended" .
Checked configuration of apache and server , there was limit on numbers of connections and total outgoing traffic bandwidth .
When put it to unlimited all working perfect when ,enabling limiting get this error, need to find the middle when it working good and there no "unlimited" for all traffic set.
The reason why we set this limiting was - one of the sites on server was raising traffic, up to limit of whole server - too much connections and outgoing traffic ... we didnt find this site ,but added module that allow you manage traffic and connection limiting per site.
So in my opinion you have the same issue when one of the sites raising your traffic and you start get this error - you as you said restarting apache - and that solves this permanently.