Hi, I'm the poster from the original discussion you referenced (http:// groups.google.com/group/google-apps-apis/browse_thread/thread/ 3b191cc9dbefe937/5757612620d41390?lnk=gst&q=503+server +busy#5757612620d41390)
I've now had good luck using the recommendations provided: - if you start getting a few 503's in a feed for a user, wait 15 seconds or so (and consider exponential backoff for future 503s), then upload just those failed messages -- I do so by generating new batch feeds with just the failed messages. - consider building in some minor delays. For example, for users with multiple folders of mail, I wait 15-30 seconds between trying to upload each folder. - if a particular user is generating a large number of 503s, "pause" that upload process for awhile, then come back to the user - you can upload mail for multiple users at a time without them affecting each other's rate of 503s (if that makes sense) I still tend to see LOTS of 503s, but by using delays and exponential back-off, I'm able to get a fairly reasonable overall upload time. On Jul 8, 4:11 pm, Frank Mantek <[EMAIL PROTECTED]> wrote: > a) i would agree with you that the server behavior here could be > improved. it will always be possible that a server can not process > items in your batch for some reason, so you need a strategy to deal > with it, but the 503 seems to be something a service should be > avoiding. But i leave that up to the apps team to answer in more detail. > > b) Your algorithm seems reasonable and it's up to you to create a new > batchfeed. In .NET you would iterate over your original feed, remove > the successful ones, and just batch again, so it's not too complicated > (IMO). > > Regards > > Frank Mantek > Google > On Jul 8, 2008, at 3:59 PM, bobb wrote: > > > > > > > I read with interest this conversation on a similar topic: > >http://groups.google.com/group/google-apps-apis/browse_thread/thread/... > > > One apparent difference with my case, however, is that I am using > > MailItemService.Batch() to upload 50 messages at > > a time. For each upload transaction, I examine the result feed for the > > status code of each entry. > > > I see many instances where of the 50 entries in a feed, a third or > > maybe half of them are marked as "503" with the reason "server busy, > > try again later". The rest are as expected, code 201 "Created". > > > Two important questions: > > > 1) How do I prevent this from happening? My claim would be that in a > > batch feed the server itself should figure out how to queue/cache the > > entries in the feed so that it can handle them all, not just some of > > them. > > > 2) Given that it's going to happen, how do I recover? I can imagine a > > technique whereby I find the entries in the result feed that have this > > problem, then match them (by batch id probably) with the original > > entries in the upload feed, then somehow submit them again (maybe 1- > > by-1? Or as a new batch feed?). This seems unreasonably complex, and > > also creates a ton more http traffic. > > > Any suggestions?- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Apps APIs" 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-apps-apis?hl=en -~----------~----~----~----~------~----~------~--~---
