I am trying to set up an email server, where people can email my app, and my app will process the information given in the body.
I was testing it last night and sent a bunch of emails to the server (22), but the last message went out at about 10pm eastern. For whatever reason, when looking at the server logs this morning, it is still saying that it is receiving emails from my email address (which it definitely isn't..). I was doing a lot of debugging and I'm wondering if GAE is recycling instances somehow if there was an error? The behavior seems incredibly odd and I don't know how to stop it.
From my app.yaml, the instance is only loaded up when an email is received, and no one else according to GAE's logs is emailing my server.
Thanks!
Here's a bit from my logs:
2014-03-30 06:58:50.668 /_ah/mail/[emailaddress]#[myappname].appspotmail.com 500 519ms 2kb module=default version=main
0.1.0.20 - - [30/Mar/2014:03:58:50 -0700] "POST /_ah/mail/[emailaddress]#[myappname].appspotmail.com HTTP/1.1" 500 2076 - - " [myappname].appspot.com" ms=520 cpu_ms=21 cpm_usd=0.200348 app_engine_release=1.9.1 instance=00c61b117cc3c88c83fa0e016a492569707566
I 2014-03-30 06:58:50.164
Received a message from: [my personal email address]
Except I definitely didn't send an email at 6:58am..
Related
I tried getting the IIS logs as per GMT (when the call was made) and also the client time zone plus collected the logs for a day before, including and after the day the call was made.
Now I get 200 and 404 error codes, I do not get 400 error codes in the logs (or those that I get don't match the user's time stamp of the call)
Are all 400 error codes always logged and what could be the reason they are not showing in the IIS logs?
Is there anything specific we should be keeping in mind when collecting the logs/ queries.
Note: when collecting the IIS logs, I seemed to have gotten some errors regarding file creation etc, could that be the reason?
Check your request logs. Sometimes they don't go in the error log depending on your configuration.
I'm trying to set up the email receiver found here, to process incoming emails and send them out as POST data to a script on my server to be handled further from there. The issue I'm having is when I send one test email to foo#[myappname].appspotmail.com, the App Engine logs show that the email is continually "received" over and over again every couple of minutes, even though I only sent it once. Then after several minutes of this, when I go into settings and disable the app, I get at least one "Delivery to the following recipient failed permanently" message to the email account I was sending the emails from (makes sense, since the app is now disabled and not accepting any incoming mail).
What I'm having trouble understanding is why the application is behaving like it's getting multiple emails sent to it when it's only one. Do I need to modify the Python script to do something to delete or halt the email once it's been processed the first time? If so, does anyone have any suggestions as to how to do that? The Python script that I'm using is found here.
User voscausa answered my question-- the email requests kept retrying because the script was erroring. Thanks!
I am getting this error about 20% of the time. I've dumped and compared traffic on successful and failed requests and there is no noticeable difference:
There's nothing in the AppEngine logs or dashboard, and also no way to catch exceptions on requests that hit "/_ah" URLs. I've attached a script that tries the login every 5 minutes, as well as the traffic dumps for successful and failed requests.
I would really appreciate it if someone from Google could take a look at this. The error definitely occurs deep in the bowls of the AppEngine OpenID implementation and there is no way for an outsider to see such errors.
Thanks,
Graeme
https://dl.dropboxusercontent.com/u/6618078/AppEngine%20OpenID%20error/error.dump
https://dl.dropboxusercontent.com/u/6618078/AppEngine%20OpenID%20error/success.dump
https://dl.dropboxusercontent.com/u/6618078/AppEngine%20OpenID%20error/test.sh
It could be related to this bug that is only 3.5 years old and not fixed as they don't consider it a "production issue".
https://code.google.com/p/googleappengine/issues/detail?id=3589
The bug is about non-gmail accounts but I have the same server error with gmail accounts (started today for me, 01/12/2014).
No error acknowledged here https://code.google.com/status/appengine.
I have an application hosted on the Google App Engine platform. The application is mostly I/O intensive and involves a high number of upload and download operations to the app engine server by an HTTP client.
My question is: what does the instance hour comprise of in this case ? Does it include the total time taken by the HTTP client to upload the request data ? Or does the instance hour calculation begin when the entire request data is uploaded and processing of the request starts ?
Example results from the application:
An HTTP client sent an upload request to the app engine server, request data size 1.1 MB
Time taken for request to complete on the client side - 78311 ms
Corresponding server log entry:
- - [Time] "POST / HTTP/1.1" 200 127 - "Apache-HttpClient/UNAVAILABLE (java 1.4)" "" ms=3952 cpu_ms=1529 api_cpu_ms=283 cpm_usd=0.154248 instance=
An HTTP client sent a download request to the app engine server.
Time taken for request to complete on the client side - 8632 ms
Corresponding server log entry:
- - [Time] "POST / HTTP/1.1" 200 297910 - "Apache-HttpClient/UNAVAILABLE (java 1.4)" "" ms=909 cpu_ms=612 api_cpu_ms=43 cpm_usd=0.050377 instance=
Which of these figures contributes towards the instance hour utilization - is it a) ms, b) cpu_ms or c) the time taken for request to complete on the client side ?
Please note that the HTTP client uses a FileEntity while uploading data, therefore I assume that data is sent over by the client to the server in a single part.
Incoming requests are buffered by the App Engine infrastructure, and the request is only passed to an instance of your app once the entire request has been received. Likewise, outgoing requests are buffered, and your app does not have to wait for the user to finish downloading the response. As a result, upload and download time are not charged against your app.
To understand numbers in log look at log breakdown, a bit more readable here.
None of the options you presented (a. b. c.) are directly billed. It used to be that GAE counted CPU time as a unit of cost, but that changed Nov 2011. Now you pay for instance uptime, even if instance is not handling any requests. Instances stop being billed after 15 min of inactivity.
(This does not mean that GAE actually shuts instances down after they stop billing for them - see "Instances" graph in your dashboard.)
How many instances are up depends on your app's performance settings.
Since your app is IO intensive it will help to enable concurrent requests (Java, Python 2.7). This way instance can run multiple parallel requests which are mainly waiting for IO - in our app I'm seeing about 15-20 requests being served in parallel on one instance.
Update:
This is what first link says about ms=xyz log entry:
This is the actual time (hence 'wallclock' time) taken to return a response to
the user, not including the time it took for the user to send their request or
the time it takes to send the response back - that is, just the time spent
processing by your app.
Note that Nick Johnson is an engineer on GAE team, so this can be taken as authoritative answer.
I want to host an SMS application on GAE and all my traffic will come
from a SMS GATEWAY with a single IP address.
Is that fine(I'm expecting 500 dynamic requests/sec) ?
Will there be any problems like unusual traffic errors or any other issues ?
EDITED
More info:
My users send queries through SMS which will be routed to my app from SMS GATEWAY(single IP address).
My app processes those queries and reply back through SMS (again through SMS GATEWAY).
I can reply using URL FETCH(not a problem) but what i'm worried about is if I receive some 500 dynamic requests/sec from single IP address , GAE might block them thinking them as Dos(denial of service) attack .
GAE either asks the user to enter a captcha at https://www.google.com/accounts/DisplayUnlockCaptcha or redirects to sorry.google.com and displays an error message itseems if it receives unusual traffic from single IP . But my users access app only through SMS.
Please look at this production issue filed.
It would be technically doable - your app can detect the user's IP via the REMOTE_ADDR environment variable, and if it's the one you want, show them the actual page (showing them a 403 otherwise). Your second question is a bit trickier to answer - your App Engine app could handle it assuming you wrote it in a scalable manner (not a trivial assumption!) and if you can afford the amount of traffic you're trying to throw at it.
You're right to be concerned that getting that level of traffic from a single IP might set off some form of DoS protection - it shouldn't, but it's impossible to rule it out. If it were to happen, you could file a production issue, and we'd take care of it.