Re: [google-appengine] Re: Datastore Overlays?
https://code.google.com/p/googleappengine/source/browse/trunk/java/src/main/com/google/appengine/api/labs/datastore/overlay On Mon, Oct 5, 2015 at 7:34 AM Patrice (Cloud Platform Support) < pvoutsi...@google.com> wrote: > Hi Aleem, > > Do you mind pointing out where you found that out? Nowhere has there been > any announcement by us about Datastore Overlays, so if it's a new Feature > coming in, what you might see in the code is just a placeholder while we > finish that feature and fully release it. > > Cheers > > > On Monday, October 5, 2015 at 1:37:54 AM UTC-4, Aleem Mawani wrote: >> >> Looking at some relatively recent GAE SDK code, there is mention of >> Datastore Overlays. Anyone know what that is or used it? I >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Google App Engine" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/google-appengine/dg59C1JR1Gw/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > google-appengine+unsubscr...@googlegroups.com. > To post to this group, send email to google-appengine@googlegroups.com. > Visit this group at http://groups.google.com/group/google-appengine. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-appengine/e62528bf-7efb-42d8-9eaa-3310f6e1730f%40googlegroups.com > <https://groups.google.com/d/msgid/google-appengine/e62528bf-7efb-42d8-9eaa-3310f6e1730f%40googlegroups.com?utm_medium=email_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CADBYpy%3D1N3VT5oGqp%3DqyV8ampN0-uDMsBi%2BwTetnzekmLzu%3DXQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Datastore Overlays?
Looking at some relatively recent GAE SDK code, there is mention of Datastore Overlays. Anyone know what that is or used it? I -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/bd1e670a-3b1e-49df-aadf-5ea217f97cc4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: Output location of mvn appengine:devserver_start
How would I go about finding out whether its logged to a fixed file or not? On Thursday, August 20, 2015 at 1:03:39 PM UTC-7, Patrice (Cloud Platform Support) wrote: Hi aloo! Really good question, I have no clue right now and I'm not even sure the server output IS logged. Looking into the options you can't force where it goes, so if it does exist, it'll be a file that never really changes location (maybe check your user data?). A way to get this from a different angle might be to make a Feature Request on the maven app engine plugin issue tracker to have a flag to control the output of the async dev server? https://code.google.com/p/appengine-maven-plugin/issues/list is the URL for the Issue Tracker. Good luck finding this out! Cheers! On Thursday, August 20, 2015 at 12:24:05 PM UTC-4, aloo wrote: I'm using the maven appengine plugin and starting the devserver asynchronously using mvn appengine:devserver_start. If you use the synchronous version mvn appengine:devserverthe server output is printed to the console. However when using devserver_start where is the server output logged to? -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/9d729721-fa2c-4674-bfc0-614b7bf4b29f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [google-appengine] Google Cloud Platform wants to hear from you
On Tue, Apr 28, 2015 at 10:03 PM 'Chris Ramsdale' via Google App Engine google-appengine@googlegroups.com wrote: excellent feedback. some comments inline below. On Thu, Apr 23, 2015 at 3:09 PM, Aleem Mawani al...@streak.com wrote: @chris, thanks for asking, 1) Sorry I might have had some confusion here, I thought traffic splitting/traffic migration didn't work for managed VM's but it in fact it doesn't work for any non-default module. We haven't yet tried to put our default module on managed vms because of stability concerns (may be outdated) and the api's listed below) a fix for this is in the works. i'll come back with a date. thanks! 2) Re: APIs, we can't yet do the following in Managed VM's: - channel api: we use this to send realtime notifications to web/mobile clients have you looked into the Firebase API set? would that work for you or is there some deficiency? Looked into it briefly, but two things concern me: 1) Firebase is designed to synchronize state across several clients and does a great job of this. But you kind of have to shoehorn in message passing. So if your app is already built using the channel api which is more message based, moving to firebase is a little awkward. For a new app this might be less of a problem. I've heard rumblings about firebase + datastore but I'm suspicious that could work well (if every client needs to provide a list of entities it would like to subscribe to, this is non trivial) for us at least. 2) Its far more expensive than channel API since its based on number of connections. We'd blow through their highest tiered plan and likely increase our monthly bills by double digit percentages. If channel API is going away, the natural replacement seems to be GCM if it supported web clients. - logging api: we use this to export our logs to BQ slightly related to my point above, our goal is to enable this via Google Cloud Logging. have you taken a look at their integration with BQ? Its good, but we need to process logs before sending to bigquery. We'd like to implement a Cloud Logginng - PubSub - Dataflow - Bigquery workflow which would remove the need for us to even use GAE insances to get logs to BQ but the Cloud Logging - PubSub is the missing piece that isn't available yet. Neither is the Logging API on Managed VMs so we're left with using vanilla GAE instances to do background log processing. 3) The other things preventing us from moving default module over to managed vms: - cloud console dashboard doesn't show a lot of the aggregate metrics for a managed vm module, most importantly instance count over time. - cloud monitoring can't monitor managed vm instance count good feedback, and i've passed this on to the Cloud monitoring folks. is the plan for cloud monitoring to replace GAE dashboard. Or for the dashboard to show instance counts of managed vms? I.e. where should we get this data? - seemed that instances would go into unhealthy state and not recover or get killed (this could be outdated) there have been several changes submitted to address this issue. please do let me know if you are still seeing this issue. will do. Thanks for all the responses! At the current moment there seems to be no major concerns with managed VM's (except for the things you're working on like startup time and deploy time and dev experience) but there are dozens of tiny gotchas which individually don't seem like much but together are a big enough deal that we don't serve front end traffic over it. For background processing the value is so high that we've moved all of our backend modules to managed vms (unless they need any of the above API's). On Thursday, April 23, 2015 at 2:24:59 PM UTC-7, Chris Ramsdale wrote: yes, the goal is to get App Engine Managed VMs (v2) to a state where they are ideal for frontend serving. couple of questions for you: (1) is traffic splitting and deploy-to-a-default-module not working for you? (2) re: APIs, which ones would you like to see enabled? you mentioned logging (and the goal is to move App Engine Logging API over to Google Cloud Logging all-up), but what else are you looking for? -- Chris On Thu, Apr 23, 2015 at 11:47 AM, Aleem Mawani al...@streak.com wrote: Chris - with the improvements you're suggesting to Managed VMs (20 sec deploys, 1 sec instance startup time) - will it be recommended to use Managed VMs to serve frontend traffic? Right now they seem to be more targetted to backend processing because of the slow scaling. If this is true, and you are targeting it to serve front end traffic, does that mean we'll be able to deploy Managed VMs to our default modules, perform traffic splitting, access the logging api's and realtime api's, etc? These are the things that have been traditionally missing from managed vms. On Wednesday, April 22, 2015 at 10:33:46 AM UTC-7, Chris Ramsdale wrote: On Wed, Apr 22, 2015 at 2:21 AM
Re: [google-appengine] Google Cloud Platform wants to hear from you
During the course of an appengine request, we record a bunch of stats in the logs, such as number/type of datastore operations, profiling info, URLfetch stats, etc. Before the logs can go into BigQuery, we want to extract that info from the logs and place them in particular columns in our BigQuery tables. Currently our GAE instances do this transformation but ideally this transformation would be done in dataflow which would be way more efficient, less code to write, cheaper, more stable and managed! On Wed, Apr 29, 2015 at 12:08 PM Jason Collins jason.a.coll...@gmail.com wrote: we need to process logs before sending to bigquery Aleem, can you tell me more about what processing you do on your logs before sending them to BigQuery? -- You received this message because you are subscribed to a topic in the Google Groups Google App Engine group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/GK_5qVwBIuQ/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/91564e30-0a50-460d-8e7f-680871272c34%40googlegroups.com https://groups.google.com/d/msgid/google-appengine/91564e30-0a50-460d-8e7f-680871272c34%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CADBYpykRkhBFCzQhT3Wj5ap2gpp1DyeiBxObygL1zeWjtdwJ-w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [google-appengine] Google Cloud Platform wants to hear from you
Chris - with the improvements you're suggesting to Managed VMs (20 sec deploys, 1 sec instance startup time) - will it be recommended to use Managed VMs to serve frontend traffic? Right now they seem to be more targetted to backend processing because of the slow scaling. If this is true, and you are targeting it to serve front end traffic, does that mean we'll be able to deploy Managed VMs to our default modules, perform traffic splitting, access the logging api's and realtime api's, etc? These are the things that have been traditionally missing from managed vms. On Wednesday, April 22, 2015 at 10:33:46 AM UTC-7, Chris Ramsdale wrote: On Wed, Apr 22, 2015 at 2:21 AM, troberti tij...@firigames.com javascript: wrote: What a flurry of activity. :) Great to see. I have been using GCP( App Engine + BigQuery) in total for over 5 years, so not new, but I have seen plenty of new users make mistakes so let me chime in a bit: On App Engine (and GCP) there are a lot of ways to approach a problem, with the consequence that is very easy to choose the wrong solution. There is actually a rather steep learning curve to just know what is available. This is a problem, because the differences between various solutions can result in an order of magnitude difference in costs/latency/complexity etc. I stopped counting the amount of times I have seen models with every property indexed, resulting in huge datastore costs. Or where someone tries to put tons of data in the Datastore while BigQuery would be a much better fit for the problem. Every time this happens, the new user ends up disappointed. So guiding new users in the right direction when starting out on GCP seems very important. I agree with a lot in Karl's post, and especially the Roadmap. It doesn't need to be about features, but big ticket items like Python 3, Java 8, SSL etc should be communicated. It doesn't have to be an explicit list somewhere, just a PM chiming in regularly should be good enough. Now back to App Engine: Like I said in my post on the other thread https://cloud.google.com/appengine/forum/?place=msg%2Fgoogle-appengine%2FqTyc2E-0IXc%2FPxUzFMXhzjQJ, the trend towards managed VMs worries me a bit. For us, zero-configuration/no-maintenance is not just another feature of App Engine, it is one of the most important ones! We want to write our programs and then keep them running for years (5+) without having to do *anything*. Some of our apps are running like this for years now, and I want to ensure that this stays possible in the future. Managed VMs represent a new hosting environment that brings with it a set of feature benefits -- open source compatible runtimes, more CPU / memory configurations, access to native resources such as a file system and network stack. we'll be investing in this environment more and more over the coming months (we're ripping docker out of the getting started flow, getting deployment times to 20 secs, getting instance activation time to 1 sec, adding scale to/from zero instances, etc.) that said, don't worry, we'll absolutely keep your existing v1 apps running just as they have for years. Glad to see the Docker fad go, but please don't replace it with something where I need to choose my technology stack in some way. Just provide a set of stable APIs instead so we can consider everything else an implementation detail for App Engine to worry about :) exactly. if anything, we're going to make those same APIs available from other compute environments (e.g. Compute Engine and Container Engine). On Wednesday, April 22, 2015 at 8:31:47 AM UTC+2, Chris Ramsdale wrote: On Tue, Apr 21, 2015 at 11:22 PM, Vinny P vinn...@gmail.com wrote: Hi Katie, I think Karl's post hit a home run and I'm happy to see the positive response to his post. Let me just tack on a few items: *Managed VMs:* The development toolchain for Managed VMs can be a bit finicky. To be quite honest I have no idea how I got Managed VMs working on my laptop. Streamlining this would be a huge benefit to me, and probably a lot of first-timers. If you can convince one of the online IDE services to simplify creating Managed VM GAE apps, that would be super. For smaller or toy apps within Managed VMs: I shouldn't need to care about the Docker container running the application; I should be able to create an application using just Eclipse + Google Plugin, then be able to deploy straight to a Managed VM runtime *without* the intermediate step of having gcloud create and store a dockerfile https://cloud.google.com/appengine/docs/managed-vms/tutorial/step2#dockerfile . We're removing the Docker toolchain from the mix and will be surfacing a hosted build service that handles this on your behalf. Their toolchain is simply unstable. *Firebase:* I'm glad that Google bought up Firebase - they have a lot of great ideas
Re: [google-appengine] Google Cloud Platform wants to hear from you
@chris, thanks for asking, 1) Sorry I might have had some confusion here, I thought traffic splitting/traffic migration didn't work for managed VM's but it in fact it doesn't work for any non-default module. We haven't yet tried to put our default module on managed vms because of stability concerns (may be outdated) and the api's listed below) 2) Re: APIs, we can't yet do the following in Managed VM's: - channel api: we use this to send realtime notifications to web/mobile clients - logging api: we use this to export our logs to BQ 3) The other things preventing us from moving default module over to managed vms: - cloud console dashboard doesn't show a lot of the aggregate metrics for a managed vm module, most importantly instance count over time. - cloud monitoring can't monitor managed vm instance count - seemed that instances would go into unhealthy state and not recover or get killed (this could be outdated) At the current moment there seems to be no major concerns with managed VM's (except for the things you're working on like startup time and deploy time and dev experience) but there are dozens of tiny gotchas which individually don't seem like much but together are a big enough deal that we don't serve front end traffic over it. For background processing the value is so high that we've moved all of our backend modules to managed vms (unless they need any of the above API's). On Thursday, April 23, 2015 at 2:24:59 PM UTC-7, Chris Ramsdale wrote: yes, the goal is to get App Engine Managed VMs (v2) to a state where they are ideal for frontend serving. couple of questions for you: (1) is traffic splitting and deploy-to-a-default-module not working for you? (2) re: APIs, which ones would you like to see enabled? you mentioned logging (and the goal is to move App Engine Logging API over to Google Cloud Logging all-up), but what else are you looking for? -- Chris On Thu, Apr 23, 2015 at 11:47 AM, Aleem Mawani al...@streak.com javascript: wrote: Chris - with the improvements you're suggesting to Managed VMs (20 sec deploys, 1 sec instance startup time) - will it be recommended to use Managed VMs to serve frontend traffic? Right now they seem to be more targetted to backend processing because of the slow scaling. If this is true, and you are targeting it to serve front end traffic, does that mean we'll be able to deploy Managed VMs to our default modules, perform traffic splitting, access the logging api's and realtime api's, etc? These are the things that have been traditionally missing from managed vms. On Wednesday, April 22, 2015 at 10:33:46 AM UTC-7, Chris Ramsdale wrote: On Wed, Apr 22, 2015 at 2:21 AM, troberti tij...@firigames.com wrote: What a flurry of activity. :) Great to see. I have been using GCP( App Engine + BigQuery) in total for over 5 years, so not new, but I have seen plenty of new users make mistakes so let me chime in a bit: On App Engine (and GCP) there are a lot of ways to approach a problem, with the consequence that is very easy to choose the wrong solution. There is actually a rather steep learning curve to just know what is available. This is a problem, because the differences between various solutions can result in an order of magnitude difference in costs/latency/complexity etc. I stopped counting the amount of times I have seen models with every property indexed, resulting in huge datastore costs. Or where someone tries to put tons of data in the Datastore while BigQuery would be a much better fit for the problem. Every time this happens, the new user ends up disappointed. So guiding new users in the right direction when starting out on GCP seems very important. I agree with a lot in Karl's post, and especially the Roadmap. It doesn't need to be about features, but big ticket items like Python 3, Java 8, SSL etc should be communicated. It doesn't have to be an explicit list somewhere, just a PM chiming in regularly should be good enough. Now back to App Engine: Like I said in my post on the other thread https://cloud.google.com/appengine/forum/?place=msg%2Fgoogle-appengine%2FqTyc2E-0IXc%2FPxUzFMXhzjQJ, the trend towards managed VMs worries me a bit. For us, zero-configuration/no-maintenance is not just another feature of App Engine, it is one of the most important ones! We want to write our programs and then keep them running for years (5+) without having to do *anything*. Some of our apps are running like this for years now, and I want to ensure that this stays possible in the future. Managed VMs represent a new hosting environment that brings with it a set of feature benefits -- open source compatible runtimes, more CPU / memory configurations, access to native resources such as a file system and network stack. we'll be investing in this environment more and more over the coming months (we're ripping docker out
Re: [google-appengine] Re: Dev workflow for Modules + Maven
How are you able to run each server independently? I'm having trouble getting maven to just build and run one server. ᐧ On Tue, Apr 22, 2014 at 11:29 AM, Rafael mufumb...@gmail.com wrote: Aleem, I use IntelliJ to run each module separately. I have 4 modules running in different ports. That way I can just press play and it will replace the resources and classes with new ones, or I can just reboot one module at the time. I can also boot only one module if I want. I had to code my own dispatch.xml behavior, since the appengine java sdk doesn't handle that: https://gist.github.com/mufumbo/6325670 (see comments for a more updated version) thanks rafa On Tue, Apr 22, 2014 at 5:10 AM, Gilberto Torrezan Filho gilberto.torre...@gmail.com wrote: Hi, If you're using Eclipse, take a look at this topic: https://groups.google.com/forum/#!topic/google-plugin-eclipse/9K0RkQID740 Maven + app engine modules doesn't work quite well with Eclipse right now, and judging by the volume of messages in the topic above, I don't think we will see any improvement in a near future. While there is a Google I/O coming up, there is hope for a big capital letters announcement: Behold, Servlets 3, Java 8 and better Maven + Modules + Eclipse integration for App Engine!. Do you think local testing is hard the way it is now? Try adding GWT to the mix and you'll end with more white strands of hair in your head... ;-) On Sunday, April 20, 2014 8:27:46 PM UTC-3, aloo wrote: Hi all, I'm curious how others have setup their dev workflow when using appengine modules + maven? In order to run the local dev server I need to rebuild my entire project and then run mvn appengine:devserver in my ear directory. This typically takes a minute for a simple code change. I'm having a hard time iterating during local testing due to this. I'm using the same project structure as the sample modules app here: https://github.com/GoogleCloudPlatform/appengine-modules-sample-java -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups Google App Engine group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/YvE-zXrOEkI/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
Re: [google-appengine] Re: Dev workflow for Modules + Maven
I have a similar POM for each of my modules as your 2nd example, but cd'ing into that directory and running mvn appengine:devserver did not work (failed with an error). Is that how you're running a single module server? On Tue, Apr 22, 2014 at 11:46 AM, Rafael mufumb...@gmail.com wrote: I use the IntelliJ plugin: https://www.dropbox.com/s/yt0nk3paanwtol3/Screenshot%202014-04-22%2011.46.00.png In any case, you can run each module separately with something like this: https://www.dropbox.com/s/6cve0xqticujdzw/Screenshot%202014-04-22%2011.47.00.png On Tue, Apr 22, 2014 at 11:37 AM, Aleem Mawani aleem.maw...@gmail.comwrote: How are you able to run each server independently? I'm having trouble getting maven to just build and run one server. ᐧ On Tue, Apr 22, 2014 at 11:29 AM, Rafael mufumb...@gmail.com wrote: Aleem, I use IntelliJ to run each module separately. I have 4 modules running in different ports. That way I can just press play and it will replace the resources and classes with new ones, or I can just reboot one module at the time. I can also boot only one module if I want. I had to code my own dispatch.xml behavior, since the appengine java sdk doesn't handle that: https://gist.github.com/mufumbo/6325670 (see comments for a more updated version) thanks rafa On Tue, Apr 22, 2014 at 5:10 AM, Gilberto Torrezan Filho gilberto.torre...@gmail.com wrote: Hi, If you're using Eclipse, take a look at this topic: https://groups.google.com/forum/#!topic/google-plugin-eclipse/9K0RkQID740 Maven + app engine modules doesn't work quite well with Eclipse right now, and judging by the volume of messages in the topic above, I don't think we will see any improvement in a near future. While there is a Google I/O coming up, there is hope for a big capital letters announcement: Behold, Servlets 3, Java 8 and better Maven + Modules + Eclipse integration for App Engine!. Do you think local testing is hard the way it is now? Try adding GWT to the mix and you'll end with more white strands of hair in your head... ;-) On Sunday, April 20, 2014 8:27:46 PM UTC-3, aloo wrote: Hi all, I'm curious how others have setup their dev workflow when using appengine modules + maven? In order to run the local dev server I need to rebuild my entire project and then run mvn appengine:devserver in my ear directory. This typically takes a minute for a simple code change. I'm having a hard time iterating during local testing due to this. I'm using the same project structure as the sample modules app here: https://github.com/GoogleCloudPlatform/appengine-modules-sample-java -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups Google App Engine group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/YvE-zXrOEkI/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups Google App Engine group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/YvE-zXrOEkI/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http
Re: [google-appengine] Re: Dev workflow for Modules + Maven
Thanks for the info. I just tried packaging 1 of my modules and it still takes on the order of 1 min. The building of the jar and copying the web app folder is the culprit I suspect. ᐧ On Mon, Apr 21, 2014 at 6:13 PM, AndyD goo...@adennie.e4ward.com wrote: I haven't found the EAR project to be necessary. I work on individual modules separately; I just do a mvn package to build a module's WAR file and then do testing/debugging by running the devserver against that WAR file. I also deploy those module WAR files individually when I need to via mvn appengine:update; I don't deploy the EAR file. -Andy On Sunday, April 20, 2014 7:27:46 PM UTC-4, aloo wrote: I'm curious how others have setup their dev workflow when using appengine modules + maven? In order to run the local dev server I need to rebuild my entire project and then run mvn appengine:devserver in my ear directory. This typically takes a minute for a simple code change. -- You received this message because you are subscribed to a topic in the Google Groups Google App Engine group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/YvE-zXrOEkI/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
Re: [google-appengine] Best Practices for Continuous Deployment on AppEngine
Thanks thats very helpful! ᐧ On Wed, Sep 25, 2013 at 8:19 AM, Jeff Schnitzer j...@infohazard.org wrote: I don't flood it - I just make one fetch to make sure a single instance is up. Our app is very busty and usually has low enough traffic that this prevents any major UX issues. I just wanted to mention it just in case someone does try this with a high-traffic app. Shelling out to 'ab' is pretty simple. This should get a handful of instances off the ground: ab -n 100 -c 10 http://www.example.com/ See http://en.wikipedia.org/wiki/ApacheBench Jeff On Tue, Sep 24, 2013 at 7:14 PM, Aleem Mawani al...@streak.com wrote: On Saturday, August 10, 2013 10:08:01 AM UTC-7, Jeff Schnitzer wrote: We do zero-downtime rolling deployments. Our solution is to deploy to a new version each time (identified by a timestamp), warm up the version, and then switch. If you have a high-traffic app you may need to use something like 'ab' to flood the new version and spin up enough instances. Can you describe the proicess you use to flood the new version with requests? Here's our ant script: https://gist.github.com/**stickfigure/6201192https://gist.github.com/stickfigure/6201192 Unfortunately there's no API to delete old versions, so every couple deploys we have to go into the GAE admin UI and delete several versions by hand. We're in the process of mavenizing this app so this is all going to change again of course... Jeff On Fri, Aug 9, 2013 at 4:44 PM, Nick naok...@gmail.com wrote: We do continuous deployment as well, although not 30 a day. I can't quite remember when there started being issues with 500s being served when deploying an app, but it wasn't always the case. Appengine used to just handle deploying newer code to the same version and start up new instances, shutting down old ones naturally. We basically have two versions, one set to default, and another used for smoke test and to host while we're deploying. We upload new code to the smoke testing environment, smoke test, then switch it to default. Then we deploy to the other version and flip it back to default. Occasionally the behaviour doing this changes (for a while the old instances on the old version didn't shutdown, and had to be done manually), but that's the nature of appengine. Issue to star if you're interested (this affects everyone, any deployment will currently cause downtime to consumers for a small window - 2 seconds to a couple of minutes, there will be no indication of this in your logs at all): http://code.google.com/p/**googleappengine/issues/detail?** id=7874q=Deploycolspec=ID%**20Type%20Component%20Status%** 20Stars%20Summary%20Language%**20Priority%20Owner%20Loghttp://code.google.com/p/googleappengine/issues/detail?id=7874q=Deploycolspec=ID%20Type%20Component%20Status%20Stars%20Summary%20Language%20Priority%20Owner%20Log -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@**googlegroups.com. To post to this group, send email to google-a...@googlegroups.**com. Visit this group at http://groups.google.com/**group/google-appenginehttp://groups.google.com/group/google-appengine . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to a topic in the Google Groups Google App Engine group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/Q9v_0bqm9ZI/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] Best Practices for Continuous Deployment on AppEngine
Rafael - what parameters do you use with ab? I.e. how many requests and how many concurrent? I'm doing this from my local box and my connection keeps getting reset by peer. I suspect this is some DoS protection ᐧ On Wed, Sep 25, 2013 at 12:06 PM, Rafael mufumb...@gmail.com wrote: For the continuous deployment, we use maven EAR to run all together in scripting. We run everything in our local servers, so we don't need to be warming up instances. We had to code our own dispatch.xml handler in order to be able to develop locally in a multi module setup. Since appengine doesn't support that in local. I have to do the AB trick every single time as well. With the same parameters :) It would be so easy for the appengine team to put a warmup XX instances whenever releasing a new version. Although, they're probably busy enabling a new language support rather than making existing customers happy :) thanks rafa On Wed, Sep 25, 2013 at 8:19 AM, Jeff Schnitzer j...@infohazard.orgwrote: I don't flood it - I just make one fetch to make sure a single instance is up. Our app is very busty and usually has low enough traffic that this prevents any major UX issues. I just wanted to mention it just in case someone does try this with a high-traffic app. Shelling out to 'ab' is pretty simple. This should get a handful of instances off the ground: ab -n 100 -c 10 http://www.example.com/ See http://en.wikipedia.org/wiki/ApacheBench Jeff On Tue, Sep 24, 2013 at 7:14 PM, Aleem Mawani al...@streak.com wrote: On Saturday, August 10, 2013 10:08:01 AM UTC-7, Jeff Schnitzer wrote: We do zero-downtime rolling deployments. Our solution is to deploy to a new version each time (identified by a timestamp), warm up the version, and then switch. If you have a high-traffic app you may need to use something like 'ab' to flood the new version and spin up enough instances. Can you describe the proicess you use to flood the new version with requests? Here's our ant script: https://gist.github.com/**stickfigure/6201192https://gist.github.com/stickfigure/6201192 Unfortunately there's no API to delete old versions, so every couple deploys we have to go into the GAE admin UI and delete several versions by hand. We're in the process of mavenizing this app so this is all going to change again of course... Jeff On Fri, Aug 9, 2013 at 4:44 PM, Nick naok...@gmail.com wrote: We do continuous deployment as well, although not 30 a day. I can't quite remember when there started being issues with 500s being served when deploying an app, but it wasn't always the case. Appengine used to just handle deploying newer code to the same version and start up new instances, shutting down old ones naturally. We basically have two versions, one set to default, and another used for smoke test and to host while we're deploying. We upload new code to the smoke testing environment, smoke test, then switch it to default. Then we deploy to the other version and flip it back to default. Occasionally the behaviour doing this changes (for a while the old instances on the old version didn't shutdown, and had to be done manually), but that's the nature of appengine. Issue to star if you're interested (this affects everyone, any deployment will currently cause downtime to consumers for a small window - 2 seconds to a couple of minutes, there will be no indication of this in your logs at all): http://code.google.com/p/**googleappengine/issues/detail?** id=7874q=Deploycolspec=ID%**20Type%20Component%20Status%** 20Stars%20Summary%20Language%**20Priority%20Owner%20Loghttp://code.google.com/p/googleappengine/issues/detail?id=7874q=Deploycolspec=ID%20Type%20Component%20Status%20Stars%20Summary%20Language%20Priority%20Owner%20Log -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@**googlegroups.com. To post to this group, send email to google-a...@googlegroups.**com. Visit this group at http://groups.google.com/**group/google-appenginehttp://groups.google.com/group/google-appengine . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email
Re: [google-appengine] Best Practices for Continuous Deployment on AppEngine
On Saturday, August 10, 2013 10:08:01 AM UTC-7, Jeff Schnitzer wrote: We do zero-downtime rolling deployments. Our solution is to deploy to a new version each time (identified by a timestamp), warm up the version, and then switch. If you have a high-traffic app you may need to use something like 'ab' to flood the new version and spin up enough instances. Can you describe the proicess you use to flood the new version with requests? Here's our ant script: https://gist.github.com/stickfigure/6201192 Unfortunately there's no API to delete old versions, so every couple deploys we have to go into the GAE admin UI and delete several versions by hand. We're in the process of mavenizing this app so this is all going to change again of course... Jeff On Fri, Aug 9, 2013 at 4:44 PM, Nick naok...@gmail.com javascript:wrote: We do continuous deployment as well, although not 30 a day. I can't quite remember when there started being issues with 500s being served when deploying an app, but it wasn't always the case. Appengine used to just handle deploying newer code to the same version and start up new instances, shutting down old ones naturally. We basically have two versions, one set to default, and another used for smoke test and to host while we're deploying. We upload new code to the smoke testing environment, smoke test, then switch it to default. Then we deploy to the other version and flip it back to default. Occasionally the behaviour doing this changes (for a while the old instances on the old version didn't shutdown, and had to be done manually), but that's the nature of appengine. Issue to star if you're interested (this affects everyone, any deployment will currently cause downtime to consumers for a small window - 2 seconds to a couple of minutes, there will be no indication of this in your logs at all): http://code.google.com/p/googleappengine/issues/detail?id=7874q=Deploycolspec=ID%20Type%20Component%20Status%20Stars%20Summary%20Language%20Priority%20Owner%20Log -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com javascript:. To post to this group, send email to google-a...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
[google-appengine] Premier support down?
I noticed that this URL no longer seems to work: https://enterprise.google.com/supportcenter/managecases/ -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
Re: [google-appengine] Emails sent by Appengine Java marked as SPAM in GMAIL
Yup the same content is getting through when using the appspotmail address. It seems that just the from address/domain is what causing the issue. If this can't be solved, is there any way to alias mailfoogae to streak so that I can send emails as notificati...@streak.appspotmail.com? On Fri, Jan 13, 2012 at 10:45 AM, Ikai Lan (Google) ika...@google.comwrote: Thanks for replying. I don't have an answer for this, and it really sucks to get flagged as a false positive if you aren't sending spam. My suggestion is to try some other addresses, given that the email went through via the @appspotmail address, it was likely not the content that got it flagged as spam. Sometimes, if the pattern of the email address looks like something a spammer will use, it may trigger Gmail's (quite excellent) spam protection. -- Ikai Lan Developer Programs Engineer, Google App Engine plus.ikailan.com | twitter.com/ikai On Fri, Jan 13, 2012 at 10:40 AM, aloo aleem.maw...@gmail.com wrote: notificati...@streak.com -- 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/-/wl2fPe6nfyQJ. 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. -- 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: Querying for N random records on Appengine datastore
I'm not sure the ID's are guranteed continous nor do they start at some starting point (0 or 1). Assigning my own id's seems to turn into a more difficult problem of creating an IdGenerator. - Aleem On Fri, Jul 10, 2009 at 3:32 PM, Julian Namaro namarojul...@gmail.comwrote: You should try to generate a list of N random keys for your entity because you can fetch that with only one datastore call(and no index). Aren't google-generated numeric IDs guaranted continuous? If not you can yourself assign alphanumeric keys that are continuous (or generated by a formula that you pass on to the random generator). Julian On Jul 10, 1:33 am, aloo aleem.maw...@gmail.com wrote: Hi all, I'm trying to write a GQL query that returns N random records of a specific kind. My current implementation works but requires N calls to the datastore. I'd like to make it 1 call to the datastore if possible. I currently assign a random number to every kind that I put into the datastore. When I query for a random record I generate another random number and query for records rand ORDER BY asc LIMIT 1. This works, however, it only returns 1 record so I need to do N queries. Any ideas on how to make this one query? Thanks. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
