I don't know how to present the title more clearly.
I want build a site on Google app engine (GAE), and one app on android.
The site on GAE should wait the signal which is from the app on android and handle the signal to do something.
I don't know how to search the "keyword" on Google of waiting signal on GAE, or what method should I use.
Is here have anyone who have some related experiment on it ?
Thank you very much.
You don't seem to have understood how web applications work. They don't wait for signals - or, rather, that's all they do. Every page served by a Web service is in response to a signal, ie a request. Your web service just needs to respond to normal requests in the normal way.
Related
I am deploying my Nodejs sample app to Google App Engine Flexible env and when I am using google app engine URL which is in the form appspot.com to hit my API, it is taking around 11 secs to send response from my mobile data, but other APIs are sending response in milisecs.
Also, the time delay is only happening when I am opening my android app and sending request to the server after that all requests are taking normal time, and again delay is coming when I again open the app and send request to the server.
Edit - I found that
This can be a caused when your application is still booting up or warming up instances to serve the request and can be called as loading latency. To avoid such scenarios you can implement health check handler like readiness check so that your application will only receive traffic when its ready
That's why I checked in my Logs that readiness check is performed sometimes around 1 sec
and sometimes around 200 ms
Can anyone please tell me is there anything wrong in warming up my instances because I don't think cold boot time is causing this problem.
Edit 2
I have also tried to set min_num_instances: 2 so that once loaded atleast my 2 instances will again not get boot up, but the thing is delay is again same.
Edit 3
runtime: nodejs
#vm: true
env: flex
automatic_scaling:
min_num_instances: 2
max_num_instances: 3
Edit 4
I am noticing a strange behaviour that when I am using this app Packet Capture to capture traffic, then all https requests (if I am not enabling SSL Proxying) and all Http requests are executing in milisecs whereas without using this app all Http/Https requests are taking 11-16 secs of delay.
I don't know how but is there any certificate kind of issue here?
Edit 5
Below I have attached Network Profiler where delay is coming 15 secs
Please Help
Depends on which App Engine you are using and how you setup the scaling, there's always a loading time if you don't have a ready instance to serve a request. But if you have readiness check to ensure your instance is ready (and not cold started for the request), then there shouldn't be a problem.
Can you find a loading request or any corresponding slow request in your logs? If not, then it's likely an issue with the app. If possible, instead of calling this API on your app, do it from two apps (one is already open, one is not). So you make calls from both apps and if you notice that the one that's already open is getting a response faster than the other one, that means that's a problem with the app itself. App Engine can't determine whether or not your app is pre-opened so any difference would be client side.
=== Additional information ===
In the your logs, there's no delay at all. The request enter Google and was processed within a few milliseconds. I am sure there's something application-side. Maybe your app is constructing the request URL (first request) from some other source that results in the delay? App Engine has no knowledge of whether or not your app is opened or not or whether it's sending a first request after being opened, it cannot act differently based on it. As long as your App Engine instance is ready and available, it will treat your request the same way regardless of whether or not it's your first request after the app is opened.
The issue is resolved now, it was happening because of network service provider which is Bharti Airtel, their DNS lookup was taking the time to resolve the hostname. After explicitly using alternative DNS like Google 8.8.8.8 the issue got completely resolved. Maybe it's a compatibility issue of Airtel with Google Cloud.
Last time I checked I remember having to put a warmup request handler so that Google would know that the instance is up and running and can be used to answer calls. Keep in mind that code has to be EXACTLY under the endpoint you specify in the handler under the yaml file. (Wouldn't be the first time someone forgets that)
Here are the docs https://cloud.google.com/appengine/docs/standard/python/configuring-warmup-requests this is python specific, but you can also check other languages like Go, Java, and such in the docs.
If the problem is client dependant (each time a new clients spawns and makes a call it gets the latency) then it is most likely, either a problem with the client app itself or with initialization, registration or DNS resolution.
You could also try to reproduce the requests with CURL or similar, and see if also with those you see the mentioned delay.
I know this is some sort of pattern question and had lots of reviews but I am here for something slightly different. In the world generally there are 3 main types of APIS which provide these functions:
QuickBlox, Sinch and PubNub.
I do not want use any of them. They are purely horrible for me. Now each of them separately.
1) QuickBlox - Setting its API is already a huge headache, you are writing heaps of code, logging user every time to get the calling ready. Plus QuickBlox do not keep any session out of box (in the background) so no luck with background listening for incoming calls. So I quit QuickBlox.
2) PubNub - Pretty much OK but the price and the trial is absolutely crazy. I can't imagine myself giving someone 50 dollars every month just for audio call and video call functions, whereas I would not have any income from both of them as there is no such good app in world which offers paid app-to-app calling, so mine should be free too. And also I am in the development phase so I do not want to waste money. They say they giving free 100 users at start. But what it is ridicioulus as 100 users won't give any income so the PubNub is fast out.
3) Sinch - This was the only library I loved and loved really much, I even asked them to add a function of WebRTC of videocalling and they did it! But still there is one more big issue which cannot be handled. The background service. Sinch does not provide and you do not have any chances to listen for incoming calls if your app is killed, so Sinch unfortunately is out too.
4) The last option I HAD to do, because I had no choice, was SIP of Android. It is basically saving hugely but I encountered an issue. I generally and now think to fully move to SIP calls, I did try to load the demo, but what is the issue, is that as far as I understood, to make SIP calls you MUST have a SIP account pre-registered. The horrible part is that I am developing a chat application and that chat application should have that audio calling at least. So it is not good practice to ask users to register a SIP account with in-app account. So by Googling I did not find any solution and came here to ask. Is there any way,to register to a SIP server (free SIP servers which are plenty on the net) with default SIP class of Android, without forcing the user to do it manually? If yes can you please provide code?
I have three Android devices with the same app, but I need that the three devices start the app simultaneously.
I have a server too, and the app exchange data with this server (developed in NodeJS).
I thought that all devices can connect to the server and wait until a response. But I don't know how to do it with Node. I used clusters in Node but it didn't work, because I don't know how to synchronize all these 3 clusters.
How can I do that? Another idea?
Thank you.
Well, it's easy to implement with generic events in node.js. Create some special event, and keep requests without response until the event is triggered, what obviously happens when 3rd request is received. node.js is very powerful in that.
Hi i'm relatively new to android programming and am trying to do the following. I want to create a messaging system in which immediate response is not (at least for now necessary). I am completely new to networking / socket programming but have followed this:
http://www.tutorialspoint.com/python/python_networking.htm
and have kinda got my head around it.
I have the following question with regards to best practice.
What are the advantages/disadvantages of method A and B.
Method A:
Have a server and client running on the app.
Method B:
Have a client running on the app and pinging the server every minute for data.
Apart from the obvious that Method B doesn't allow real time which is better suggested? Does a server application take too much memory / CPU / battery etc? I know a lot of IM apps exist, how do they work?
Thank you in advance
Why not use push notifications?
http://developer.android.com/guide/google/gcm/index.html
I would recommend Google Cloud Messaging but last time I checked you needed a dedicated server to install it. Or Am i wrong? I only had a shared server so:
method A: the difficult part, considering its a mobile device, would be to keep the connection alive when your phone changes IP (another wifi network for example) and
method B: you could make small simple messages in order to check if there is something new and update in that case. My app sent around 500 bytes every 30 seconds and I didnt have any battery related problems. It also didnt slow the phone down.
I have developed android apps, and have a web server application which serves REST style JSON, to the apps.
My apps are strongly dependent on that web services but as traffic gets higher, users' complaint started, as force close problems. I am not sure but maybe my server (AWS small instance) may not answer all requests correctly or in time.
I am planning to retry the web request when a problem on getting json response arise instead giving the error/net-connection alert.
I guess there are many developers who integrates apps with web services, so what is the good practice on handling network problems?
Or is the frequency of such network problems acceptable?
I take about 10-20 problem per day.
I have about 200.000+ web requests per day, for a AWS small instance (1.7 RAM), dedicated to server Tomcat. I analyze the logs there is no clue, no error log. Also the errors are spreaded.
You need to start with analyzing the problem, and determine the root cause or root causes of your issues. You always need to take into account that
a network connection might drop
a users switches from 3G / WiFi
the android devices "thinks" it's connected while in fact it's not
Also, be very sceptical when using the Android ConnectivityManager / NetworkInfo. Only trust it when it states that it is not connected. If it is connected, check it yourself (as sometimes, user is on a hotspot and the only connectivity he has is with a login page).
The application needs to handle all these scenarios properly. The way it's presented to the user depends on the use-case (do you want the user to be informed of the error, do you silently ignore it and just retry, ....)
In terms of retrying webservice connections, there are several ways to implement this :
exponential backoff
periodic rescheduling
event-driven triggering
retry-after moratorium intervals
You need to start by putting sufficient logging both on the client (Android) and on the server (AWS) so that you can analyze the issues and draw the proper conclusions.
I think the answer to your problem lies in the design of your android app.
You need to take into consideration the worst case scenario and redesign your application to take that into account and recover. Dealing with the chaos monkey - jeff atwood.
Personally I never allow an android app to be in a state where it needs to force close. For any or all network connection I assume that the connection is down, lossy, not all data can be retreived and (finally) up and working correctly.
That way my app will degenerate gracefully. If it needs web access it'll make an attempt in a background thread allowing the user to continue using the app, it will cache previous requests and will retry until it gets a connection or gives a nice toast to the end user.