1

I am trying to fix a number of issues our company's platform has with an integration with Adobe Connect. One that has me perplexed is intermittent failures with the login method. We have one client whose credentials fail regularly, but not always. I have the login method call in a try/catch block with the CFHTTP output dumped into an email and sent to me. Here is a sample failure, using the cfhttp tag <cfhttp url="#httpCall#" method="GET" />:

enter image description here

However, when I invoke the login method via browser, using the URL attribute that is invoked by the CFHTTP tag (eg. http://[host].adobeconnect.com/api/xml?action=login&login=[username]&password=[password]&account-id=[id]), I get the following callback:

<results>
     <status code="ok"/>
</results>

The request header I get back is as follows: enter image description here

So, there is nothing wrong with the credentials passed in, nor with the response: it does return a MIME type of text/xml, when called directly. This points to an issue with the CFHTTP tag, and potentially with the Adobe Connect account we've set up for one of our clients, or both. This does not happen with every call made to Adobe Connect via CFHTTP, and it does seem to happen more often with the account we've set up for one particular client, than for others we've set up. We did get this with other accounts, but when I mitigated it by repeating calls to the API login method upon failure to return a MIME type of text/xml, we are now only getting it with this account.

What can I do with the CFHTTP tag for this API call to get around this problem?

Max Monclair
  • 91
  • 6

3 Answers3

1

The error detail is "connection Failure" + "unknown host", indicating the client is not getting an error from the Adobe Connect server, rather is unable to communicate with it at all.

You've redacted the full hostname so I can't test its validity, but I would first verify that it is correct and resolvable (with nslookup or dig) from your workstation, then do the same from the failing client machine. Investigate the failing client's DNS resolution: is it querying a reliable name server, etc. The symptom could indicate the client is misconfigured, e.g. has the wrong account domain, but the intermittent nature suggests otherwise.

You might also check whether a proxy is configured or clear the CF DNS resolver cache. Ref this question for more detail.

Brant
  • 181
  • 6
  • The CF DNS resolver cache is one angle I hadn't considered. One possible angle I hadn't considered before is whether I should rework the legacy code using CFHTTP to call the API and use CFINVOKE instead. I'll take a look at your suggestion and also try changing how the API is called. – Max Monclair Jun 03 '15 at 17:09
  • Since the error is a name resolution failure and inconsistent across clients, another thing you might investigate is the domain names involved. Hosted Adobe Connect uses 2 FQDNs: the account domain name and the cluster domain name. The account domain name is an CNAME alias to the cluster name (e.g. max.adobeconnect.com -> na1cps.adobeconnect.com). If the account domain name were changed at some point, the old name might not be valid anymore. (The account could also be moved to a different cluster, e.g. na1cps to na2cps, but that shouldn't result an unknown host error.) – Brant Jun 04 '15 at 17:18
0

Brant, the article you pointed me to didn't have the whole answer, but it did give me a clue to it. In addition to limiting the JVM's DNS cache TTL, which did cut down the problem though not eliminating it, the Windows server's DHCP settings referenced an internal DNS server that has been problematic. When we changed these settings to a more reliable DNS server, the problem with resolving the Adobe Connect login method stopped. Overriding DHCP settings

Max Monclair
  • 91
  • 6
  • Glad you got it resolved! FWIW, I think the bit where I said "Investigate the failing client's DNS resolution: is it querying a reliable name server" in my answer addressed that aspect. Would appreciate an acceptance on the answer. =) – Brant Jun 24 '15 at 22:29
0

Try to keep a / at the end of url, so finally your code should be 

<cfhttp url="#httpCall#/" method="GET" />
user3440782
  • 144
  • 1
  • 14