Re: [google-appengine] Re: incoming XMPP down for app engine?
looks like the problem was googletalk being down No, it wasn't. I was logged in on my GMail/GTalk account while my bot was offline: x...@appspot.com is offline and can't receive messages right now. While we are on this topic: maybe it would be a good idea to enable queuing of messages while XMPP service is offline, so bot would be able to reply after it comes back online? Best regards, Piotr Sikora piotr.sik...@frickle.com -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Re: [google-appengine] Blobstore API Feedback
Hi Nick, I did, and it's unfortunate - feel free to file a bug - but it's still far from clear that this should result in returning a 404 to the user. I don't think this is a bug, but I believe that 404 response is simply better and more obvious than 500 in this case and since Blobstore API is still experimental and you were eager to get my feedback so that you could improve the API, I think it's good time to talk about this now ;) Just take a look at competing solutions that work this way: - S3 returns 404 for NoSuchBucket and NoSuchKey errors [1], - Azure Blob Service returns 404 for ContainerNotFound and BlobNotFound errors [2], - nginx returns 404 when file pointed by X-Accel-Redirect doesn't exist. [1] http://docs.amazonwebservices.com/AmazonS3/latest/API/index.html?ErrorCodeList.html [2] http://msdn.microsoft.com/en-us/library/dd179439.aspx Best regards, Piotr Sikora piotr.sik...@frickle.com -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Blobstore API Feedback
Hello, lately I've been playing around with Blobstore and I believe that it misses few critical features: 1. MD5/SHA1 integrity checksums. This is a *MUST*. All competing services (S3, Nirvanix, etc) provide ways to: - get checksum of already uploaded file (this should be another BlobInfo property), - upload file along with its checksum. When calculated checksum of uploaded file differs from the provided one, file is discarded and error response is sent to client. 2. Ranged requests. With large files this is another *MUST HAVE* feature and hopefully requires no explanation. 3. When success_path generates error response after upload (either 4xx or 5xx) with custom error page, it results in 500 Internal Server Error response with Google's default error page, because Blobstore requires 3xx response. In my opionion this is bad, because one cannot return custom error page. Maybe only 2xx responses should be handled as incorrect? 4. 500 Internal Server Error response is returned when wrong / old / not-existing BlobKey is passed via blobstore.BLOB_KEY_HEADER, in my opinion this should result in 404 Not Found response. Also, few times I received 500 Internal Server Error response when uploading file(s) to path previously generated using blobstore.create_upload_path(). Those errors didn't result in *any* entry in application logs and I wasn't able to find proper way to reproduce this, but my guess is that this results from either: - too old upload token (24h), - upload token generated for older deployment. Best regards, Piotr Sikora piotr.sik...@frickle.com -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Google Fronted, Content-Length and HEAD requests
Hello, I noticed that Google Frontend overrides user-supplied Content-Length header with its own. This is of course good idea, but I find this undesirable for HEAD requests, especially when combined with Blobstore. For *every* HEAD request Google Frontend returns response with Content-Length: 0. Would it be possible to disable this for HEAD requests or at least provide way to conditionaly disable this based on user-supplied header (ie. X-AppEngine-Override: Content-Length)? According to RFC 2616: 9.4 HEAD The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification. The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale. Best regards, Piotr Sikora piotr.sik...@frickle.com -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Cron jobs not running
Same here: every 1 minutes (UTC) 2009/06/11 07:09:57 on time Success It's quite strange that they stopped working on differnet times. On 11 Cze, 20:39, Philippe philippe.cr...@gmail.com wrote: only 2 persons reported that issue. then, I will be the 3rd one .. Last time a cron job worked for me was : 06-11 12:16AM I hope someone at google can solve it, starts to be long :/ On Jun 11, 5:39 pm, vivpuri vivpu...@gmail.com wrote: Can someone from Google shed some light on this issue. None of my jobs have run in the past 4 hours. As you can guess, this is going to cause major data issues cause of timeouts when the jobs start again and suddenly need to process large amount of data. Thanks On Jun 11, 9:47 am, vivpuri vivpu...@gmail.com wrote: Okay someone else also has the same issue -http://groups.google.com/group/google-appengine/browse_thread/thread/... On Jun 11, 9:40 am, vivpuri vivpu...@gmail.com wrote: I added new cron jobs couple of hours back, and now neither the new nor the existing jobs are running. All the jobs either have the schedule of every 5 minutes (UTC) or every 1 minutes (UTC) . Any idea what might be the issue here?- Ukryj cytowany tekst - - Pokaż cytowany tekst - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
