I think that would be fine except for the edge case, wherein our customers are editing and saving individual records. Our sending is asynchronous to the user (our client) activity. We have to switch user for each update. It's not too hard to imagine that there would be times where many people would be editing simultaneously yet acting as a broker we would be re-issuing the same credentials. And if we don't act as a broker it seems likely that a single user could put in 10 updates and when we sweep be we might get several threads sending nearly simultaneously. Wham.
We can take care of this. It's just more code! :) But we would like a) to know that in fact we are hitting a throttle limit and b) a more precise definition of the limit. And maybe c) an improvement on the error message: the required credentials were of course sent (and correct). Cheers On Aug 29, 11:21 am, "Eric (Google)" <[EMAIL PROTECTED]> wrote: > Ah, you should only call setUserCredentials once. > That function makes an HTTPS request for a new token. > > http://code.google.com/apis/gdata/auth.html#ClientLogin > > Eric > > On Aug 28, 6:28 pm, icebackhaz <[EMAIL PROTECTED]> wrote: > > > This is using the java API. I've generally been testing with pushing > > 10 items in a single feed (and occasionally with >500). Also I have > > no problem inside eclipse running 20 submissions each with a single > > rather sparse item. But when we escalate the processing to the more > > production-like multi-threaded scenario (say 5 threads), a run of 20 > > of those same single-item submissions (each with a > > setUserCredentials() call) generates an AuthenticationException for > > some of the submissions with a message stating "Authentication > > required" (The exception class is correct, my programme catchs > > explicitly that, and the "Authentication required" is definitely > > there, I just don't have the full message to hand.) > > > So our concern is somewhat of an edge case perhaps. We don't expect > > to get a lot of singleton requests in rapid fire from our (eventual) > > users, but it reliably blows up in testing so we will have to guard > > for it. (This may lead us away from being an aggregator as we w/could > > use different credentials in reality (If for instance we suddenly got > > a slough of singleton requests from a variety of our clients.) > > > On Aug 28, 6:45 pm, "Eric (Google)" <[EMAIL PROTECTED]> wrote: > > > > How are you doing the inserts? Are you using one of the libraries? > > > > I just tried inserting 30 items in a single loop using the PHP > > > library. > > > Everything went as expected. > > > > Also, what's the auth error? > > > > Eric > > > > On Aug 28, 5:08 pm, icebackhaz <[EMAIL PROTECTED]> wrote: > > > > > Has anybody else seen authentication failure on rapidly fired single- > > > > entry submissions? A test using 20 items sent in succession (well > > > > potentially in parallel as the env is multithreaded) is generating an > > > > authentication exception on some of the entries. > > > > > From the FAQ: > > > > "The Google Base data API supports up to approximately 5 queries per > > > > second, per user." > > > > > Are inserts queries? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Base Data API" 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-Base-data-API?hl=en -~----------~----~----~----~------~----~------~--~---
