automatically refresh token if calls fail due to expired token

[imurdock]

[ghost]

That would be nice, we've added to fallback call in our code to handle this.

A strong typed exception to catch this would also be cleaner.

++ Chris

CreateResponse response;
try {
    response = getTriggerSendResponse(request);
} catch (Exception e) {
    try {
        LOGGER.trace("Refreshing Exact Target token on error '{}' ...", e.getMessage());
        getClient().refreshToken();

        response = getTriggerSendResponse(request);
    } catch (Exception sub) {
        LOGGER.error(sub.getMessage(), sub);
        throw new RuntimeException("Can't refresh Exact Target token!", sub);
    }
}

[Geooorg]

Does this issue still persist?

I'm currently overwhelmed by Exceptions like this: ... Caused by: com.exacttarget.fuelsdk.ETSdkException: refreshToken == null at com.exacttarget.fuelsdk.ETClient.refreshToken(ETClient.java:347) ~[fuelsdk-1.1.2.jar:na] at com.exacttarget.fuelsdk.ETDataExtension.retrieveColumns(ETDataExtension.java:743) ~[fuelsdk-1.1.2.jar:na] at com.exacttarget.fuelsdk.ETDataExtension.retrieveColumnNames(ETDataExtension.java:778) ~[fuelsdk-1.1.2.jar:na] at com.exacttarget.fuelsdk.ETDataExtension.select(ETDataExtension.java:335) ~[fuelsdk-1.1.2.jar:na]

[amagar088]

@Geooorg yeah this has been resolved. There is a tag in fuelsdk.properties that needs to be modified to get this working. Please add "accessType=offline" to get it working. Please let me know, if that helps.

[neeraji2it]

Am facing the following issue when I run the
"https://auth.exacttargetapis.com/v1/requestToken" Input : with values of my exact target installed package { "clientId": "gyjzvytv7ukqtfn3x2qdyfsn", "clientSecret": "", "refreshToken": "************", "accessType": "offline" } Output : { "message": "Unauthorized", "errorcode": 1, "documentation": "" }

[sharif26]

Try this: POST https://auth.exacttargetapis.com/v1/requestToken?legacy=1 HEADER Content-Type: application/json BODY { "clientId": "xxxx", "clientSecret": "yyyy" }

[mariogalic]

After setting accessType=offline it worked for days but then eventually the following error was again thrown:

javax.xml.ws.soap.SOAPFaultException: Token Expired

This is breaking our production where we have thousands of request on Marketing Cloud per day. Is there anything we can do to help with this?

We are using version v1.2.2

[sharif26]

@neeraji2it If you provide accessType=offline and also refreshToken, then please make sure that refreshToken is not expired. Try using accessType=offline without refreshToken.

@mario-galic Could you please elaborate what exactly happened for which MC Object, provide some (debug) logs if possible.

[mariogalic]

@sharif26 In the following code we are using Subscriber, SubscriberList, ETClient.getSoapConnection:

  @Provides
  @Singleton
  def getETClient(config: Config): ETClient = {
    val etConf = new ETConfiguration()
    etConf.set("accessType", "offline") // DO NOT CHANGE THIS: https://github.com/salesforce-marketingcloud/FuelSDK-Java/issues/5#issuecomment-261360052
    etConf.set("clientId", config.ExactTarget.clientId)
    etConf.set("clientSecret", config.ExactTarget.clientSecret)
    new ETClient(etConf)
  }

  def subscribe(email: String, listId: String): Try[CreateResponse] = {
    val soapClient = etClient.getSoapConnection.getSoap

    val subscriberList = new SubscriberList
    subscriberList.setId(listId.toInt)
    subscriberList.setStatus(SubscriberStatus.ACTIVE)

    val subscriber = new Subscriber
    subscriber.setEmailAddress(email)
    subscriber.setSubscriberKey(email)
    subscriber.setStatus(SubscriberStatus.ACTIVE)
    subscriber.getLists.add(subscriberList)

    val createOptions = new CreateOptions
    val saveOption = new SaveOption
    saveOption.setPropertyName("*")
    saveOption.setSaveAction(SaveAction.UPDATE_ADD)
    val saveOptions = new SaveOptions
    saveOptions.getSaveOption.add(saveOption)
    createOptions.setSaveOptions(saveOptions)

    val createRequest = new CreateRequest
    createRequest.getObjects.add(subscriber)
    createRequest.setOptions(createOptions)

    Try(soapClient.create(createRequest))
  }

The following crash log graph shows it works for few days and then it fails with javax.xml.ws.soap.SOAPFaultException: Token Expired (the bars indicate exception frequency)

We have also tried scheduling token refresh every 30 min, but that did not help:

actorSystem.scheduler.schedule(5.seconds, 30.minutes) { etClient.refreshToken() }

Just today it failed again where token would not refresh for 10+ hours in production, so unfortunately we had to revert the client.

[sharif26]

@mario-galic which JDK version are you using? So is it happening when you ran code for long time (more than 10 hour or so)? Did you try to refresh token less than 30 min, e.g. 20 min? I need some actual logs, like FuelSDK-Java file name, line no, etc where it is actually failing(similar to Nov 17, 2016 comment above).

[mariogalic]

@sharif26 Many thanks for helping but unfortunately we do not have full stack trace of the error, and since we have now removed the client we will be unable to provide it (we should have put in better logging). The code would run fine for days before the exception. We did not try refreshing every 20 min, we thought it expires after 60 min. JDK version:

$ java -version
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

One thing worth noting is that our app is load balanced across multiple (3+) servers, and the exception would start happening on one server but other servers would be fine, that is, the token would not stop refreshing on all servers at the same time.

[sharif26]

Looks like it happens when it is ran for a longer period of time which makes it harder to simulate the issue. It is also difficult to analyze without stack trace exception log.

[sharif26]

@mario-galic Did that happen to previous Fuel Sdk Java version as well? Can you test it somehow. Do you think your particular issue relates with previous comments on this thread?

[levischuckeats]

This seems to still be an issue.

Attempting to use Spring retry with @Recover to compensate.

[levischuckeats]

Unable to get that to work. Attempted try catch on SOAPFaultException, which calls client.refreshToken();, this however threw its own exception.