Hi Tim - no, we're not. A session might be created for a user based on their activity, so maybe a few times a day.
We're definitely not hammering the system... J On Mar 18, 2:14 am, Tim Hoffman <[email protected]> wrote: > I have had problems in the past where I was using a lot of remote_api > calls into appengine. > > What I found was, on each call I wasn't reusing an already > authenticated session, which meant after a number of calls > I would be hit with acaptchalock. (it seems higher up google > infrastructure didn't like me creating new authenticated session for > each call - aside from the fact it isn't very efficient ;-) > > Maybe thats whats happening in your case, it might be worthing > checking to see if you are creating a new authenticated session > frequently. > > Rgds > > T > > On Mar 16, 4:15 am, Jan Z <[email protected]> wrote: > > > > > gdata ClientLogin calls from GAE (and from GAE only) appear to get > > frequent spuriousCAPTCHAlocks. > > > By "spurious" I mean that another ClientLogin attempt a couple of > > seconds later succeeds (with same credentials), so there is no need > > for users to actually go through the unlockcaptcha step. > > > We can reproduce this on GAE reliably (as in acaptchaoccurring one > > or more times for every five attempts) using gdata (python) or > > straight protocol access with urlfetch. Same code runs on local SDK > > without encountering a singlecaptcha. > > > So it looks like the API iscaptcha-locking the GAE. > > > We have an existing support case #00618963 for this, would be great to > > get someone from the GAE team to have a look please? > > > Jan -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
