Failed to do client auth with Gaia server exception

[Manish Khettry]

We are trying to upload a campaign to one of our existing accounts and part way through, an attempt to upload keywords is failing out repeatedly with this exception.

java.io.IOException: Failed to do client auth with Gaia server.
        at com.google.api.adwords.lib.AuthToken.getAuthToken(lib:AuthToken.java):63)
        at com.adchemy.sem.google.gateway.GoogleCredentials.getAuthToken(GoogleCredentials.java:102)
        at com.adchemy.sem.google.gateway.GoogleServices.setSoapHeaders(GoogleServices.java:102)
        at com.adchemy.sem.google.gateway.GoogleServices.createAdGroupCriterionService(GoogleServices.java:85)
        at com.adchemy.sem.google.gateway.GoogleItemGateway.getKeywordService(GoogleItemGateway.java:44)
        at com.adchemy.sem.google.gateway.GoogleKeywordGateway.createCriteria(GoogleKeywordGateway.java:131)
        at com.adchemy.sem.google.gateway.GoogleGateway.createCriteria(GoogleGateway.java:142)

Any ideas what this means?

[AdWords API Advisor]

Hi Manish,

This could be caused by making too many requests to the ClientLogin
API, which is done every time you create a new AdWordsUser or
service. Please ensure that you are re-using your users and services
between requests.

Best,
- Eric Koleda, AdWords API Team

> com.adchemy.sem.google.gateway.GoogleGateway.createCriteria(GoogleGateway.j ava:142)

[Pete Lavetsky (AdWords API Guru)]

Eric,

Is there a procedure to get the request limit bumped? We're re-using
everything between requests, but still hit this limit every now and
then.

Thanks
Pete

On Feb 24, 10:50 am, AdWords API Advisor

[AdWords API Advisor]

Hi Pete,

As far as I know it isn't possible to change those limits. Looking at
this code again, the error message was being returned in any situation
where the ClientLogin API returns a status code other than 200, so in
your case it might be due to factors other than too many logins. The
client library has been updated to better report and handle
ClientLogin errors, so you may want to see if that gives you more
information.

Best,
- Eric

On Apr 7, 8:03 am, "Pete Lavetsky (AdWords API Guru)"

[hov...@gmail.com]

Hi,

We are having the same error. We just migrated from V13 to V2009 and
we are getting thousands of this errors when we are trying to change
bids. We run the same scenario with old (v13) API and it is working.
Was this limit reduced from version 13 to 2009?

As far as your suggestion goes. Is there a suggested pattern for
caching AdWordsUser and services? Are these objects thread safe? Can
you cache them indefinitely? If you create a service using client
account X, can you reuse it using client account Y?

This is not related to this particular error (at least I don't think
it does, but we also got the follwoing errors). Any idea how we we can
find out more about it?

faultString: InternalApiError.UNEXPECTED_INTERNAL_API_ERROR @

Thanks,

Hovanes

On Apr 7, 8:04 am, AdWords API Advisor <adwordsapiadvi...@google.com>
wrote:

> Hi Pete,
>
> As far as I know it isn't possible to change those limits.  Looking at
> this code again, the error message was being returned in any situation
> where the ClientLogin API returns a status code other than 200, so in

> your case it might be due to factors other than too many logins.  Theclientlibrary has been updated to better report and handle

[AdWords API Advisor]

Hi Hovanes,

In general authTokens should be reused as much as possible, keeping in
mind that they expire after two weeks. Although we try to ensure that
the AdWordsUser and services in our client libraries are thread safe
our general recommendation is for each thread to have it's own users
and services. Because these objects contain references to the
authToken they should be used for no longer than two weeks.

As for the UNEXPECTED_INTERNAL_API_ERROR, if you provide me the
requestId or SOAP XML request and response that demonstrates the
problem then I can research into the problem further.

Best,
- Eric

[hov...@gmail.com]

Hi Eric,

Thanks for quick response.

I am a little unclear about difference of creating AdWordsUser using
client account and without client account.

1. public AdWordsUser(String email, String password, String clientId,
String userAgent, String developerToken, String applicationToken)
vs
2. public AdWordsUser(String email, String password, String userAgent,
String developerToken, String applicationToken)

1. If you use (1) then you can only use that AdWordsUser to work with
that specified client account. if you try to use AdWordsUser that was
created using client account X with client account Y it will cause an
error.

2. If you use (2) you can use that AdWordsUser to work with any client
accounts?

3. Are these assumptions correct? If yes, are there any restrictions
on using AdWordsUser created using (2).

Our software has batch jobs that run daily and perform (for example)
bidding across different accounts. Right now we try to group this
operations per adgroup and instantiate AdWordsUser using (1) for each
adgroup update (using client ID of whatever account that adgroup
happens to be in). So my question is, can we create AdWordsUser only
once using (2) and then reuse it to change bids (or do other
operations) in all client accounts that are under that same MCC?

I will get more details on
InternalApiError.UNEXPECTED_INTERNAL_API_ERROR.

Thanks again,

Hovanes

On Apr 8, 7:55 am, AdWords API Advisor <adwordsapiadvi...@google.com>
wrote:

> Hi Hovanes,
>
> In general authTokens should be reused as much as possible, keeping in
> mind that they expire after two weeks.  Although we try to ensure that

> the AdWordsUser and services in ourclientlibraries are thread safe

> our general recommendation is for each thread to have it's own users
> and services.  Because these objects contain references to the
> authToken they should be used for no longer than two weeks.
>
> As for the UNEXPECTED_INTERNAL_API_ERROR, if you provide me the
> requestId or SOAP XML request and response that demonstrates the
> problem then I can research into the problem further.
>
> Best,
> - Eric
>
> On Apr 7, 9:26 pm, "hov...@gmail.com" <hov...@gmail.com> wrote:
>
>
>
> > Hi,
>
> > We are having the same error. We just migrated from V13 to V2009 and
> > we are getting thousands of this errors when we are trying to change
> > bids. We run the same scenario with old (v13) API and it is working.
> > Was this limit reduced from version 13 to 2009?
>
> > As far as your suggestion goes. Is there a suggested pattern for
> > caching AdWordsUser and services? Are these objects thread safe? Can
> > you cache them indefinitely? If you create a service usingclient

> > account X, can you reuse it usingclientaccount Y?

[hov...@gmail.com]

Hi Eric,

Thanks for quick response.

Thanks again,

Hovanes

On Apr 8, 7:55 am, AdWords API Advisor <adwordsapiadvi...@google.com>
wrote:

> Hi Hovanes,
>
> In general authTokens should be reused as much as possible, keeping in
> mind that they expire after two weeks.  Although we try to ensure that

> the AdWordsUser and services in ourclientlibraries are thread safe

> our general recommendation is for each thread to have it's own users
> and services.  Because these objects contain references to the
> authToken they should be used for no longer than two weeks.
>
> As for the UNEXPECTED_INTERNAL_API_ERROR, if you provide me the
> requestId or SOAP XML request and response that demonstrates the
> problem then I can research into the problem further.
>
> Best,
> - Eric
>
> On Apr 7, 9:26 pm, "hov...@gmail.com" <hov...@gmail.com> wrote:
>
>
>
> > Hi,
>
> > We are having the same error. We just migrated from V13 to V2009 and
> > we are getting thousands of this errors when we are trying to change
> > bids. We run the same scenario with old (v13) API and it is working.
> > Was this limit reduced from version 13 to 2009?
>
> > As far as your suggestion goes. Is there a suggested pattern for
> > caching AdWordsUser and services? Are these objects thread safe? Can
> > you cache them indefinitely? If you create a service usingclient

> > account X, can you reuse it usingclientaccount Y?

[AdWords API Advisor]

Hi Hovanes,

An AdWordsUser can either be constructed with a clientId or without
one. When a clientId isn't specified then the services run directly
against the MCC account. This can be useful when you want to run
cross-client reports, or get API usage info. However, for making
changes to campaigns, ad groups, etc you need to use a user with a
clientId of the account that owns the campaigns. The AdWordsUser
object provides a method of obtaining a client user from an MCC user:

http://code.google.com/p/google-api-adwords-java/source/browse/trunk/src/com/google/api/adwords/lib/AdWordsUser.java#400

Best,
- Eric

[hov...@gmail.com]

Hi Eric,

So, does that mean that if we want to reuse AdWordUsers and services
generated from these users we to cache both (users and services) per
each client account and per each thread?

One more thing, you didn't answer my question from my original post.
Was the number of allowed request to ClientLogin API reduced from
version 12 to 2009? Because we have been running this exact scenario
with a lot more bids with no problem with all previous API versions.

Thanks,
Hovanes

On Apr 9, 10:17 am, AdWords API Advisor <adwordsapiadvi...@google.com>
wrote:
> Hi Hovanes,
>

> An AdWordsUser can either be constructed with a clientId or without
> one.  When a clientId isn't specified then the services run directly
> against the MCC account.  This can be useful when you want to run

> cross-clientreports, or get API usage info.  However, for making

> changes to campaigns, ad groups, etc you need to use a user with a
> clientId of the account that owns the campaigns.  The AdWordsUser

> object provides a method of obtaining aclientuser from an MCC user:
>
>  http://code.google.com/p/google-api-adwords-java/source/browse/trunk/...

>
> Best,
> - Eric
>
> On Apr 8, 3:15 pm, "hov...@gmail.com" <hov...@gmail.com> wrote:
>
>
>
> > Hi Eric,
>
> > Thanks for quick response.
>
> > I am a little unclear about difference of creating AdWordsUser using
> >clientaccount and withoutclientaccount.
>
> > 1. public AdWordsUser(String email, String password, String clientId,
> > String userAgent, String developerToken, String applicationToken)
> >  vs
> > 2. public AdWordsUser(String email, String password, String userAgent,
> > String developerToken, String applicationToken)
>
> > 1. If you use (1) then you can only use that AdWordsUser to work with

> > that specifiedclientaccount. if you try to use AdWordsUser that was
> > created usingclientaccount X withclientaccount Y it will cause an

> > error.
>
> > 2. If you use (2) you can use that AdWordsUser to work with anyclient
> > accounts?
>
> > 3. Are these assumptions correct? If yes, are there any restrictions
> > on using AdWordsUser created using (2).
>
> > Our software has batch jobs that run daily and perform (for example)
> > bidding across different accounts. Right now we try to group this
> > operations per adgroup and instantiate AdWordsUser using (1) for each

> > adgroup update (usingclientID of whatever account that adgroup

> > happens to be in). So my question is, can we create AdWordsUser only
> > once using (2) and then reuse it to change bids (ordoother

> > operations) in allclientaccounts that are under that same MCC?

[AdWords API Advisor]

Hi Hovanes,

Yes, caching the users and services per client account and per thread
is one way. Another way would be to simple cache the authToken for
the MCC user, and use it to create a new AdWords user when you need
one.

The v13 version of the API didn't use the ClientLogin API so you can't
compare it with the functionality in v200909.

Best,
- Eric

[hov...@gmail.com]

Thanks for your help Eric.

We have modified our software to cache AdWordsUser per account. We are
not caching services, but it seems as that doesn't make much
difference, because once AdWordsUser is authenticated (it has
authToken) subsequent calls to getService don't make web service calls
and complete very quickly.

We are still testing, and there are some other issues (so I might be
posting more), but we are no longer getting "Failed to do client auth
with Gaia server exception" errors.

Thanks again,
Hovanes

On Apr 12, 9:27 am, AdWords API Advisor <adwordsapiadvi...@google.com>
wrote:
> Hi Hovanes,
>
> Yes, caching the users and services perclientaccount and per thread

> is one way.  Another way would be to simple cache the authToken for
> the MCC user, and use it to create a new AdWords user when you need
> one.
>
> The v13 version of the API didn't use the ClientLogin API so you can't
> compare it with the functionality in v200909.
>
> Best,
> - Eric
>
> On Apr 9, 2:43 pm, "hov...@gmail.com" <hov...@gmail.com> wrote:
>
>
>
> > Hi Eric,
>
> > So, does that mean that if we want to reuse AdWordUsers and services
> > generated from these users we to cache both (users and services) per

> > eachclientaccount and per each thread?