BOOM!!! Daily limit reached... about gcalcli HOT 26 CLOSED

I work in Google.
if u give me a link to your ticket I can try to help.

well done man!!

Sent from my iPhone 4 so pls excuse my (his?) typos ;)

On 21 Feb 2013, at 00:58, Eric Davis [email protected] wrote:

gcalcli from 'master' seems to be popular! We've easily reached the daily 10K request limit. This quota is tied to the gcalcli client application key which is in turn tied to my Google account. There are two temporary solutions and one long term solution...

Short term:

1. Increase the daily quota limit.
2. Change gcalcli so each user has to create their own client application key tied to their own Google account.

Long term:

1. Caching.

I don't like the idea of each user having to create their own client application key. This is a hassle and something you don't have to do for any other application using the various Google APIs.

Today I put in a request to Google to raise the daily quota to 1M requests per day. Hopefully this will be enough until we fully support caching. Btw, see the 'caching' branch for that work.

Traceback (most recent call last):
File "/mnt/raid/insanum/src/gcalcli/gcalcli", line 2427, in
BowChickaWowWow()
File "/mnt/raid/insanum/src/gcalcli/gcalcli", line 2257, in BowChickaWowWow
useCache=useCache)
File "/mnt/raid/insanum/src/gcalcli/gcalcli", line 539, in init
self._GetCached()
File "/mnt/raid/insanum/src/gcalcli/gcalcli", line 623, in _GetCached
calList = self._CalService().calendarList().list().execute()
File "/usr/lib/python2.7/site-packages/oauth2client/util.py", line 120, in positional_wrapper
return wrapped(_args, *_kwargs)
File "/usr/lib/python2.7/site-packages/apiclient/http.py", line 678, in execute
raise HttpError(resp, content, uri=self.uri)
apiclient.errors.HttpError: <HttpError 403 when requesting https://www.googleapis.com/calendar/v3/users/me/calendarList?alt=json&key=AIzaSyA6qJCdEnUiOX7Y79Ro5eA2toInxwWCikc returned "Daily Limit Exceeded">
—
Reply to this email directly or view it on GitHub.

from gcalcli.

Nice! :-)

When I submitted the quota request I didn't see a link or really care for that matter. Also didn't get a return email saying it's in progress. Is there someplace under my (apps) account that would list it? I briefly looked but didn't find anything.

If it helps gcalcli's project number in the APIs console is: 232867676714

from gcalcli.

So atm, nothing can be done to render it usable? Not whining, I know things happen (altho I cant really fix them lol).

from gcalcli.

Alright Mr. Juggalo... :-) You have two "immediate" options. Use the v2.4.1 tag of gcalcli which uses the older gdata python module and is not subject to quota limits, but requires username/password. The other option is to create your own client application id and secret key that is tied to your Google account. Simply go to https://code.google.com/apis/console and create a new project. Under the API access for your project you'll see the client id and secret. Simply hardcode those two items in the gcalcli script (search for client_id and client_secret).

More details can be found here: https://developers.google.com/console/help/

from gcalcli.

Hi Eric,
when I have some time I'll try to raise your quota.
Honestly I cant promise anything at all, but I'll do all I can trust me.
If, on your side, you have something to say that i can easily copy and
paste like "this is a service from which many people benefit blah blah
blah" I'll try to use it to make your point stronger.

Have a lovely weekend,
Riccardo

On 21 February 2013 08:14, Eric Davis [email protected] wrote:

Nice! :-)

When I submitted the quota request I didn't see a link or really care for
that matter. Also didn't get a return email saying it's in progress. Is
there someplace under my (apps) account that would list it? I briefly
looked but didn't find anything.

If it helps gcalcli's project number in the APIs console is: 232867676714

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-13876157.

"I'm carless but I couldn't care less"
Riccardo Carlesso
http://www.palladius.it/

from gcalcli.

Thanks @palladius. I just checked the gcalcli API console and saw the quota was raised to 100K per day. I never got an email or anything. Thanks Google! I'm closing this issue for now. If we start hitting the new daily quota I'll open this up again.

from gcalcli.

100K daily limit is now getting reached. Looks like people in Taiwan and Italy are wacking Google with gcalcli. I put in a request to Google for raising the daily limit again. Hope they continue to be awesome! If not I'll have to focus in again on adding caching support.

from gcalcli.

Daily quota limit reached very early today. This means everyone using gcalcli from the master branch is completely hosed right now.

I can tell from the quota reports there are a select few who are completely abusing Google's servers with gcalcli. While I can't tell exactly what's going on I'm suspecting a user(s) not thinking whatsoever and has a shell script with a tight loop running gcalcli every second against an account with heavily populated calendars. Then this script is shared with others because it's so cool! :-)

We're discussing a fix/workaround. Best solution is we're going to make everyone configure their own keys with Google (tied to their own accounts) and oauth2 against those. This results in a simple one time setup per Google account.

from gcalcli.

On Wed, Apr 10, 2013 at 10:54:06AM -0700, Eric Davis wrote:

Daily quot limit reached very early today. This means everyone using gcalcli
from the master branch is completely hosed right now.

I can tell from the quota reports there are a select few who are completely
abusing Google's servers with gcalcli. While I can't tell exactly what's going
on I'm suspecting a user(s) not thinking whatsoever and has a shell script with
a tight loop running gcalcli every second against an account with heavily
populated calendars. Then this script is shared with others because it's so
cool! :-)

We're discussing a fix/workaround. Best solution is we're going to make
everyone configure their own keys with Google (tied to their own accounts) and
oauth2 against those. This results in a simple one time setup per Google
account.

—
Reply to this email directly or view it on GitHub.*

Not that I can offer any coding or support to do so, I'm totaly behind
this. A Little config never hurt anyone, and it would solve the issue
pretty well correct? I use a few other tools that need to use the google
auth stuff, and its hardly a headache, one time typicaly and its great.

from gcalcli.

I'm kinda surprised at how this is handled by Google. You would think the limits would be per-app/per-account instead of just per-app. That totally hoses people if 1 person abuses the app, and Google can identify who that is and throttle them...

from gcalcli.

Okay, the 2 last commits should at least give a way to work around the limits. Adds 2 new params that can be configured on the command line or gcalclirc:

• --client_id
• --client_secret

These can be generated by creating a project at https://code.google.com/apis/console/ . I also removed the API key and have encouraged @insanum to regenerate it. I did notice that for one of my accounts, the initial caching requests can take over 1000 API requests, that's crazy talk and I think we need to look at opportunistic caching versus full data caching.

from gcalcli.

So this is happening again :( Really need to fix this to cache opportunistically vs attempting to download all the data every time. I don't think we can release this "officially" without fixing this...

from gcalcli.

@insanum https://github.com/insanum/gcalcli/compare/no_fake_cache_events should seriously cut down on API requests when people refresh cache. Given that only the calendar list cache is currently used, making the event retrieval calls is wasteful at this point. Any objections to merging this into master?

from gcalcli.

I have no objections as long as the code you're removing still lives in the "caching" branch so we can chip away at it later.

from gcalcli.

I'll make sure it's there and that the caching branch is brought up-to-date with current efforts. Then will merge this into trunk.

from gcalcli.

Once I get to the console, I turned ON the calendar API. Is that the right thing to do first?

Then I go to register a new app, put in a name ("My Gcalcli") and then I'm presented with these choices:

• Web Application
• Android
• iOS
• Chrome
• Native

Since gcalcli is a shell script, does it qualify as "Native"?

from gcalcli.

Yes
On Nov 19, 2013 12:30 AM, "taa1" [email protected] wrote:

Once I get to the console, I turned ON the calendar API. Is that the right
thing to do first?

Then I go to register a new app, put in a name ("My Gcalcli") and then I'm
presented with these choices:

• Web Application
• Android
• iOS
• Chrome
• Native

Since gcalcli is a shell script, does it qualify as "Native"?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-28770944
.

from gcalcli.

I've merged my no fake caching branch into master. The old behavior is in the caching branch (as well as in history.) This should be a major reduction in both startup time for gcalcli and requests made be clients.

Additionally I've requested an API limit increase from Google.

from gcalcli.

:-) Thanks @tresni.

from gcalcli.

Recently, I am seeing the "Daily Limit Exceeded" error more often. Anything we can do about this?

from gcalcli.

I got hit with it last night. :(

from gcalcli.

I'm getting it now unfortunately

from gcalcli.

We've requested a API limit increase and it was just granted. You should be good to go again.

from gcalcli.

Brilliant, it's working again.

from gcalcli.

Until next time... :-)

On Wed, Feb 4, 2015 at 2:53 PM, Brian Hartvigsen [email protected]
wrote:

We've requested a API limit increase and it was just granted. You should
be good to go again.

—
Reply to this email directly or view it on GitHub
#65 (comment).

from gcalcli.

I'm closing this for now since we've addressed the immediate issue. We have issues open to implement caching and the like. We can re-open this (or open a new ticket) if we still need it.

from gcalcli.