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" />
:
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:
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?
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.