We have received mail from Google mentioned that "It appears that your project is performing intrusion attempts against a third-party. We will suspend your project in 3 days unless you correct the problem by ensuring your project traffic directed at third-parties is expected, and that your project has not been compromised."
I have cross checked all my access/error log, Firewall ports,DDoS log, etc. I've not found any problem from server end. Has anyone faced same issue?. It's critical for my client project.pls help
Related
I have an application which writes lots (millions) of calendar entries to mailboxes for large organisations. Occasionally, Office 365 EWS API will accept a batch of entries, return success (not error) codes, and the entries fail to make into mailboxes.
Microsoft support don't (appear to) have a public-facing API support team so the usual Microsoft support routes just say either "third-party application" or "we don't have a support team you can speak to" ... so I'm a bit stuck. This does not appear to be a failure of the app, as I can see from the trace that it writes successfully and is given a change key back. And this only happens over a short period of time (say, all writes in a 30 min window have this problem).
I'm a bit stuck as to where to go here, as there's no error, just occasional and undesirable behaviour. It could even not be the API that's at fault, and could be just a sync error between EWS and mailbox stores. But, as it's Office 365, I can't see this.
Application is .Net 3.5 if it helps; very stable installs, runs fine for years, just occasionally has this problem... with just one customer...
I'm a bit stuck as to where to go here, as there's no error, just occasional and undesirable behaviour. It could even not be the API that's at fault, and could be just a sync error between EWS and mailbox stores. But, as it's Office 365, I can't see this.
EWS is just an API to access the Mail Store there is no sync involved and no cache, if your getting an ItemId returned then it must at some point have been written to the Exchange Store. DAG's https://learn.microsoft.com/en-us/exchange/high-availability/database-availability-groups/database-availability-groups?view=exchserver-2019#:~:text=A%20DAG%20is%20a%20group,affect%20individual%20servers%20or%20databases.&text=For%20example%2C%20you%20can't,servers%20in%20the%20same%20DAG. are Exchanges way of ensuring redundancy.
How are you determining that the appointments aren't in the Mailbox (or haven't been deleted or modified by another mail client). Most likely it will be another mail client (eg the IOS client has been cause of many issue of the past years). I would suggest calendar logging or auditing maybe be useful to see what might be happening if you can reproduce the issue.
I failed to start my instance (through the web browser), it gave me the error:
"The zone 'projects/XXXXX/zones/us-central1-f' does not have enough resources available to fulfill the request. Try a different zone, or try again later."
Can anyone suggest some resolution to it.
The share error message meaning that you’re having a temporary resource stock-out issue in that particular zone. I would like to point you to this post made by "Paul Nash" on 4/18/17, who thoroughly explained the resource stock-out issue at Google Cloud Platform (GCP).
As a workaround, I would recommend that you try a different zone or to try later if you are looking to get resources in the same zone as those issues are to be expected transiently.
We also recommend deploying and balancing your workload across multiple zones or regions to reduce the likelihood of an outage. For more details visit the following link. Please review the documentation which outlines how to build resilient and scalable architectures on Google Cloud Platform.
Again, we want to offer our sincerest apologies. We are working hard to resolve this and make this an exceptionally rare event.
We have a crawling engine that we are trialling on Google Kubernetes Engine.
It appears that we are severely network bound when it comes to making request outside the google network.
We have been in-touch with an architect at google, who though that perhaps there was some rate-limiting being applied inside the google data centre. He mentioned that I should raise a support ticket with Google to investigate. Raising a ticket involves subscribing to a support plan (which I am not ready to do until the network issues are addressed) [a bit of a catch-22].
Looking at the network documentation: https://cloud.google.com/network-tiers/?hl=en_US it seems that rates might be severely limited. I'm not sure that I'm reading this right, but are we saying 6Mbps network?
I'm reaching out to the community / Google to see is what we are seeing is expected, if there is any rate limiting and what options there are to increase raw throughput?
You can raise a ticket with Google using the public issue tracker free of charge. In this case, since it's possibly an issue on the Cloud side of things, raising a ticket in this manner will get a Google Engineer looking into this.
Saw this error a few times today in Chrome's developer tools, and trying to figure out what it means / what we can do to avoid it.
"Failed to load resource: net:: ERR_CERT_DATABASE_CHANGED"
This was causing some image urls to fail to load in our testing. Fwiw I just checked the cert for the site in question, and it was issued over a year ago and is valid until the end of 2016, so it doesn't look like any changed serverside.
Google search turns up pretty much nothing for this error message, so hoping Stack Overflow will have more answers.
So the best I've been able to discover is this: https://chromium.googlesource.com/chromium/src/net/+/master/spdy/spdy_session_pool.cc and a few related tickets in Chromium about this code. It would appear that when the system cert database changes - in my case, potentially just a crappy puppet policy double checking that only trusted certs are in our store - Chrome reacts by closing down all existing connections and returning network errors to any outstanding request.
I had the same problem.
You may have Kaspersky Antivirus installed.
The Kaspersky software is manipulating the system keychain frequently (sometimes many times a second), which is causing Chrome to flush connections, because the system trust store has changed.
You can try it:
Remove Kaspersky;
disable Kaspersky web traffic interception
I also found a page with a description of the bug https://bugs.chromium.org/p/chromium/issues/detail?id=925779#c29.
We are using the google-api-client gem in our Ruby on Rails project to access the Google Drive API methods and everything has been working great. However, we are sometimes receiving the following error response from the API when calling the drive.files.update or drive.files.insert methods:
{"code"=>500, "message"=>"Unable to read application configuration information"}
This error is not documented in the list of possible errors from the SDK, so I am not sure how I should go about it. Could you please help?
Thank you!
If this error is transient, the best way is to have a retry strategy when that happens (simply retry the request 2 or 3 times before giving up).
It seems like some concurrency issue on the Drive side where a request to read your application's configuration times out. By experience with Google APIs - and web APIs in general - I can tell you that, even though the team will try to fix/improve these (btw I will repport the bug so they can investigate) errors like that will always happen once in a while even with a very low occurrence as concurrency, timeout and reliability issues on distributed, web-scale systems are extremely hard to resolve. The best to have fail-proof code on your side is to retry a few times on every single 500 and 503 errors from external web APIs.
If you really have time on your hands you could even implement an exponential backoff strategy where the time between each of your retries increases each time as described in our documentation.