[google-appengine] Upload time doubled

[Kyle Baley]

We have a nightly build process that deploys our GWT app to a staging
version on AppEngine. Sometime between 2am July 27 and 2am July 28
(Central time), something changed to seriously increase the time it
takes to upload the application. Prior to that, the deploy would take
about 15 minutes. Since then, it has consistently taken over 40
minutes.

Here is an excerpt from our build log on July 27:

[02:07:20]:  [java] 40% Uploading 467 files.
[02:08:54]:  [java] 52% Uploaded 116 files.
[02:10:27]:  [java] 61% Uploaded 232 files.
[02:12:03]:  [java] 68% Uploaded 348 files.
[02:13:27]:  [java] 73% Uploaded 464 files.


And the corresponding lines on July 28:

[02:08:20]:  [java] 40% Uploading 470 files.
[02:19:01]:  [java] 52% Uploaded 117 files.
[02:29:39]:  [java] 61% Uploaded 234 files.
[02:39:59]:  [java] 68% Uploaded 351 files.
[02:50:16]:  [java] 73% Uploaded 468 files.

I've looked through the checkins for July 27 and the only changes were
to .java, .css, and .ui.xml files. Would anything on the AppEngine
side of things cause a drastic increase in the upload time or is it an
issue with the network connection on the server? Note that we also
have a QA build that's launched manually. It's shown similar increases
in deploy time.

We are using AppEngine 1.3.2.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appeng...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Versioning applications/entities

[Kyle Baley]

We've just released the first version of our application and are now
looking at a problem we've been avoiding until now. Namely, what is
the best way to upgrade the application to a new version that requires
changes to the datastore. We're looking at two options:

1) Big Bang Upgrade
We take the application down and run an upgrade process to update all
entities from version 1 to version 2.

Pros: Easy to maintain; intuitive
Cons: App has to be taken down for a period of time, which will
increase as time passes and more data is added to the datastore
(potentially hitting the limit for long-running processes eventually)
Question: What's a good way to take the app offline?

2) Version Entities Individually
Each entity has a version number and we have a series of commands,
each one responsible for upgrading an entity from one version to the
next. As we request entities, we check to see if it's the latest
version. If not, we run each necessary upgrade command in sequence
until it is the latest version.

Pros: No need to take the app offline; provides flexibility on whether
to upgrade everything at once or piecemeal
Cons: Not as intuitive; entities with different versions in the
datastore (if that matters)

What do other people do to upgrade their datastore for a live
application?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appeng...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Versioning applications/entities

[Kyle Baley]

Here's one extreme example. In the original data model, the password
isn't encrypted. In the new one, it is.

On Sep 22, 4:41 am, Tim Hoffman  wrote:
> Why can't you push the version 2, start updating the data
> but still keep running version 1 until the data update has finished.
>
> That I believe is the normal recommended approach.
>
> Is there something about your new version 2 data model that will break
> version 1 ?
>
> T
>
> On Sep 21, 2:29 am, Kyle Baley  wrote:
>
>
>
> > We've just released the first version of our application and are now
> > looking at a problem we've been avoiding until now. Namely, what is
> > the best way to upgrade the application to a new version that requires
> > changes to the datastore. We're looking at two options:
>
> > 1) Big Bang Upgrade
> > We take the application down and run an upgrade process to update all
> > entities from version 1 to version 2.
>
> > Pros: Easy to maintain; intuitive
> > Cons: App has to be taken down for a period of time, which will
> > increase as time passes and more data is added to the datastore
> > (potentially hitting the limit for long-running processes eventually)
> > Question: What's a good way to take the app offline?
>
> > 2) Version Entities Individually
> > Each entity has a version number and we have a series of commands,
> > each one responsible for upgrading an entity from one version to the
> > next. As we request entities, we check to see if it's the latest
> > version. If not, we run each necessary upgrade command in sequence
> > until it is the latest version.
>
> > Pros: No need to take the app offline; provides flexibility on whether
> > to upgrade everything at once or piecemeal
> > Cons: Not as intuitive; entities with different versions in the
> > datastore (if that matters)
>
> > What do other people do to upgrade their datastore for a live
> > application?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appeng...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Versioning applications/entities

[Kyle Baley]

That's an interesting idea. But if you do that, wouldn't you need to
first copy all the data from the v1 namespace to the v2 namespace?

On Sep 22, 7:07 pm, Eli Jones  wrote:
> It might be useful for you to use a namespace for the new version of the
> datastore.
>
> Thus, you could have the "new version" of the app deployed as a non-live
> version of the app.. and code that "new version" to use the "new version
> datastore" namespace.
>
> Then, when you are ready.. just change the live version of your app to the
> "new version".
>
> Here's a link:
>
> http://code.google.com/appengine/docs/python/multitenancy/multitenanc...
>
> <http://code.google.com/appengine/docs/python/multitenancy/multitenanc...>So..
> you could just think of your version 1 datastore as "that old customer who
> we're going to dump just as soon as our new version 2 datastore customer is
> ready"... or something like that.
>
> It's better (I think) than adding a "version" property to all of your models
> or trying to maintain model consistency between app versions.
>
>
>
> On Mon, Sep 20, 2010 at 2:29 PM, Kyle Baley  wrote:
> > We've just released the first version of our application and are now
> > looking at a problem we've been avoiding until now. Namely, what is
> > the best way to upgrade the application to a new version that requires
> > changes to the datastore. We're looking at two options:
>
> > 1) Big Bang Upgrade
> > We take the application down and run an upgrade process to update all
> > entities from version 1 to version 2.
>
> > Pros: Easy to maintain; intuitive
> > Cons: App has to be taken down for a period of time, which will
> > increase as time passes and more data is added to the datastore
> > (potentially hitting the limit for long-running processes eventually)
> > Question: What's a good way to take the app offline?
>
> > 2) Version Entities Individually
> > Each entity has a version number and we have a series of commands,
> > each one responsible for upgrading an entity from one version to the
> > next. As we request entities, we check to see if it's the latest
> > version. If not, we run each necessary upgrade command in sequence
> > until it is the latest version.
>
> > Pros: No need to take the app offline; provides flexibility on whether
> > to upgrade everything at once or piecemeal
> > Cons: Not as intuitive; entities with different versions in the
> > datastore (if that matters)
>
> > What do other people do to upgrade their datastore for a live
> > application?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google App Engine" group.
> > To post to this group, send email to google-appeng...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-appengine+unsubscr...@googlegroups.com > e...@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-appeng...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] remote_api not allowed

[Kyle Baley]

I'm trying to test a backup restore from one app to another and I'm
getting an error trying to access remote_api on one of them. Here's
the first part of the log message I get when I navigate to remote_api
directly:

/remote_api
java.lang.IllegalArgumentException: The requested URL was not
allowed: /remote_api
at
com.google.appengine.api.users.UserServiceImpl.makeSyncCall(UserServiceImpl.java:
131)
at
com.google.appengine.api.users.UserServiceImpl.createLoginURL(UserServiceImpl.java:
62)
at
com.google.appengine.api.users.UserServiceImpl.createLoginURL(UserServiceImpl.java:
42)
at
com.google.apphosting.utils.remoteapi.RemoteApiServlet.checkIsAdmin(RemoteApiServlet.java:
70)
at
com.google.apphosting.utils.remoteapi.RemoteApiServlet.doGet(RemoteApiServlet.java:
96)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)


Authentication mode is set to Google Apps and we have forced SSL. I've
tried this on other apps with the same configuration successfully. Not
sure why this one is throwing this error.

Any ideas?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appeng...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Versioning applications/entities

[Kyle Baley]

Eli,

I can see a benefit to this approach but isn't there a chance some
data would be missed? If customers are using the app while you're
testing the new version, wouldn't you need to re-import the data from
version 1 and convert it again while the app is down?

On Sep 23, 11:27 am, Eli Jones  wrote:
> Yes, you'll need to duplicate your data.
>
> This is the cleanest way to do this.. in my mind.  You would have
> two separate versions of your app.. and you could easily switch back to your
> old version of you realized some horrible mistake was made after switching
> to the new version.
>
> The main work you would need to do for the changeover from Old Version to
> New Version would be:
>
> 1.  Write code that converts old datastore data to the New Version namespace
> data.
> 2.  Test New Version datastore with converted data on New App version.
> 3.  Schedule a downtime late at night where the app is brought offline (just
> upload a dummy app.yaml for the Old Version that points /.* to some message
> page.. or you could be official and have a "Maintenance Period" version of
> your app that you make live.. so that you make no changes whatsoever to the
> "Old Version".), and the datastore conversion code is run after you are
> comfortable that no users are using the site and are all viewing the
> "maintenance period" messages.
> 4.  Once complete, make New Version app the live version.
>
> To me, it seems like a massive headache to try to convert the data in
> place.. in the same datastore.. you have to have new model names or at least
> some new property for "version" on your models.. and then your key_names
> have to be different.. etc..  If you screw something up, that's a potential
> headache for your live app..  with the New Version namespace.. you can
> freely move ahead with experimenting with your coding.. and even make plenty
> of changes to your models (if you think they are beneficial) without
> thinking "I don't know.. it's going to be a pain in the ass to figure out
> how to keep track of the old version and new version entities and now I have
> to add a new model or property definition to my schema code.."
>
> With a namespace, you just have to add the correct mapping, conversion code
> to your datastore converter code, and make schema changes to your New
> Version app code.. and just leave the Old Version datastore and code alone.
>
> You can also get fancy with your converter.. (depending on how the
> conversion actually works) and you can have your converter code get a cursor
> with keys_only for each model, serialize that cursor and pass it off to a
> task that then iterates through the cursor and breaks up the keys into
> batches to be converted and fires off tasks to do the batches in parallel.
>  And, to make the process simpler, you could just used the deferred api..
> (so you don't have to deal with setting up task handler urls or anything
> like that).
>
> However big your datastore is.. and however much money it might cost to have
> your data duplicated (it costs $0.01 a day for 2 GB of data above the free
> limit).. I think it would be worth it.. it would be valuable to learn to do
> it this way, since a large scale site would (or should) do something more
> like this.
>
>
>
> On Wed, Sep 22, 2010 at 9:39 PM, Kyle Baley  wrote:
> > That's an interesting idea. But if you do that, wouldn't you need to
> > first copy all the data from the v1 namespace to the v2 namespace?
>
> > On Sep 22, 7:07 pm, Eli Jones  wrote:
> > > It might be useful for you to use a namespace for the new version of the
> > > datastore.
>
> > > Thus, you could have the "new version" of the app deployed as a non-live
> > > version of the app.. and code that "new version" to use the "new version
> > > datastore" namespace.
>
> > > Then, when you are ready.. just change the live version of your app to
> > the
> > > "new version".
>
> > > Here's a link:
>
> > >http://code.google.com/appengine/docs/python/multitenancy/multitenanc...
>
> > > <http://code.google.com/appengine/docs/python/multitenancy/multitenanc..
> > .>So..
> > > you could just think of your version 1 datastore as "that old customer
> > who
> > > we're going to dump just as soon as our new version 2 datastore customer
> > is
> > > ready"... or something like that.
>
> > > It's better (I think) than adding a "version" property to all of your
> > models
> > > or trying to maintain model consistency between app ve

[google-appengine] Re: Versioning applications/entities

[Kyle Baley]

I asked Fred Sauer at Google and his advice sounded like what Robert,
and possibly John if I understand it correctly, describe:

-
The best practice is to deploy a version of your app which understand
the old model, but which on update/insert creates the new model. For
minor changes (like a new property), you can just keep running this
way. For bigger changes, or if you want to clean up, use the Mapper
API (or your own task queues) to migrate all existing entities. Once
migrated, you can remove the support for the old data structure from
the app.


Advantages I can see to this approach:
- No downtime
- Data store doesn't contain various versions of entities. There are
only two versions: old and new. And the old ones will get cleaned up
in short order.

Disadvantage is that you need to support two models for a time and you
need to re-deploy to remove support for the old version. Doesn't seem
too big a deal since I doubt we'd deploy specifically for this
purpose. More likely, we'd bundle it with another deployment.



On Sep 27, 11:16 pm, Robert Kluin  wrote:
> I have several apps with complex models and relationships.  Personally
> I have found using a version property on my models has made most of my
> upgrades and schema changes fairly straight forward.  Although it does
> sometimes take an interim version of the code capable of handling both
> versions; or, possibly that sets the "version" explicitly on a put()
> so that it can be upgraded later.
>
> In some cases I simply leave a version of the 'old' and 'new' logic in
> place.  When dealing with new data I use the new logic; when dealing
> with existing data I use the version of the logic corresponding to the
> entity or set of entities I am dealing with.  Of course the structure
> of my code itself facilitates this method, but it has proven very easy
> to make even significant schema changes.  Basically I push the interim
> version then kick off my upgrade handlers.  Works really well if you
> do not want much, if any, downtime.  YMMV.
>
> I like the idea of using namespaces to version the data too.  But
> figuring out how to either keep stuff in sync or going offline for a
> full conversion could be tricky.  I suppose you could add some type of
> change indicator that gets set on _all_ of your models, then increment
> it each time you run a conversion.  That would let you identify what
> has changed since your last run... possibly minimizing downtime?
>
> Robert
>
>
>
> On Mon, Sep 27, 2010 at 22:56, Eli Jones  wrote:
> > Yes, when you did the official switch to put the new version of your app
> > live for your customers.. you would need to take the app down and re-convert
> > all the datastore data.
> > Now, you could put a lot of time and energy figuring out a synchronization
> > process.. but it seems like that would take a lot of extra coding.
> > You'd have to have some process to compare the old datastore entities to the
> > new datastore entities (either some sort of "datemodified" property or
> > entity checksum.. or some sort of prop by prop comparison) and really..
> > seems like that would take more resources than just doing a straight
> > re-conversion.
> > I suppose if the re-conversion took hours and hours.. and cost a lot of
> > money.. it might make sense.  But then.. you'd have to figure.. would the
> > re-conversion cost more money (and customer time) than the price of your
> > time (and saved customer time) to code up a iterative sync process?
> > Trying to straddle two databases (one for an old version of code.. and one
> > for a new version of code) that stays synchronized can get pretty mind
> > bending.  But, that all depends on the complexity of your datastore..
> > So, synchronization is sort of a catch 22.
> > If your datastore is so big and complex that synchronization takes less time
> > than total re-conversion, the time to code out a sync process might be
> > prohibitive.
> > If your datastore is so simple that coding a synchronization process is
> > easy, then re-conversion probably wouldn't take much time to run..
> > But, this is just a guess on my part.. I don't know what your datastore
> > changes are going to look like.
>
> > On Mon, Sep 27, 2010 at 9:37 PM, Kyle Baley  wrote:
>
> >> Eli,
>
> >> I can see a benefit to this approach but isn't there a chance some
> >> data would be missed? If customers are using the app while you're
> >> testing the new version, wouldn't you need to re-import the data from
> >> version 1 and convert it again while the app is down?
>
> >> On Sep 23, 11:27 am, Eli Jones  wrote:

[google-appengine] Migration tool reversibility

[Kyle Baley]

I tried the datastore migration tool today from one test environment to 
another and it went through smoothly. But it doesn't appear it can be done 
more than once. I was hoping to test it out a few times before doing it in 
our production environment. But two things lead me to believe it's not 
possible:

1) It creates an alias from the old app ID to the new one and I don't see 
any way of reversing this
2) When you go to the migration tool after it's done, it shows the results 
from the previous migration but no way to restart it.

Assuming it can be done only once, I don't feel comfortable enough to use 
it. If something goes wrong during the migration (like, for instance, we 
miss something in testing that doesn't show up until after we migrate), 
we'd like an easy way to go back to the old app and continue on with it 
until the issue has been resolved.

What that in mind, has anyone tried the Copy Data to Another Application 
feature in the Datastore Admin console? Does that do the same thing as the 
migration tool (at least from a data perspective)?

-- 
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/-/6mgN7qV7UF4J.
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] Channel API billing when channel expires

[Kyle Baley]

When a channel expires, does the new one that gets created count toward 
your billing? For example, if someone opens the app and leaves the browser 
open for 24 hours, is that 12 open channels or 1?

-- 
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/-/8Ldzhuav88QJ.
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: Error code 202

[Kyle Baley]

We've been getting these errors since Feb. 13. We did a deployment on that 
day and I've been tracing through the code trying to see if there's 
something in there that would cause this to no avail.

Our app is technically HR but we don't have any data in it. The app makes 
API calls to another AppEngine app mostly via URLFetch. 

That said, the errors occur almost exclusively on static files. Here's a 
sample:


   1.  2012-03-10 11:42:06.052 /images/separator2.gif 500 124544ms 0kb 
Mozilla/5.0 
   (X11; CrOS i686 1412.205.0) AppleWebKit/535.11 (KHTML, like Gecko) 
   Chrome/17.0.963.60 Safari/535.11 
   
   166.248.1.87 - - [10/Mar/2012:08:42:06 -0800] "GET /images/separator2.gif 
HTTP/1.1" 500 0 "http://www.bookedin.net/multimedia-solutions-llc"; "Mozilla/5.0 
(X11; CrOS i686 1412.205.0) AppleWebKit/535.11 (KHTML, like Gecko) 
Chrome/17.0.963.60 Safari/535.11" "www.bookedin.net" ms=124544 cpu_ms=0 
api_cpu_ms=0 cpm_usd=0.58 exit_code=202 instance=
   
2.  W 2012-03-10 11:42:06.051  
   
   A problem was encountered with the process that handled this request, 
causing it to exit. This is likely to cause a new process to be used for the 
next request to your application. (Error code 202)
   


A request to that same image two minutes earlier (on the same instance) 
returned a 200. AppEngine ID is gunton-prod.

We're using Java. All requests are filtered through a servlet module via 
Guice but we let requests for static files pass through. Nothing in our 
configuration changed in the deployment we did. We're getting the problem 
daily though intermittently. 25 - 30 failures today out of over 1000 
requests for these images. 

The other AppEngine app we have is also HR and Java. It's by far the more 
heavily used one. Haven't seen any issues with it.

Happy to provide more details if you want to contact me.

On Wednesday, March 7, 2012 4:19:15 AM UTC-5, tarun2000 wrote:
>
>
> I keep getting:  A problem was encountered with the process that handled 
> this request, causing it to exit. This is likely to cause a new process to 
> be used for the next request to your application. (Error code 202)
>
> It seems like the issue happens right after uploading a new version or on 
> cold start.  It seems to disappear after a while.  The rpcs that fail may 
> be returning a lot of data.  Any idea what's wrong?
>

-- 
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/-/oAUFHHPFJXUJ.
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] Compile an app with datastore callbacks through ANT

[Kyle Baley]

We've just introduced datastore callbacks into our app and they work fine 
in Eclipse but I can't figure out how to compile the app with them in Ant. 
This is my target:













The error I get is:
[javac] Caused by: java.io.FileNotFoundException: Resource does not 
exist : CLASS_OUTPUT//META-INF\datastorecallbacks.xml
[javac] at 
org.eclipse.jdt.internal.compiler.apt.dispatch.BatchFilerImpl.getResource(BatchFilerImpl.java:158)

NOTE: We're using the eclipse internal compiler through ant because our app 
makes use of a feature that requires some later version of Java. But we ran 
into this 
issuewith
 the timezone and the indicated fix *really* messed up our UI tests. 
(It's a scheduling application so mucking with the timezone introduced some 
weird test failures.)

-- 
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/-/UpWgUFfEH8oJ.
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] Switch domains for Google Apps authentication

[Kyle Baley]

We're using Google Apps as the authentication mechanism for one of our 
apps. I know we can't switch authentication methods but can I switch the 
domain that it's tied to? We're able to add users to it from the new domain 
and log in to the AppEngine console but we have trouble accessing URLs that 
require admin rights. In these cases, we are redirected to a 
domain-specific login page (e.g. http://www.google.com/a/olddomain.com). 
Changing the URL manually to the new URL doesn't work.

-- 
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/-/G_6kUEfCbeUJ.
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: codereview is dead

[Kyle Baley]

We're getting the same error. We have it installed for three domains (via 
Google Marketplace) and all three are failing.

On Monday, May 14, 2012 4:48:24 AM UTC-4, Ian Marshall wrote:
>
> Have you examined the logs for {mydomain}? 
>
>
> On May 14, 4:45 am, Maksym Novozhylov  wrote: 
> > and is dead again..., hope this will have gone soon 
> > 
> > Am Montag, 14. Mai 2012 06:41:24 UTC+3 schrieb Maksym Novozhylov: 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > I meant codereview.{mydomain} 
> > > Not sure if smb. from admins has already seen this post, but all 
> started 
> > > to work well two ci. 3-4 mimutes ago. 
> > 
> > > Am Montag, 14. Mai 2012 06:36:21 UTC+3 schrieb Amy Unruh: 
> > 
> > >> hi, 
> > 
> > >> If you mean: 
> > >>  http://codereview.appspot.com/, 
> > >> it seems to be loading fine.  Is there a particular URL that 
> triggered 
> > >> this error? 
> > 
> > >> On 14 May 2012 13:28, Maksym Novozhylov  
> wrote: 
> > 
> > >>> please fix codereview, which now returns: 
> > 
> > >>> Error: Server Error The server encountered an error and could not 
> > >>> complete your request. 
> > 
> > >>> If the problem persists, please report<
> http://code.google.com/appengine/community.html> your 
> > >>> problem and mention this error message and the query that caused it. 
> > 
> > >>> -- 
> > >>> 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/-/6QB7G-1KZ6oJ. 
> > >>> 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 view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/2QCaRpAj7YwJ.
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] Should i migrate from DataStores to Cloud SQL ?

[Kyle Baley]

I see it as a move to get into the corporate world where they can be 
skittish about non-SQL databases. We're planning to use Cloud SQL as a 
reporting source, not for the day-to-day operations (i.e. CloudSQL for 
OLAP, datastore for OLTP). And if someone is building a tool to copy data 
from datastore to CloudSQL, hit me up.

On Monday, May 14, 2012 6:26:33 AM UTC-4, barryhunter wrote:
>
> if you have to ask - doubt you have any reason to switch.
>
> realisticly you would really only switch if you need specific features 
> offered by sql not available via the datastore.
>
> in general cloud sql will not be as scalable as the datastore. its not a 
> replacement, but to just fill a requirement for some things not possible 
> with the datastore.
> On May 14, 2012 7:19 AM, "Prakhil Samar"  wrote:
>
>> Hi GAE Experts,
>>
>> Need your help !
>>
>> I have a large application build on Datastores using Python, As Google 
>> has introduced Cloud SQL support too.
>>
>> So, should i switch from DataStores to Cloud SQL ?
>> Will Cloud SQL be a value add on to my application?
>> Is performance of Cloud SQL better than DataStores?
>> Will it be big effort to migrate the complete application code and its 
>> data from DataStores to Cloud SQL?
>>
>> Please help me out taking the decision either to switch to Cloud SQL or 
>> stick to the DataStores... 
>>
>>
>>
>>
>>  -- 
>> 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/-/lUpp5yLWkGAJ.
>> 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 view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/txuESAT2NDIJ.
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] URLFetch errors

[Kyle Baley]

About 1:30 EDT today, we started getting URLFetch errors on one of our 
apps. The app makes URLFetch calls to another of our apps.

We haven't done a deployment to either app in a few weeks and all seemed to 
be working this morning. I've tried hitting the offending URLs manually and 
they work fine. From what I can tell, the calls aren't reaching the 
destination because I don't see corresponding requests in its logs.

Have tried shutting down all instances on both apps to no avail.

Here's a partial stack trace:

java.io.IOException: Could not fetch URL: 
http://scheduler.bookedin.net/api/v1/countries
at 
com.google.appengine.api.urlfetch.URLFetchServiceImpl.convertApplicationException(URLFetchServiceImpl.java:115)
at 
com.google.appengine.api.urlfetch.URLFetchServiceImpl.fetch(URLFetchServiceImpl.java:42)
at 
net.bookedin.gunton.server.config.FetchServiceUrlFetch$ApiHandler.getResponse(FetchServiceUrlFetch.java:194)

-- 
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/-/9u3mDaGvDuIJ.
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] URLFetch errors

[Kyle Baley]

That is indeed our problem. Thanks for the quick reply.

On Monday, September 10, 2012 3:10:55 PM UTC-4, barryhunter wrote:
>
> bookedin.net is using GoDaddy for DNS. 
>
> GoDaddy DNS is down. 
>
> Apprently Anonymous did it, but that's unclear at this point. 
>
>
> This is not a Google issue :) You probably have DNS cached locally on 
> your machine. 
>
>
> On Mon, Sep 10, 2012 at 7:57 PM, Kyle Baley > 
> wrote: 
> > 
> > About 1:30 EDT today, we started getting URLFetch errors on one of our 
> apps. The app makes URLFetch calls to another of our apps. 
> > 
> > We haven't done a deployment to either app in a few weeks and all seemed 
> to be working this morning. I've tried hitting the offending URLs manually 
> and they work fine. From what I can tell, the calls aren't reaching the 
> destination because I don't see corresponding requests in its logs. 
> > 
> > Have tried shutting down all instances on both apps to no avail. 
> > 
> > Here's a partial stack trace: 
> > 
> > java.io.IOException: Could not fetch URL: 
> http://scheduler.bookedin.net/api/v1/countries 
> > at 
> com.google.appengine.api.urlfetch.URLFetchServiceImpl.convertApplicationException(URLFetchServiceImpl.java:115)
>  
>
> > at 
> com.google.appengine.api.urlfetch.URLFetchServiceImpl.fetch(URLFetchServiceImpl.java:42)
>  
>
> > at 
> net.bookedin.gunton.server.config.FetchServiceUrlFetch$ApiHandler.getResponse(FetchServiceUrlFetch.java:194)
>  
>
> > 
> > -- 
> > 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/-/9u3mDaGvDuIJ. 
> > To post to this group, send email to 
> > google-a...@googlegroups.com. 
>
> > To unsubscribe from this group, send email to 
> google-appengi...@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 view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/vvynxfw4mVYJ.
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] Latency problems

[Kyle Baley]

We've been having severe latency issues for about an hour now. Haven't made 
any changes to our system for some time. We have a couple of apps and it 
*appears* to be affecting only one at the moment. 
(bookedin-prod.appspot.com)

Is anyone else having trouble? We've got some pretty testy clients on our 
hands at the moment and I need to tell them something.



-- 
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] Re: Latency problems

[Kyle Baley]

Ya, the list of recent downtime
notifications<https://groups.google.com/forum/#!forum/google-appengine-downtime-notify>doesn't
inspire a lot of confidence but this is the first time it's
affected us dramatically in some time. In any case, we seem to be more
stable now for about an hour so fingers are crossed. At the very least, I
can rest assured that system reliability is a top priority at
Google<https://www.google.com/search?q=%22please+rest+assured+that+system+reliability+is+a+top+priority+at+Google%22>
.


On Thu, Jun 27, 2013 at 11:35 AM, troberti  wrote:

> We had something similar yesterday morning for one of our apps. Lasted for
> about 3 hours.
>
> Today, on a different app, I saw a lot of very slow timeouts (60+) on some
> requests handlers which caused hundreds of extra instances to be launched..
> So something is still going on.
>
> On Thursday, June 27, 2013 5:02:49 PM UTC+2, Kyle Baley wrote:
>>
>> We've been having severe latency issues for about an hour now. Haven't
>> made any changes to our system for some time. We have a couple of apps and
>> it *appears* to be affecting only one at the moment. (
>> bookedin-prod.appspot.com)
>>
>> Is anyone else having trouble? We've got some pretty testy clients on our
>> hands at the moment and I need to tell them something.
>>
>>
>> <https://lh4.googleusercontent.com/-UG942Im8YgM/UcxUD0QgN8I/A7A/F5SU7LzABSU/s1600/Latency.png>
>>
>>  --
> 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/60Q1aAlAx_I/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.

[google-appengine] Re: Latency problems

[Kyle Baley]

Not sure if it's related but we've seen a significant spike in the number 
of front-end instance hours used by the system. More than one might 
attribute to traffic growth. It's jumped about 60-90% since the 25th. I.e. 
it went from 25-30 hours/day to 40-60 hours/day on average. Not gradually, 
either.

Is there any way to get someone to look at this to at least identify if the 
problem is with Google or us? That's not meant to sound snarky, I would 
honestly like to know.


On Wednesday, July 3, 2013 10:05:39 AM UTC+2, o...@haitov.com wrote:
>
> I encountered the same issue yesterday,
> Crazy response time of 30k-60kMS for basic requests.
> The even more troubling issue is that many of the requests are incoming 
> phone calls the comes from twillio, and when my app doesn't respond in 10s 
> the customers hear "an application error has occurred" because that's the 
> twillio timeout for a request.
> That makes me look very very bad in front of my customers !! Moreover they 
> aren't able to perform what they wish for which is a critical issue !!! i'm 
> thinking seriously of migrating from app engine if this kind of downtime 
> will continue.
> I am very disapointed from the GAE team, ok there is no free support, but 
> at least respond in the group or stack overflow about such critical issues 
>  i definitely consider this as a downtime, denying that it's like 
> saying that a car with a flat tire is a functional car, ok you can drive 
> with it very very slow, but it's still doesn't make it a functional car 
> !
>
> GAE team, please respect your customers and respond with some feedback, 
> estimated time when this issue will be fixed, or otherwise i believe many 
> other customer will also start looking fo other options (and there are 
> plenty of them...)
>

-- 
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] java.security.AccessControlException: access denied ("javax.security.auth.AuthPermission" "getSubject") on local gae server with maven

[Kyle Baley]

I'm working with Julien on this problem and can provide updates. IntelliJ 
is configured to use the App Engine SDK.

This worked for us locally when we used Eclipse as well. And it worked when 
we deployed via the GPE. Here's the logged exception for a deployed mapper:

com.google.appengine.tools.mapreduce.v2.impl.handlers.Status handleCommand: Got 
exception while running command
java.lang.ExceptionInInitializerError
at org.apache.hadoop.mapreduce.JobContext.(JobContext.java:80)
at 
com.google.appengine.tools.mapreduce.AppEngineJobContext.(AppEngineJobContext.java:123)
at 
com.google.appengine.tools.mapreduce.AppEngineJobContext.createContextForNewJob(AppEngineJobContext.java:132)
at 
com.google.appengine.tools.mapreduce.v2.impl.handlers.Controller.handleStart(Controller.java:85)
at 
com.google.appengine.tools.mapreduce.v2.impl.handlers.Status.handleStartJob(Status.java:81)
at 
com.google.appengine.tools.mapreduce.v2.impl.handlers.Status.handleCommand(Status.java:182)
at 
com.google.appengine.tools.mapreduce.MapReduceServlet.doPost(MapReduceServlet.java:203)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at 
com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:263)
at 
com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:178)
at 
com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:91)
at 
com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:62)
at 
com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:168)
at 
com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
at 
com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:168)
at 
com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
at 
com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:118)
at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:113)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at 
com.google.apphosting.utils.servlet.ParseBlobUploadFilter.doFilter(ParseBlobUploadFilter.java:125)
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:266)
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:146)
at 
com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:439)
at 
com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:435)
at 
com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:442)
at 
com.google.tracing.CurrentContext.runInContext(CurrentContext.java:186)
at 
com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:306)
at 
com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:298)
at 
com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:439)
at 
com.google.apphosting.runtime.ThreadGroupPool$PoolEntry.run(ThreadGroupPool.java:251)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang

[google-appengine] Datastore puts not working

[Kyle Baley]

We've been having an issue for the last hour with puts not working. When I 
save something, everything appears to succeed and there are no errors in 
the log but when I refresh the page, the previous changes I made disappear. 
This is happening in two different applications we have (the same codebase 
but one for staging and one for prod) but not in the third. The AppEngine 
status is showing green and I haven't received any emails indicating the 
team is looking into any issues which is why I'm posting here. We haven't 
hit our quota and haven't updated our app in over a week.

-- 
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] Datastore puts not working

[Kyle Baley]

Never mind! The email from the AppEngine team just came in.


On Tue, Mar 18, 2014 at 3:57 PM, Kyle Baley  wrote:

> We've been having an issue for the last hour with puts not working. When I
> save something, everything appears to succeed and there are no errors in
> the log but when I refresh the page, the previous changes I made disappear.
> This is happening in two different applications we have (the same codebase
> but one for staging and one for prod) but not in the third. The AppEngine
> status is showing green and I haven't received any emails indicating the
> team is looking into any issues which is why I'm posting here. We haven't
> hit our quota and haven't updated our app in over a week.
>
> --
> 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/aiRi9qDDAL4/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] Datastore puts not working

[Kyle Baley]

Here's the email I got:

We're investigating an issue with Google App Engine Datastore beginning at
Tuesday, 2014-03-18 11:45 AM. We will provide more information shortly.


On Tue, Mar 18, 2014 at 4:10 PM, Kinesh Patel  wrote:

> Sometimes my puts work but the queries are returning zero results for
> certain kinds. We've made zero code changes in 5 days, so it's def. a
> datastore issue with certain indexes not being updated.
>
>
> On Tuesday, March 18, 2014 4:09:04 PM UTC-4, Kinesh Patel wrote:
>>
>> I'm having the same issue. Have not received an email yet - are they
>> looking into it?
>>
>> On Tuesday, March 18, 2014 3:59:36 PM UTC-4, Kyle Baley wrote:
>>>
>>> Never mind! The email from the AppEngine team just came in.
>>>
>>>
>>> On Tue, Mar 18, 2014 at 3:57 PM, Kyle Baley  wrote:
>>>
>>>> We've been having an issue for the last hour with puts not working.
>>>> When I save something, everything appears to succeed and there are no
>>>> errors in the log but when I refresh the page, the previous changes I made
>>>> disappear. This is happening in two different applications we have (the
>>>> same codebase but one for staging and one for prod) but not in the third.
>>>> The AppEngine status is showing green and I haven't received any emails
>>>> indicating the team is looking into any issues which is why I'm posting
>>>> here. We haven't hit our quota and haven't updated our app in over a week.
>>>>
>>>> --
>>>> 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/aiRi9qDDAL4/unsubscribe.
>>>> To unsubscribe from this group and all its topics, 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-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/aiRi9qDDAL4/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: too many appengine frontend instances

[Kyle Baley]

This affected us and it's gone back to normal mostly. But for the last two 
days, our front-end instance usage is still roughly twice what it normally 
is.

On Friday, May 9, 2014 11:52:40 AM UTC-4, Diego Duclos wrote:
>
> The following was posted on the forums: 
> https://groups.google.com/forum/#!topic/google-appengine-downtime-notify/VmH7s-Eeyso
>
>
> On Fri, May 9, 2014 at 5:14 PM, Keith Mukai 
> 
> > wrote:
>
>> Same problem here. Crazy instance numbers since about 4hrs ago. Normally 
>> 3-5 instances and then it grew to 60+. Dead in the water now at my billing 
>> limit.
>>  
>> -- 
>> 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-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: Error deploying application: loop at 87% on sending batch files

[Kyle Baley]

We just upgraded from 1.9.3 to 1.9.4 and are seeing the same behaviour this 
evening. Even fails at the same point: after multiple 87% attempts.

On Thursday, May 8, 2014 12:58:40 AM UTC-4, Gilberto Torrezan Filho wrote:
>
> Confirmed: "appcfg.sh update" on 1.9.3 works as intended.
>
> I hope it gets fixed on next update.
>
> On Monday, May 5, 2014 8:48:50 PM UTC-3, Gilberto Torrezan Filho wrote:
>>
>> Hi Fernando,
>>
>> Thanks for your message (I was feeling lonely here =P). I'll check it out.
>>
>> Gilberto
>>
>

-- 
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: Error deploying application: loop at 87% on sending batch files

[Kyle Baley]

Confirmed that 1.9.3 still works for us. Anyone else have a solution that 
doesn't require downgrading?

On Tuesday, May 13, 2014 10:09:11 PM UTC-4, Kyle Baley wrote:
>
> We just upgraded from 1.9.3 to 1.9.4 and are seeing the same behaviour 
> this evening. Even fails at the same point: after multiple 87% attempts.
>
> On Thursday, May 8, 2014 12:58:40 AM UTC-4, Gilberto Torrezan Filho wrote:
>>
>> Confirmed: "appcfg.sh update" on 1.9.3 works as intended.
>>
>> I hope it gets fixed on next update.
>>
>> On Monday, May 5, 2014 8:48:50 PM UTC-3, Gilberto Torrezan Filho wrote:
>>>
>>> Hi Fernando,
>>>
>>> Thanks for your message (I was feeling lonely here =P). I'll check it 
>>> out.
>>>
>>> Gilberto
>>>
>>

-- 
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.

[google-appengine] Google Apps accounts and forums

[Kyle Baley]

I'm having quite a bit of trouble with the new community forums on
AppEngine. Might be linked to the new way Google is handling GAFYD
accounts as well.


Here's what happened this morning when I tried to access the community
forums: http://twitpic.com/3cife4


I have two GAFYD accounts: one for my personal domain and one for my
work, both converted to the "new" mechanism that makes them similar to
regular Google accounts. With each nested frame, it would ask me to
select one of them. I did and it would open another nested frame. Only
by opening a frame in a new tab/window was I able to break the cycle.
And even then, I couldn't do it from the Java-specific forum, only the
general one.


Has anyone else had similar problems with this forum? If so, did you
come up with a workaround?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appeng...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.