Greetings! I did an analysis of your requests on our servers, and I found a pattern that appears to be causing these errors. I'll cover my observations followed by some best practices, so that these errors are not as frequent.
Observations I noticed that there was a pattern in how the OfflineUserDataJobService was being called. The pattern was similar to this: Create the offline data job for the user list. Immediately add operations with one request. Run the job. Immediately create another data job for the same user list. Immediately add operations with one request. Run the job. And so on... When running offline user data jobs in this way, the concurrent modification exception is one I would expect. Heres's why. Every time a request is made in reference to an object like a user list, the user list resource is locked down so two threads don't accidentally cause a race condition. In the pattern I'm seeing, a new job is created for a user list before the previous job has completed. I saw repeatedly that the new job was created in the same second or the second after run job method was called on the same user list. This is where the concurrent modification exception comes in. Due to the user list still being locked down by the previous job adding data to it, the following requests can sometimes can locked out. I can give you some best practices next to explain how to structure your jobs to make that less of a chance. Best practices There are two best practices here that will help stop this error from happening. Best Practice #1 Do not have multiple jobs running in parallel for the same user list. What would need to change in your code would be to wait until the job has finished running for a user list by polling the job periodically until it's done. Then, create a new job for that user list. What I've seen our community do is have multiple offline data jobs running, but each offline data job is updating a different user list. So, they have one thread per user list running with multiple threads in parallel. That way they can still get great throughput on multiple user lists being updated without causing the error. Best Practice #2 Create larger jobs. What most people do is that for a single user list, they will create an offline job, send an add operations request, then another add operations request with more operations, then another operations create and so on, and then call run job. This creates a larger job. What this does is it means that you call create job and run job less often. A single job may take longer, but because you don't have to call create job and run job so often, you actually save time over a longer period. This is especially the case when you need to upload large amounts of data to a single user list. Please give those best practices a try. That should clear up those errors that you're seeing. Regards, Nadine Wang Google Ads API Team ref:_00D1U1174p._5004Q2TkoQ6:ref -- -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog: https://googleadsdeveloper.blogspot.com/ =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API and Google Ads API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en --- You received this message because you are subscribed to the Google Groups "AdWords API and Google Ads API Forum" group. To unsubscribe from this group and stop receiving emails from it, send an email to adwords-api+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/adwords-api/5-519000000000000000000000000000000000000000000000R4YBQZ00K4Zw2EqMR22ro-elxs3Klg%40sfdc.net.
