[google-appengine] Fwd: Is anyone using Appstats with Firepython support?
There's an obscure feature in Appstats that integrates Firepython support. (See https://developers.google.com/appengine/articles/firepython) It appears Firepython is no longer maintained and I doubt there are many users of the combination. Would anyone be terribly disappointed if we dropped support for Firepython in appstats? -- --Guido van Rossum (python.org/~guido) -- 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] Re: paid email quota
Christina told me that every time a credit card charge fails, appengine automatically sets the limit back to 100 emails. It this a very (very) recent change? I've had billing fail recently, and the app continued to work normally, including mail. Google only sent me an email that the app will be reset to free quota if the outstanding payment isn't cleared at a specific date. -- 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] Re: JPA transactions and entity keys
I don't use JPA myself, so I don't have a code example for you, but you
have the right concept at the end of your post. In order to be in the same
Entity Group, entities must share the same Parent entity. You should make
sure that this is actually sensible in your data model, and not simply do
it to support arbitrary transactions. You can also use cross-group
transactions, but that only supports 5 different entity groups per
transaction.
I think that in JPA it is actually a little messier to use parent entities
than with some other persistence mechanisms. If you aren't too far along,
and you don't mind using an app engine specific library, I would encourage
you to look at Objectify: http://code.google.com/p/objectify-appengine/
On Thursday, July 12, 2012 10:10:54 AM UTC-4, Peter wrote:
Hi
I'm using JPA in my application. Yesterday I tried to delete some Entities
with a same class in one transaction, but I got an exception which said
that I can not do this in one transaction as they are in a different entity
group. I thought If I persist two entities with the same class they will be
in the same entity group, but now I know that they won't.
The question is how can I persist two entities to be in the same group?
My entity looks like this:
@Entity
public class SomeEntity {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
protected Key key;
}
When I persist them the key is set automatically:
entityManager.persist(someEntityObject);
Deleting them:
... EntityManager em;
... ListSomeEntity toDelete;
EntityTransaction tx = em.getTransaction();
try {
tx.begin();
for (SomeEntity entity : toDelete) {
em.remove(entity);
}
tx.commit();
} finally {
if (tx.isActive()) {
tx.rollback();
}
em.close();
}
I saw somehow I can set a parent key to the keys but I think in this way
I'll loose the automatic id generation.
Is there a good way to resolve this problem?
Thanks,
Peter
--
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/-/EtKQdwJsa4IJ.
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: Startup time exceeded...on F4?!
Same for me.. I just checked: no calls to warmup, lots of loading requests. **shakes fist at App Engine** On Thursday, July 12, 2012 4:39:48 PM UTC-4, Tom Phillips wrote: Interesting..I checked and I too have 100% of my loading requests on user facing URLs instead of /_ah/warmup. Warmup requests are enabled and Automatic-Automatic for both instance sliders. I used to see at least a decent percentage of loading requests on /_ah/ warmup, but haven't looked in quite a while. /Tom On Jul 12, 3:46 pm, David Hardwick david.hardw...@bettercloud.com wrote: Some additional observations and questions... After reading this [Link 1] stack overflow article that mentioned an issue with having your Max Idle count below 6, we started looking at our warmup request on our staging environment because that app-id has Idle Instances set to Auto-Auto, while production had specific values. But...Where did all the /_ah/warmup requests go? When doing a label search for these staging environment logs [path:/_ah/warmup (doing a label search)] we couldn't find any warmup request!!(yes, we have warmup requests turned on)...we would just see the first cold-start request would take around 15 seconds to load (F1) and 10 seconds to load on (F2). I even shut down every instance and hit the staging server again to see if I could find a warmup request in the logs...nope. Honestly, I would rather have a user wait 10 seconds for the first request to that server as opposed risking the warmup requests failing again. Where did all the /_ah/warmup requests go? More importantly, why would we have such different times for warmup requests compared to cold starts? Shouldn't they be nearly identical?! Rock on, -Hardwick [Link 1] - http://stackoverflow.com/questions/9422698/ah-warmup-producing-hardde... On Jul 12, 12:26 pm, David Hardwick david.hardw...@bettercloud.com wrote: Hello, I realize there's been a lot of discussion on startup times exceeded on this forum recently, but wanted needed to post this experience we had this morning to keep the attention on this important issue. We uploaded a point release of our app to a not-live version this morning and, of course, we were going to click around on that instance to make sure it's all kosher before making that version live. The warm-up requests for the not-live version were exceeding the deadline limit of 60s... __and__we__are__on__F4s__!_!. However, the LIVE version of the app crashed too, 500 server errors, instance counts went to zero, all sorts of whacky stuff was seen in the control panel. All that happened to our LIVE version without when all we did was upload another non-live version and hit it with a single request...did I mention we were on F4s? ;-) Does the failure of any instance to exceed the 60s limit take down all instances to include live one? We did a few things as quickly as possible since our live application was down, so clearly we didn't have the time to take the scientific approach of only changing one thing at a time and wait to see if it that did it. We... 1. Switched from F4s to F2 (i figured if this would least get us on some new servers/instances) 2. Increased max idle instances from 1 to 2 (with F4s running, I'm fine with having just 1 idle instance and not at all happy about paying for 2 idle instances, so maybe we'll just increase this prior to deployments and then back down again after the deployment succeeds until we know more) 3. Made the recently uploaded version live (hey, why not, the production app was down for 10 minutes, so how much more harm could we do?) We use GWT and Guice, we jar everything (as I have been paying attention to this startup time discussions for quite some time now. We are also considering switching our Guice libraries to a non-AOP version as we saw suggested in another blog since we just need the injection. Any insight, and I'm all ears! app_id=s~myflashpanel Regards, -Hardwick -- *We make Google Apps even better.* *David Hardwick* *CTO* david.hardw...@bettercloud.com *Signature by Flashpanel http://flashpanel.com/* *See us in Mashable: Growing Up Google: How Cloud Computing Is Changing a Generation http://mashable.com/2012/04/30/generation-growing-up-google/* -- 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/-/Bs6JKwLYDAMJ. 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,
Re: [google-appengine] Re: Startup time exceeded...on F4?!
Now the warmup requests are fired only if you set min idle instances to some value(not automatic). -- Takashi On Fri, Jul 13, 2012 at 9:52 PM, Michael Hermus michael.her...@gmail.comwrote: Same for me.. I just checked: no calls to warmup, lots of loading requests. **shakes fist at App Engine** On Thursday, July 12, 2012 4:39:48 PM UTC-4, Tom Phillips wrote: Interesting..I checked and I too have 100% of my loading requests on user facing URLs instead of /_ah/warmup. Warmup requests are enabled and Automatic-Automatic for both instance sliders. I used to see at least a decent percentage of loading requests on /_ah/ warmup, but haven't looked in quite a while. /Tom On Jul 12, 3:46 pm, David Hardwick david.hardw...@bettercloud.**com wrote: Some additional observations and questions... After reading this [Link 1] stack overflow article that mentioned an issue with having your Max Idle count below 6, we started looking at our warmup request on our staging environment because that app-id has Idle Instances set to Auto-Auto, while production had specific values. But...Where did all the /_ah/warmup requests go? When doing a label search for these staging environment logs [path:/_ah/warmup (doing a label search)] we couldn't find any warmup request!!(yes, we have warmup requests turned on)...we would just see the first cold-start request would take around 15 seconds to load (F1) and 10 seconds to load on (F2). I even shut down every instance and hit the staging server again to see if I could find a warmup request in the logs...nope. Honestly, I would rather have a user wait 10 seconds for the first request to that server as opposed risking the warmup requests failing again. Where did all the /_ah/warmup requests go? More importantly, why would we have such different times for warmup requests compared to cold starts? Shouldn't they be nearly identical?! Rock on, -Hardwick [Link 1] -http://stackoverflow.com/**questions/9422698/ah-warmup-** producing-hardde.http://stackoverflow.com/questions/9422698/ah-warmup-producing-hardde... On Jul 12, 12:26 pm, David Hardwick david.hardw...@bettercloud.**com wrote: Hello, I realize there's been a lot of discussion on startup times exceeded on this forum recently, but wanted needed to post this experience we had this morning to keep the attention on this important issue. We uploaded a point release of our app to a not-live version this morning and, of course, we were going to click around on that instance to make sure it's all kosher before making that version live. The warm-up requests for the not-live version were exceeding the deadline limit of 60s... __and__we__are__on__F4s__!_!. However, the LIVE version of the app crashed too, 500 server errors, instance counts went to zero, all sorts of whacky stuff was seen in the control panel. All that happened to our LIVE version without when all we did was upload another non-live version and hit it with a single request...did I mention we were on F4s? ;-) Does the failure of any instance to exceed the 60s limit take down all instances to include live one? We did a few things as quickly as possible since our live application was down, so clearly we didn't have the time to take the scientific approach of only changing one thing at a time and wait to see if it that did it. We... 1. Switched from F4s to F2 (i figured if this would least get us on some new servers/instances) 2. Increased max idle instances from 1 to 2 (with F4s running, I'm fine with having just 1 idle instance and not at all happy about paying for 2 idle instances, so maybe we'll just increase this prior to deployments and then back down again after the deployment succeeds until we know more) 3. Made the recently uploaded version live (hey, why not, the production app was down for 10 minutes, so how much more harm could we do?) We use GWT and Guice, we jar everything (as I have been paying attention to this startup time discussions for quite some time now. We are also considering switching our Guice libraries to a non-AOP version as we saw suggested in another blog since we just need the injection. Any insight, and I'm all ears! app_id=s~myflashpanel Regards, -Hardwick -- *We make Google Apps even better.* *David Hardwick* *CTO* david.hardw...@bettercloud.com *Signature by Flashpanel http://flashpanel.com/* *See us in Mashable: Growing Up Google: How Cloud Computing Is Changing a Generation http://mashable.com/2012/04/**30/generation-growing-up-** google/ http://mashable.com/2012/04/30/generation-growing-up-google/* -- You received this message because you are subscribed to the Google Groups Google App Engine group. To view this discussion on the web visit
[google-appengine] Google App Engine Launcher on Ubuntu
Hi, I am having issues trying to run the launcher in Ubuntu in a specific way. I have described the problem in detail here http://bit.ly/MmOBkL Please have a look and respond any place. Thanks, Arun. -- 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/-/5iGOmZN95Z8J. 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] Google App Engine Launcher on Ubuntu
Just reading the page briefly, but maybe you can use both of the workaround in the answer #1 and the shell built-in alias feature(see man alias). On Fri, Jul 13, 2012 at 11:29 PM, deostroll deostr...@gmail.com wrote: Hi, I am having issues trying to run the launcher in Ubuntu in a specific way. I have described the problem in detail here http://bit.ly/MmOBkL Please have a look and respond any place. Thanks, Arun. -- 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/-/5iGOmZN95Z8J. 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. -- Takashi Matsuo -- 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] Re: Using com.google.appengine.api.datastore.Query.CompositeFilterOperator generates java.lang.VerifyError at runtime
not a bugits a developer upgraded last month. On Thursday, July 12, 2012 12:30:57 AM UTC-5, ArnM wrote: Did anyone experience this? I was using query.addFilter(...) before. As this is deprecated now, I changed the code to use Query.FilterPredicate and Query.CompositeFilterOperator to construct my query on the fly. It compiles fine. But the run time throws java.lang.VerifyError for the class that uses it. Is this a bug? Am I missing something? -- 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/-/7xlaboeeR2wJ. 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: Google App Engine community support is moving to Stack Overflow
i go with steve On Monday, February 6, 2012 8:14:54 PM UTC-6, Ikai Lan wrote: *Hi App Engine Developers, In the last few years, the QA website Stack Overflowhttp://www.stackoverflow.com/has become an invaluable tool for developer communities. We’re pleased to announce that we are migrating to Stack Overflow as the official channel for answering development questions about Google App Engine.The google-appengine http://groups.google.com/group/google-appengine group will remain open for general discussions and announcements that are better suited for the groups format. We believe that Stack Overflow is better platform for sharing knowledge and answering support questions given its larger community, de-duping of similar questions and contributor reputation system. We also expect that App Engine developers will be able to contribute and benefit from the wider range of language-related information not specific to App Engine. In addition, due to Stack Overflow’s use of OpenID for account management, developers will not need to create a new account to participate in the discussion - developers will be able to log in with any of the identity providers supported by Stack Overflow, including Google Accounts. We plan on deprecating the App Engine language-specific groups, namely google-appengine-pythonhttp://groups.google.com/group/google-appengine-pythonand google-appengine-javahttp://groups.google.com/group/google-appengine-java. The google-appengine-gohttps://groups.google.com/forum/?fromgroups#%21forum/google-appengine-godiscussion group will continue to remain open for at least as long as the Go runtime is in experimental status. The Python and Java groups will be placed into read-only on March 5th, 2012. While answering technical questions, we will begin nudging developers to ask their questions on Stack Overflow using the google-app-engine taghttp://stackoverflow.com/questions/tagged/google-app-engine . Please let us know if there are any questions or concerns about this announcement. Happy coding! - Ikai Lan, on behalf of the App Engine team* -- 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/-/JVEqUnwv-a8J. 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] Drive DrEdit
Hi, I try to integrate GDrive to GoogleAppEngine and started with the example of DrEdit. Unfortunately, I always get this error message. Who can help me? 1. 2012-07-13 11:31:03.948 Error for /drivex java.lang.NoClassDefFoundError: com/google/api/client/http/HttpTransport at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406) at java.lang.Class.getConstructor0(Class.java:2716) at java.lang.Class.newInstance0(Class.java:343) at java.lang.Class.newInstance(Class.java:325) at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:153) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:428) at org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:339) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at com.google.apphosting.utils.servlet.ParseBlobUploadFilter.doFilter(ParseBlobUploadFilter.java:102) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at com.google.apphosting.runtime.jetty.SaveSessionFilter.doFilter(SaveSessionFilter.java:35) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:249) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923) at com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:76) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:135) at com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:477) at com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:449) at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:455) at com.google.tracing.TraceContext.runInContext(TraceContext.java:695) at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:333) at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:325) at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:453) at com.google.apphosting.runtime.ThreadGroupPool$PoolEntry.run(ThreadGroupPool.java:251) at java.lang.Thread.run(Thread.java:679) Caused by: java.lang.ClassNotFoundException: com.google.api.client.http.HttpTransport at com.google.appengine.runtime.Request.process-1a9757181952ef12(Request.java) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406) at java.lang.Class.getConstructor0(Class.java:2716) at java.lang.Class.newInstance0(Class.java:343) at java.lang.Class.newInstance(Class.java:325) at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:153) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:428) at org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:339) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at
[google-appengine] Webrtc Multi-peer connection
Hi Guys, I am trying to implement a multi-party video conference, but I am getting some errors. Messages would not get sent to other peers. Here is my python code - http://pastebin.mozilla.org/1702256 And here is my JS code - http://pastebin.mozilla.org/1702257 -- 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] Re: Content is not allowed in prolog when running JDO Enhancement
Hi Sebastian, have you solved it? I have the same problem cheers Mirko On Thursday, August 6, 2009 12:14:39 AM UTC+2, Sebastian Sylvan wrote: I've tried to let Eclipse automatically enhance my classes, but that failed, running it manually produces the following error: DataNucleus Enhancer (version 1.1.4) : Enhancement of classes 05-Aug-2009 23:07:21 org.datanucleus.metadata.xml.MetaDataParser parseMetaDataSt ream SEVERE: Parser error with file file:/C:/Users/Sebastian/workspace/ guestbook/src /guestbook/Greeting.java has cause Error reading the Meta-Data input Content is not allowed in prolog. org.xml.sax.SAXParseException: Content is not allowed in prolog. ..etc... As far as I can tell this is just the parser complaining about some junk characters before the ?xml ... line, however there are no junk characters there! I've even explicitly saved it without a Byte Order Marker using Notepad++ but it *still* fails. So I'm guessing DataNucleus somehow it adds back in a BOM or something at the start of the file causing the XML parser to fail? The XML file I'm using for JDO is the auto-generated one (I'm just doing the guestbook sample here: http://code.google.com/appengine/docs/java/gettingstarted/usingdatastore.html ). I'm on Windows 7, using: java version 1.6.0_15 Java(TM) SE Runtime Environment (build 1.6.0_15-b03) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02, mixed mode) Anyone ever had anything like this? -- 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/-/mDzdLX4VIOwJ. 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] Is HTTP standard 'Date' header stripped from response when using Appengine's urlfetch?
Hi, I'm using Appengine's urlfetch (Python) to retrieve some data over the network. For caching purposes, I need the HTTP standard 'Date' header to be found in the received response. Unlike in dev environment, when I deploy my application in your remote servers, I don't receive this header anymore in the response. Is this behavior excepted? Did I miss something? Thanks in advance for your help, Youssef -- 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/-/a1CNoGxlQw4J. 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] Re: Startup time exceeded...on F4?!
Takashi, this is a piece of info that should be clearly spelled out in the docs IMO. I spent many frustrating hours a while back trying to figure out why my warmup requests were not working until i pieced it all together from different posts such as this one and got 1 resident instance configured. Hopefully new users don't have to go through this pain which needlessly makes GAE look bad. -Mauricio On Friday, July 13, 2012 6:28:07 AM UTC-7, Takashi Matsuo (Google) wrote: Now the warmup requests are fired only if you set min idle instances to some value(not automatic). -- Takashi On Fri, Jul 13, 2012 at 9:52 PM, Michael Hermus michael.her...@gmail.comwrote: Same for me.. I just checked: no calls to warmup, lots of loading requests. **shakes fist at App Engine** On Thursday, July 12, 2012 4:39:48 PM UTC-4, Tom Phillips wrote: Interesting..I checked and I too have 100% of my loading requests on user facing URLs instead of /_ah/warmup. Warmup requests are enabled and Automatic-Automatic for both instance sliders. I used to see at least a decent percentage of loading requests on /_ah/ warmup, but haven't looked in quite a while. /Tom On Jul 12, 3:46 pm, David Hardwick david.hardw...@bettercloud.**com wrote: Some additional observations and questions... After reading this [Link 1] stack overflow article that mentioned an issue with having your Max Idle count below 6, we started looking at our warmup request on our staging environment because that app-id has Idle Instances set to Auto-Auto, while production had specific values. But...Where did all the /_ah/warmup requests go? When doing a label search for these staging environment logs [path:/_ah/warmup (doing a label search)] we couldn't find any warmup request!!(yes, we have warmup requests turned on)...we would just see the first cold-start request would take around 15 seconds to load (F1) and 10 seconds to load on (F2). I even shut down every instance and hit the staging server again to see if I could find a warmup request in the logs...nope. Honestly, I would rather have a user wait 10 seconds for the first request to that server as opposed risking the warmup requests failing again. Where did all the /_ah/warmup requests go? More importantly, why would we have such different times for warmup requests compared to cold starts? Shouldn't they be nearly identical?! Rock on, -Hardwick [Link 1] -http://stackoverflow.com/**questions/9422698/ah-warmup-** producing-hardde.http://stackoverflow.com/questions/9422698/ah-warmup-producing-hardde... On Jul 12, 12:26 pm, David Hardwick david.hardw...@bettercloud.**com wrote: Hello, I realize there's been a lot of discussion on startup times exceeded on this forum recently, but wanted needed to post this experience we had this morning to keep the attention on this important issue. We uploaded a point release of our app to a not-live version this morning and, of course, we were going to click around on that instance to make sure it's all kosher before making that version live. The warm-up requests for the not-live version were exceeding the deadline limit of 60s... __and__we__are__on__F4s__!_!. However, the LIVE version of the app crashed too, 500 server errors, instance counts went to zero, all sorts of whacky stuff was seen in the control panel. All that happened to our LIVE version without when all we did was upload another non-live version and hit it with a single request...did I mention we were on F4s? ;-) Does the failure of any instance to exceed the 60s limit take down all instances to include live one? We did a few things as quickly as possible since our live application was down, so clearly we didn't have the time to take the scientific approach of only changing one thing at a time and wait to see if it that did it. We... 1. Switched from F4s to F2 (i figured if this would least get us on some new servers/instances) 2. Increased max idle instances from 1 to 2 (with F4s running, I'm fine with having just 1 idle instance and not at all happy about paying for 2 idle instances, so maybe we'll just increase this prior to deployments and then back down again after the deployment succeeds until we know more) 3. Made the recently uploaded version live (hey, why not, the production app was down for 10 minutes, so how much more harm could we do?) We use GWT and Guice, we jar everything (as I have been paying attention to this startup time discussions for quite some time now. We are also considering switching our Guice libraries to a non-AOP version as we saw suggested in another blog since we just need the injection. Any insight, and I'm all ears!
Re: [google-appengine] Re: Startup time exceeded...on F4?!
any reason behind this change? this seems kind of strange. I too was wondering by the behavior till you posted this. I had my min set to automatic also On Fri, Jul 13, 2012 at 9:28 AM, Takashi Matsuo tmat...@google.com wrote: Now the warmup requests are fired only if you set min idle instances to some value(not automatic). -- Takashi On Fri, Jul 13, 2012 at 9:52 PM, Michael Hermus michael.her...@gmail.com wrote: Same for me.. I just checked: no calls to warmup, lots of loading requests. **shakes fist at App Engine** On Thursday, July 12, 2012 4:39:48 PM UTC-4, Tom Phillips wrote: Interesting..I checked and I too have 100% of my loading requests on user facing URLs instead of /_ah/warmup. Warmup requests are enabled and Automatic-Automatic for both instance sliders. I used to see at least a decent percentage of loading requests on /_ah/ warmup, but haven't looked in quite a while. /Tom On Jul 12, 3:46 pm, David Hardwick david.hardw...@bettercloud.com wrote: Some additional observations and questions... After reading this [Link 1] stack overflow article that mentioned an issue with having your Max Idle count below 6, we started looking at our warmup request on our staging environment because that app-id has Idle Instances set to Auto-Auto, while production had specific values. But...Where did all the /_ah/warmup requests go? When doing a label search for these staging environment logs [path:/_ah/warmup (doing a label search)] we couldn't find any warmup request!!(yes, we have warmup requests turned on)...we would just see the first cold-start request would take around 15 seconds to load (F1) and 10 seconds to load on (F2). I even shut down every instance and hit the staging server again to see if I could find a warmup request in the logs...nope. Honestly, I would rather have a user wait 10 seconds for the first request to that server as opposed risking the warmup requests failing again. Where did all the /_ah/warmup requests go? More importantly, why would we have such different times for warmup requests compared to cold starts? Shouldn't they be nearly identical?! Rock on, -Hardwick [Link 1] -http://stackoverflow.com/questions/9422698/ah-warmup-producing-hardde... On Jul 12, 12:26 pm, David Hardwick david.hardw...@bettercloud.com wrote: Hello, I realize there's been a lot of discussion on startup times exceeded on this forum recently, but wanted needed to post this experience we had this morning to keep the attention on this important issue. We uploaded a point release of our app to a not-live version this morning and, of course, we were going to click around on that instance to make sure it's all kosher before making that version live. The warm-up requests for the not-live version were exceeding the deadline limit of 60s... __and__we__are__on__F4s__!_!. However, the LIVE version of the app crashed too, 500 server errors, instance counts went to zero, all sorts of whacky stuff was seen in the control panel. All that happened to our LIVE version without when all we did was upload another non-live version and hit it with a single request...did I mention we were on F4s? ;-) Does the failure of any instance to exceed the 60s limit take down all instances to include live one? We did a few things as quickly as possible since our live application was down, so clearly we didn't have the time to take the scientific approach of only changing one thing at a time and wait to see if it that did it. We... 1. Switched from F4s to F2 (i figured if this would least get us on some new servers/instances) 2. Increased max idle instances from 1 to 2 (with F4s running, I'm fine with having just 1 idle instance and not at all happy about paying for 2 idle instances, so maybe we'll just increase this prior to deployments and then back down again after the deployment succeeds until we know more) 3. Made the recently uploaded version live (hey, why not, the production app was down for 10 minutes, so how much more harm could we do?) We use GWT and Guice, we jar everything (as I have been paying attention to this startup time discussions for quite some time now. We are also considering switching our Guice libraries to a non-AOP version as we saw suggested in another blog since we just need the injection. Any insight, and I'm all ears! app_id=s~myflashpanel Regards, -Hardwick -- *We make Google Apps even better.* *David Hardwick* *CTO* david.hardw...@bettercloud.com *Signature by Flashpanel http://flashpanel.com/* *See us in Mashable: Growing Up Google: How Cloud Computing Is Changing a Generation http://mashable.com/2012/04/30/generation-growing-up-google/* -- You received this message because
[google-appengine] Re: Could The App Engine Python 2.7 Tutorial Be Broken?
I have not run the code in the tutorial but it looks fine to me. The error
you have received leads me to think you do not have the variable assigned
for 'guestbook_name'
guestbook_name=self.request.get('guestbook_name')
this will give you 'None' or the actual name if it has been passed.
The error occurred during the function call for guestbook_key()
So make sure you have that function in your code:
def guestbook_key(guestbook_name=None):
Constructs a Datastore key for a Guestbook entity with guestbook_name.
return db.Key.from_path('Guestbook', guestbook_name or 'default_guestbook')
And if all of that is in your code then I am not sure what else it could be
without seeing all the code.
--
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/-/-MkrffZhdFEJ.
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] Drive DrEdit
Hi, Questions like this are best served on Stack Overflow. There are tags for both google-app-engine and google-drive-sdk. Please inquire there. Thanks, Dan On Fri, Jul 13, 2012 at 11:35 AM, richi richard.j.p...@googlemail.comwrote: Hi, I try to integrate GDrive to GoogleAppEngine and started with the example of DrEdit. Unfortunately, I always get this error message. Who can help me? 1. 2012-07-13 11:31:03.948 Error for /drivex java.lang.NoClassDefFoundError: com/google/api/client/http/HttpTransport at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406) at java.lang.Class.getConstructor0(Class.java:2716) at java.lang.Class.newInstance0(Class.java:343) at java.lang.Class.newInstance(Class.java:325) at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:153) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:428) at org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:339) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at com.google.apphosting.utils.servlet.ParseBlobUploadFilter.doFilter(ParseBlobUploadFilter.java:102) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at com.google.apphosting.runtime.jetty.SaveSessionFilter.doFilter(SaveSessionFilter.java:35) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:249) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923) at com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:76) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:135) at com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:477) at com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:449) at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:455) at com.google.tracing.TraceContext.runInContext(TraceContext.java:695) at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:333) at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:325) at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:453) at com.google.apphosting.runtime.ThreadGroupPool$PoolEntry.run(ThreadGroupPool.java:251) at java.lang.Thread.run(Thread.java:679) Caused by: java.lang.ClassNotFoundException: com.google.api.client.http.HttpTransport at com.google.appengine.runtime.Request.process-1a9757181952ef12(Request.java) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406) at java.lang.Class.getConstructor0(Class.java:2716) at java.lang.Class.newInstance0(Class.java:343) at java.lang.Class.newInstance(Class.java:325) at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:153) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:428) at org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:339) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
Re: [google-appengine] Re: Startup time exceeded...on F4?!
Hi Mauricio, Yes I understand that, and we've been working on it. Sorry that it's taking long. Hi Wilson, It's coming with the pricing change. Since we started charging with number of instances, we needed to provide more control on how we spin-up a new instances. In other words, if we continued the old behavior, many developers would have complained like App Engine spins up unnecessary instances.. We believe that it makes more sense when warmup requests are used only for resident idle instances. -- Takashi On Sat, Jul 14, 2012 at 7:18 AM, Wilson MacGyver wmacgy...@gmail.comwrote: any reason behind this change? this seems kind of strange. I too was wondering by the behavior till you posted this. I had my min set to automatic also On Fri, Jul 13, 2012 at 9:28 AM, Takashi Matsuo tmat...@google.com wrote: Now the warmup requests are fired only if you set min idle instances to some value(not automatic). -- Takashi On Fri, Jul 13, 2012 at 9:52 PM, Michael Hermus michael.her...@gmail.com wrote: Same for me.. I just checked: no calls to warmup, lots of loading requests. **shakes fist at App Engine** On Thursday, July 12, 2012 4:39:48 PM UTC-4, Tom Phillips wrote: Interesting..I checked and I too have 100% of my loading requests on user facing URLs instead of /_ah/warmup. Warmup requests are enabled and Automatic-Automatic for both instance sliders. I used to see at least a decent percentage of loading requests on /_ah/ warmup, but haven't looked in quite a while. /Tom On Jul 12, 3:46 pm, David Hardwick david.hardw...@bettercloud.com wrote: Some additional observations and questions... After reading this [Link 1] stack overflow article that mentioned an issue with having your Max Idle count below 6, we started looking at our warmup request on our staging environment because that app-id has Idle Instances set to Auto-Auto, while production had specific values. But...Where did all the /_ah/warmup requests go? When doing a label search for these staging environment logs [path:/_ah/warmup (doing a label search)] we couldn't find any warmup request!!(yes, we have warmup requests turned on)...we would just see the first cold-start request would take around 15 seconds to load (F1) and 10 seconds to load on (F2). I even shut down every instance and hit the staging server again to see if I could find a warmup request in the logs...nope. Honestly, I would rather have a user wait 10 seconds for the first request to that server as opposed risking the warmup requests failing again. Where did all the /_ah/warmup requests go? More importantly, why would we have such different times for warmup requests compared to cold starts? Shouldn't they be nearly identical?! Rock on, -Hardwick [Link 1] - http://stackoverflow.com/questions/9422698/ah-warmup-producing-hardde... On Jul 12, 12:26 pm, David Hardwick david.hardw...@bettercloud.com wrote: Hello, I realize there's been a lot of discussion on startup times exceeded on this forum recently, but wanted needed to post this experience we had this morning to keep the attention on this important issue. We uploaded a point release of our app to a not-live version this morning and, of course, we were going to click around on that instance to make sure it's all kosher before making that version live. The warm-up requests for the not-live version were exceeding the deadline limit of 60s... __and__we__are__on__F4s__!_!. However, the LIVE version of the app crashed too, 500 server errors, instance counts went to zero, all sorts of whacky stuff was seen in the control panel. All that happened to our LIVE version without when all we did was upload another non-live version and hit it with a single request...did I mention we were on F4s? ;-) Does the failure of any instance to exceed the 60s limit take down all instances to include live one? We did a few things as quickly as possible since our live application was down, so clearly we didn't have the time to take the scientific approach of only changing one thing at a time and wait to see if it that did it. We... 1. Switched from F4s to F2 (i figured if this would least get us on some new servers/instances) 2. Increased max idle instances from 1 to 2 (with F4s running, I'm fine with having just 1 idle instance and not at all happy about paying for 2 idle instances, so maybe we'll just increase this prior to deployments and then back down again after the deployment succeeds until we know more) 3. Made the recently uploaded version live (hey, why not, the production app was down for 10 minutes, so how much more harm could we do?) We use GWT
[google-appengine] Re: Startup time exceeded...on F4?!
Hi Takashi, Now that I've added a resident idle instance, the logs seem to confirm that only the loading of the resident instance is via /_ah/warmup. It's difficult to tell that for sure, but all my current dynamic instances were loaded on a user URL, and the current resident instance was loaded via /_ah/warmup. Resident idle instances are loaded only infrequently, and serve little traffic, so of what use are warmup requests if only they get them? The vast majority of loading requests are now on user URLs. That's a 20+ second wait (Java) by a user on almost every loading request. Back in the Always-on days, I would see virtually all loading requests use /_ah/warmup, as long as traffic was relatively stable. So an instance loading rarely affected an actual user. What do we configure now to get this same behavior? /Tom On Jul 13, 7:07 pm, Takashi Matsuo tmat...@google.com wrote: Hi Mauricio, Yes I understand that, and we've been working on it. Sorry that it's taking long. Hi Wilson, It's coming with the pricing change. Since we started charging with number of instances, we needed to provide more control on how we spin-up a new instances. In other words, if we continued the old behavior, many developers would have complained like App Engine spins up unnecessary instances.. We believe that it makes more sense when warmup requests are used only for resident idle instances. -- Takashi On Sat, Jul 14, 2012 at 7:18 AM, Wilson MacGyver wmacgy...@gmail.comwrote: any reason behind this change? this seems kind of strange. I too was wondering by the behavior till you posted this. I had my min set to automatic also On Fri, Jul 13, 2012 at 9:28 AM, Takashi Matsuo tmat...@google.com wrote: Now the warmup requests are fired only if you set min idle instances to some value(not automatic). -- Takashi On Fri, Jul 13, 2012 at 9:52 PM, Michael Hermus michael.her...@gmail.com wrote: Same for me.. I just checked: no calls to warmup, lots of loading requests. **shakes fist at App Engine** On Thursday, July 12, 2012 4:39:48 PM UTC-4, Tom Phillips wrote: Interesting..I checked and I too have 100% of my loading requests on user facing URLs instead of /_ah/warmup. Warmup requests are enabled and Automatic-Automatic for both instance sliders. I used to see at least a decent percentage of loading requests on /_ah/ warmup, but haven't looked in quite a while. /Tom On Jul 12, 3:46 pm, David Hardwick david.hardw...@bettercloud.com wrote: Some additional observations and questions... After reading this [Link 1] stack overflow article that mentioned an issue with having your Max Idle count below 6, we started looking at our warmup request on our staging environment because that app-id has Idle Instances set to Auto-Auto, while production had specific values. But...Where did all the /_ah/warmup requests go? When doing a label search for these staging environment logs [path:/_ah/warmup (doing a label search)] we couldn't find any warmup request!!(yes, we have warmup requests turned on)...we would just see the first cold-start request would take around 15 seconds to load (F1) and 10 seconds to load on (F2). I even shut down every instance and hit the staging server again to see if I could find a warmup request in the logs...nope. Honestly, I would rather have a user wait 10 seconds for the first request to that server as opposed risking the warmup requests failing again. Where did all the /_ah/warmup requests go? More importantly, why would we have such different times for warmup requests compared to cold starts? Shouldn't they be nearly identical?! Rock on, -Hardwick [Link 1] - http://stackoverflow.com/questions/9422698/ah-warmup-producing-hardde... On Jul 12, 12:26 pm, David Hardwick david.hardw...@bettercloud.com wrote: Hello, I realize there's been a lot of discussion on startup times exceeded on this forum recently, but wanted needed to post this experience we had this morning to keep the attention on this important issue. We uploaded a point release of our app to a not-live version this morning and, of course, we were going to click around on that instance to make sure it's all kosher before making that version live. The warm-up requests for the not-live version were exceeding the deadline limit of 60s... __and__we__are__on__F4s__!_!. However, the LIVE version of the app crashed too, 500 server errors, instance counts went to zero, all sorts of whacky stuff was seen in the control panel. All that happened to our LIVE version without when all we did was upload another non-live version and hit it with a single request...did I mention we were on F4s? ;-) Does the failure of any
[google-appengine] Re: Log Filtering Broken
It is really bad. Anyone looks at logs? On Sunday, July 8, 2012 10:46:34 PM UTC-7, vlad wrote: Has anyone noticed that Filtering in AdminConsole/Logs has been broken for a while? Basically after you enter a filter expression the log does NOT re-paginate results. Thus forcing you to page through bunch of empty pages. Star this issue: http://code.google.com/p/googleappengine/issues/detail?id=7669 -- 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/-/_yg69f5zjXkJ. 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.
