[google-appengine] Test
Testing -- You received this message because you are subscribed to the Google Groups Google App Engine group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/GDb7R4Dyk30J. 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.
Re: [google-appengine] Test
For what ? Regards Thanks Shilendra Sharma +919891343808 shilendra...@googlemail.com On Thu, Nov 8, 2012 at 5:39 PM, Christian christian.devso...@gmail.comwrote: Testing -- You received this message because you are subscribed to the Google Groups Google App Engine group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/GDb7R4Dyk30J. 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. -- 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.
[google-appengine] Immutability of *Key in Go datastore package: Is it really immutable?
The documentation states that *Key is immutable, but what prevents somebody
from writing this:
key := newKey(context, Entity, , 123, nil)
*key = *someOtherKey // The key referenced by 'key' has now changed
violating immutability.
...
*key = Key{}
Even more grievous, would be this.
parentKey := newKey(context, Parent, , 456, nil)
key := newKey(context, Entity, , 123, parentKey)
*parentKey = *someOtherKey // Also modifies the key that 'key' references
as a side effect!
In my experience raw reference types in go such as pointers, slices, or
maps can make no guarantees regarding immutability.
--
You received this message because you are subscribed to the Google Groups
Google App Engine group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-appengine/-/HJTW6OpGKNEJ.
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.
[google-appengine] Re: Understanding Request was aborted after waiting too long
+1 On Thursday, 8 November 2012 17:09:49 UTC+13, ckhan wrote: Several requests over the last two days have failed with: 0.1.0.2 - - [06/Nov/2012:10:26:04 -0800] POST /_ah/queue/deferred HTTP/1.1 500 0 http://myapp.appspot.com/my/url; AppEngine-Google; (+ http://code.google.com/appengine) 1:1352226364.645785 Request was aborted after waiting too long to attempt to service your request. I know this problem is reported and discussed often here - but I'm still unclear on precisely how to interpret it. I'm trying to make sure I understand the relationship between idle instances, pending latency, dynamic/resident instances, warmup requests and startup time. My configuration: Idle instances : 4 - Automatic Pending latency: Autoomatic - Automatic My app makes having use of deferred, at the time of the failure several dozen tasks were posted to the app from taskqueue. 1. I'm going to start by assuming that while this request came to my app from the taskqueue (via the deferred library), this problem has nothing to do with the taskqueue per se. 2. The 500 means that this request in the Pending Queue: https://developers.google.com/appengine/docs/adminconsole/performancesettings App Engine's scheduler is responsible for routing incoming requests to be served by your app's instances. Sometimes the volume of incoming requests exceeds the capacity of the instances currently available to your app. When this happens, incoming requests may have to wait in the Pending Queue until busy instances become available, or until the scheduler starts new instances. 3. So by that definition, there were only 3 ways out of the queue. After minimum pending latency, but before max, Scheduler does one of these: 1. One of the 4 resident instances becomes idle, and get the request. 2. One of the dynamic instances becomes idle, and gets the request. 3. Scheduler spins up a new dynamic instance. 3a. If the instance comes up in time, the request is sent there. As the 'inaugural request' to this instance, this request is known as a loading request. Your app handles the request, but its noticeably slower. You get the warning in the log: This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application. 3b. If the instance does not come up in time, the request is aborted in the Pending Queue before the app ever sees it. You get the error in the log: Request was aborted after waiting too long to attempt to service your request. The big questions I have : 1. Is my summary above accurate? Are there any other cases where request was aborted after waiting too long happens? 2. How long can you sit in the pending queue before you hit case #3b, and the request is aborted? Do I have any control over this value? 3. I don't have warmup requests configured. Would this have helped? If so, why? The scheduler has *real* requests waiting in the pending queue, why/when would it need to send me warmup ones? And most importantly: How can I tell the difference between : my instance took too long to come up because my app isn't optimized properly (ie, my problem) AND my instance took too long to come up because of something internal to GAE, entirely outside of my control (ie, an issue that should be reported GAE prod) Thanks so much for any comments/pointers/responses. -ckhan -- You received this message because you are subscribed to the Google Groups Google App Engine group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/gkOeLbaI4l0J. 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.
[google-appengine] Re: SDK 1.7.3 not detecting source file changes - ANNOYING!
+1 on Windows 7, on an old app, very annoying since it uses default datastore and a reset takes more than a minute On Wednesday, November 7, 2012 10:02:28 PM UTC+2, Jason Collins wrote: I've been seeing this on Mac as well. Very misleading and annoying. On Tuesday, 6 November 2012 18:17:43 UTC-6, Jakob Holmelund wrote: We have the same issue. 4 guys running on ubuntu. This is really annoying.. Den tirsdag den 6. november 2012 04.55.41 UTC+1 skrev GregF: I just updated to SDK 1.7.3 running on Linux. At the same time I switched to the SQLite datastore stub, suggested by the depreciation message. After this, edits to source (python) files are not always detected, and I have to stop and restart the SDK after every edit. Occasionally it starts working for a run, then stops working again. Jinja2 template file modifications are being detected properly, presumably because it has it's own file change detection. I asked on Stackoverflow, but apart from one other person with the same problem, got no responses. This is intensely annoying. Is anyone else seeing this? Any ideas on how to diagnose and fix it? Cheers! Greg. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/rHdrQDX5ppAJ. 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.
