We have an API with Googe App Engine. The process does as follows. We have two calls to datastore with objetify and a call with urlfetch (to an external API).
We were working normally and suddenly we started to get in the client some 502 errors. There is not error traces in the server. The message we are getting is this one:
Do you have any idea of what is happening??? The only change we made was to release the project with different versions, we did it because somebody in Google support recommended us to do it.
Does it mean that GAE is doing some internal maintenance? if so, shouldn't they tell us in some way.
We talked to Google support. They told us that these errors are unpredictable and expected (if they are in a very small percentage, less than 0.01%). They suggested to do an exponential back-off and retry the request.
The reason why this happened was due to a network connectivity loss for a single machine in Google's wide cluster.
Related
we have a Restful web service created using Jersey and running on TomEE 7.0.3
we are using Android platform for client-side and it's using Retrofit for having communication with the server.
our system is modular and contains more than 14 parts.
about 3 weeks (until now), sometimes the clients getting too many follow-up requests as the response.
we searched for it in here and retrofit issues in github.
they said that it might be server falt so we trace the request with ngrep command on the server.
we saw that server was getting the request and also responding to it correctly even when clients get follow-up.
we also test this matter with different networks and this matter still remains.
so what else could cause this problem?
after several tests, we realized that this error is only on Android platforms (we tested the APIs with Postman when Android platforms were receiving Too many follow up request.
so after some more tests, we found out, when Android platforms get 408 as a response code they show this message. we changed the status code and this problem fixed.
I put this issue on square/okhttp repository in github and they put the bug flag on it.
you can see it here
---- update ----
they said it fixed in OkHttp v3.10
We are using the Exchange Web Service (EWS) API against Office 365 to create calendar events in the calendar of a user. This works fine for an on-premise deployment, but with an Office 365 deployment we seem to be hitting a throttling limit fairly quickly.
After creating 16 events, in the calendar of 16 different users (from a service account, using delegate access to the calendars), we receive the following error:
ErrorTooManyObjectsOpened - Too many concurrent connections opened
After ~5 minutes, this error clears and we can continue creating events. It seems that the EWS server caches connections to mailboxes, and Office 365 only seems to allow a connection to 16 mailboxes at a time.
We tried a lot to overcome this error, but have not found a 'final' solution or workaround. What we tried:
Using impersonation instead of delegation: this works, but is a no-go from a security perspective.
Using multiple service accounts: this works, although each account it still limited to ~16 users per 5 minutes.
We tried the X-AnchorMailbox and X-PreferServerAffinity headers, and we making requests with and without HTTP keep alive, and with and without keeping the HTTP cookies.This does not make any difference. From the debug info we see that we usually end up on the same front-end and back-end server if we keep the cookies/connection, and that we end up on a different front-end if we drop the cookies but send a X-AnchorMailbox header.
We have not yet tried the REST API, since the client credential flow is not available yet.
Only the CreateItems call seem to cause this problem, we can do a FindItems for many users without hitting a limit.
Is anyone aware of a way to overcome this limitation, e.g., is there some call we can do to close the cached mailbox sessions on the Office 365 side? Or is there an Office 365 administrator in the room who can shed some light on the exact throttling limits, and why they are so much lower than the on-premise Exchange throttling limits?
Other details: we are using a modified version of the EWS Java API, but have done some extensive research and are quite sure this problem is server-side.
Unfortunately there is no call you can make to close the connections. Impersonation is the recommended solution. You said it's a "no-go" from a security perspective, can you elaborate?
An app I am working on relies on connecting to a private, remote server to login via an API.
The other day, I got an ANR message and I think it was due to the server being offline (its a Windows Server that was being updated).
In my app, I am using the following code:
new ReadJSONFeedTask().execute(url).get();
Which turns an AsyncTask into a synchronous task (I believe!)
And because the server was offline, I think the app got hung up, causing the ANR (it's my only lead at the moment, and all seems to make sense, despite the code above is inside a Service class, which shouldn't cause an ANR, should it?)
So, I want to try an simulate the server being offline. I tried replacing the URL with one that simply doesn't work, by removing some letters from the hostname, but that only triggered an "UnknownHostException".
Is there any way to achieve this kind of simulation? I know there are tools for browsers to simulate low bandwidth etc, but have no idea what could be done when my app is running on Android and is trying to connect to a remote server that I can't really reboot at will.
I am using Java EWS API in my web application to connect my application to MS Exchange and read user email requests. Also I am using a scheduler to pull subscription every 1 minute.
Problem is when I start my application, EWS-API works fine. It gets all new mails and processes it. But after few days, whenever the scheduler tries to pull the subscription inbox, the application throws the following error :
microsoft.exchange.webservices.data.ServiceResponseException: The specified subscription was not found.
Maybe it is thread issue or memory issue, I am not sure. Please suggest any reason for this issue.
Have a look at this article, the Client Access Server affinity issue it describes maybe what you are encountering.
http://blogs.msdn.com/b/exchangedev/archive/2011/07/20/client-access-server-affinity-and-network-load-balancing-considerations-for-programmatic-access-to-exchange-online.aspx
Supposedly if you use the EWS Java version 1.1 library (or later) you shouldn't get this particular issue however.
So I'd try checking your EWS library version, and if you still get the problem, add retry logic into your app to recreate the subscription when you encounter this error.
I have been using EWS Push subscription since 2017 so not sure if below might help or not but if you can share your code I can check and see if I can found something.
For Push Subscription I have seen many different errors and to avoid any issues I am using an Object Pool of connection and if I encounter any random error from Exchange Server, I discard current connection and create a new one which mostly solve these kind of issues.
Also you can try setting anchor mailbox while establishing connection it helps with some of the issues.
Also if you can share some sample code I am happy to check.
A friend and I are currently working on a turn-based game with chat with both desktop browser and Android clients, with Google App Engine as the server.
We're using the Java API for GAE and using HTTP for communication with the server. We've implemented simple chat functionality, and we're getting undesirable latencies 1-3 seconds from both the browser and Android clients while just posting simple one-word chat messages.
My friend thought it would be best to use XMPP instead of HTTP, but we want to use a Google Accounts cookie for authentication from the Android client, and according to the GAE documentation, XMPP clients cannot use a Google Accounts cookie and must use the user's password.
Does anyone have any suggestions as to where the latency might be coming from, how to troubleshoot it, and/or what to do about it?
Also, is anyone aware of any opensource implementations of chat (or something similar) on GAE done in Java? Can't seem to find any.
One way to analyze the situation would be to use Wireshark to look at the network traffic during the delays.
You don't say how your chat messages are getting from one JVM to the other. If you're using the datastore, maybe try memcache?
Also, startup time is often an issue; app engine starts and stops JVMs all the time, particularly for a low-traffic app. A way to diagnose this is to reload the page a bunch of times (send more messages) and see if it gets faster after a while. It should be pretty easy to tell the difference in the admin console logs.