Hi,
I am trying to create a XMPP Agent.It is a very basic code.But I am
unable to deploy. I am getting the following error while trying to
deploy,
Unable to update app: Error posting to URL:
https://appengine.google.com/api/appversion/getresourcelimits?app_id=gaejxmpptutorial13%40appspot.com&vers
I am having the same issue. I have a Python app that lets users log in
with their Google accounts. Any user with one account can sign in with no
problem, but users with multi sign in enabled get the error described
below. Does anyone know how to fix this? It seems like all the threads on
th
I am trying to use the filter() method based on a key argument. For
example:
user_key="agxkZXZ-emFiZXRhLTJyCgsSBFVzZXIYGAw"
d=datamodel.Task.all()
d.filter("user=",user_key)
results=d.fetch(1024)
This produces zero results, and its probably because the key isn't in
the right format. If this where
I'm working on a multi-user application where I'm using my own
authentication / account scheme, but am running into trouble structuring
accounts in GAE storage. Here's where I started and got tripped up:
- I'd like each user be a root level entity, and have all of the entities
for that user be
My web app makes use of Google Cloud SQL.
It works perfectly locally, using mvn gae:run (mave gae plugin) on
local mysql db.
Here's some of my xml spring context config:
it.trew.prove.model.beans.Scadenza
>
> Manually copying the ACSID (in Firefox) during this redirection seems to
> work. I shall see how well it holds up automated.
On Tuesday, March 20, 2012 11:58:16 PM UTC-7, tarun2000 wrote:
>
> I don't think that would work. If I login and get redirected to
> blah.appspot.com, then manuall
Searching "Unable to get members for class" on google lends to
many AppEngine-related results!
What is that error? In my case, I can't autowire an Hibernate session
factory (working with Cloud SQL).
Failed startup of context
com.google.apphosting.utils.jetty.RuntimeAppEngineWebAppContext@1079
Hi
I have a application and my datastore indexes are full i have created
200 indexes.
is there any way that indexes can be increased ?
Can i increase indexes by enabling billing on my application ?
--
You received this message because you are subscribed to the Google Groups
"Google App Engine
Hi Arie,
thanks for looking after by backups. Please cleanup the failed backups, I
will make new ones containing at most 15 kinds each. Thanks!
Daniel
Am Montag, 19. März 2012 22:55:05 UTC+1 schrieb Arie Ozarov:
>
> Hi Daniel,
>
> In both cases the backup failed in its last stage which is a cle
Hey App Engine developers,
We’re working on a new feature to help out your front-end development
efforts. We’ve been working with the Google Page Speed team (
https://developers.google.com/pagespeed/service) to bring Page Speed
Service to your App Engine applications. When enabled, this feature wi
I also want to know if that would be possible. Actually my app is using 186
out of 200 and I am afraid that soon more than 200 will be needed.
Is there something to buy?
Il giorno mercoledì 21 marzo 2012 08:47:06 UTC+1, prakhil samar ha scritto:
>
> Hi
>
> I have a application and my datastore i
dont know if this is a typo but there is a strict syntax on how to query.
you are missing some spaces in your filter():
d.filter('user =', user_key)
there is a space between property name ane =
On Mar 20, 2012, at 5:26 PM, Mike wrote:
> I am trying to use the filter() method based on a key arg
I would suggest optimising the number of indexes, 200 is a lot of indexes!
Read this and see if you can reduce the number of indexes given some of the
improvements last year:
http://code.google.com/appengine/articles/indexselection.html
On Wednesday, March 21, 2012 12:53:31 PM UTC, Nicanor Bab
On Wed, Mar 21, 2012 at 1:44 AM, toonetown wrote:
> Yup - still waiting for resolution on deadlineexceeded exceptions...2+ weeks
> and counting. Even migrated to HRD (even though our app doesn't use data
> store at all)
>
> Still nothing. And no way to contact anyone or find out what's going on.
I remember get tripped up on that space, boy was that painful. You can also
leave out the = entirely, it is assumed if no operator is given.
Using filter you can use a key object directly, I have no experience with
using a string with filter.
On Wednesday, March 21, 2012 12:57:15 PM UTC, aschmi
BTW, this is the Latency-Graph I'm currently experience: 8 days ago
(approx. March 13) everything was still fine then it started climbing and
the last 1-2 days it's extremely sporadic... (not sure if this is a
sampling issue and the data earlier are just smoothed).
I have not made changes to my
Same for me. It seems to be very obviously that there is a major problem
in the GAE runtime starting around 8 days ago.
My instance scheduling went wild (see attached picture).
I updated to version 1.6.3. on March 9 -> I think the issue is not related
to the SDK Version number.
How long does it t
Sorry for the times in the log, my computer is set to UTC+11.
02:44 <+proppy> hey there
02:48 < sec_> good holiday proppy :)
02:48 <+proppy> I'm visiting london :)
02:48 <+proppy> not really in holiday
02:49 * sec_ have read all GAE thing related (but slow)
02:54 <+proppy> how many people are the
On Tuesday, March 20, 2012 2:26:20 PM UTC-7, Mike wrote:
>
> I am trying to use the filter() method based on a key argument. For
> example:
>
> user_key="agxkZXZ-emFiZXRhLTJyCgsSBFVzZXIYGAw"
> d=datamodel.Task.all()
> d.filter("user=",user_key)
> results=d.fetch(1024)
> This produces zero res
ok guys now fetching 500 entities by keys as strings takes something between
8-10 seconds?!!
3s was already too much... 10 is not acceptable.
On Feb 18, 2012, at 11:17 AM, GordonHo wrote:
> i am having a similiar problem.
> occasionally i need to fetch all entities of a given table (about 5000)
tested ndb.ge_multi(). the same query with the same keys takes 0.7 seconds
how is this possible?
On Mar 21, 2012, at 3:49 PM, Andreas wrote:
> ok guys now fetching 500 entities by keys as strings takes something between
> 8-10 seconds?!!
> 3s was already too much... 10 is not acceptable.
>
Hi Daniel,
Both backups were removed.
Let me know if you have any more issues.
Regards,
Arie.
On Wed, Mar 21, 2012 at 3:00 AM, Daniel Behnen wrote:
> Hi Arie,
>
> thanks for looking after by backups. Please cleanup the failed backups, I
> will make new ones containing at most 15 kinds each. T
I'm posting my workaround that I've implemented for anyone that may be
interested in the future. I'd also appreciate feedback.
1) Client hits https://mydomain.com/blah which goes through EC2 proxy
https://appid.appspot.com/blah
2) The client is redirected to the google login page, with continue
There are a lot of possible answers to that question. Have you
enabled appstats? That is the best way to figure out what is actually
going on.
Jeff
On Wed, Mar 21, 2012 at 4:45 PM, Andreas wrote:
> tested ndb.ge_multi(). the same query with the same keys takes 0.7
> seconds how is this pos
Not sure if this will help you, but we've been reasonably happy with
CloudFlare's SSL support. It provides SSL to CF's edge, then http
between CF and Google - not great if you're taking CC#s, but perfectly
adequate for protecting against FireSheep-type attacks.
We aren't using Google auth, howeve
i mean with query here i dont really mean querying and filtering. i have a list
of keys and i get() them.
what is going on i think is that ndb does the query a bit smarter than the db
module.
ndb is consistently under 1s while db takes multiple seconds.
On Mar 21, 2012, at 7:14 PM, Jeff Schni
I think I'd have the same issue since the continue url would be relative to
appspot unless I specify it fully, but that results in a 500 =(. However,
if someone got it to work please let me know!
On Wed, Mar 21, 2012 at 4:22 PM, Jeff Schnitzer wrote:
> Not sure if this will help you, but we've
If I had to guess, I would suspect the difference is NDB's caching
layer pulling data from memcache. But I don't know. The only way to
find out is to run appstats and find out what's actually going on.
Stop speculating, start measuring. It's the same datastore
underneath.
Jeff
On Wed, Mar 21,
your right. didnt have the time yet to find out what the difference is but i
will.
another possible option is that ndb is making async gets for the keys compared
to the db...
On Mar 21, 2012, at 8:45 PM, Jeff Schnitzer wrote:
> If I had to guess, I would suspect the difference is NDB's caching
29 matches
Mail list logo
