Sorry for not being clear. I was thinking about Abraham William's
suggestion above where Twitter Search API works with authenticated
sessions+rate limiting, instead of IP based rate filtering. Just so
you know, AppEngine has 30 second timeout on request to all AppEngine
urls, and 10 second timeout on each individual HTTP request made
within an AppEngine request. In case you are making multiple HTTP
requests to Twitter within each individual AppEngine request, all the
communication microseconds, from AppEngine to Proxy and Proxy to
Twitter and then Twitter to Proxy and Proxy to AppEngine, quickly
addup leading to timeouts. Personally i have tried quite a few
scenarios to catch all the data i can, but from my experience, i can
catch only 30%(sometimes better, sometimes almost nothing) of what i
want, and rest just ends up with 503 and eventually since_id/max_id
getting too old to get response from the Twitter Search API. So, right
now Twitter is putting it's resources to offer a very robust Search
API, but we as developers cannot use it effectively just 'cause of the
way the hits are counted. Not to mention we are also investing funds
to keep our apps running. Hope you understand our position.


On Oct 18, 3:12 pm, Chad Etzel <> wrote:
> On Sun, Oct 18, 2009 at 8:09 AM, vivekpuri <> wrote:
> > Will someone from Twitter please respond if there is an ETA to resolve
> > this issue. Work arounds can never be really as effective as the real
> > deal.
> Sorry, I thought it was clear from the previous email. There is no ETA
> because it's not going to be resolved. GAE does not use an IP
> infrastructure that is amicable to our rate-limiting logic, so if you
> want to integrate IP rate-limited calls into your web-based
> applications, you will need to either use the workaround stated
> earlier or use a hosting service that will let you use a static IP.
> -Chad

Reply via email to