I have an imp that has been reporting data for many months, suddenly I’m getting a status code of 28 to my HTTP POSTs as of about three hours ago. That looks like it’s a timeout error, but our platform is pretty definitely up. Is there anything I can do about this?
Agent Code: local response = http.post( "https://m2.exosite.com/onep:v1/stack/alias", { "Content-Type": "application/x-www-form-urlencoded", "X-Exosite-CIK": cik }, http.urlencode(data) ).sendsync(); if(response.statuscode != 204 || response.statuscode == 200){ server.error("Could not write to the OnePlatform. HTTP Response Code: "+response.statuscode) }
Log:
2014-08-27 13:07:59 UTC-5 [Agent] Write to temp: 25.75
2014-08-27 13:12:59 UTC-5 [Agent] Write to temp: 25.875
2014-08-27 13:17:59 UTC-5 [Agent] Write to temp: 25.875
2014-08-27 13:27:59 UTC-5 [Agent] ERROR: Could not write to the OnePlatform. HTTP Response Code: 28
2014-08-27 13:27:59 UTC-5 [Agent] Write to temp: 25.75
2014-08-27 13:37:59 UTC-5 [Agent] ERROR: Could not write to the OnePlatform. HTTP Response Code: 28
2014-08-27 13:37:59 UTC-5 [Agent] Write to temp: 26.125
2014-08-27 13:47:59 UTC-5 [Agent] ERROR: Could not write to the OnePlatform. HTTP Response Code: 28
2014-08-27 13:47:59 UTC-5 [Agent] Write to temp: 26
From the sendsync() docs: “If the statuscode is 100 or higher, it is a real HTTP status code returned from the server; if it is between 0 and 99, there was an error sending the request.”
Errors 0-99 match curl errors: 28 is “Operation timeout. The specified time-out period was reached according to the conditions.”
You should double-check your HTTP request details, I think.
Yep, I’m aware of that, but as I said, that code had been working for months and suddenly stopped working without me touching anything. I’ve also got half a dozen things sitting on my desk (and a couple thousand customers’ devices) using the same API and none of them had a problem. So, I assume it was an imp platform issue, but I can’t really prove that for sure. I had some strange DNS issues a couple weeks ago (my DNS queries weren’t giving me the actual IP for the imp servers) so maybe this was just another similar issue.
It seems to have righted itself (at about 20:27:58 UTC-5 last night), but if there is any way to still figure out what was going wrong, I’d still like to know.
Obviously, reachability depends from where on the internet you’re trying to call from; without being able to go back in time, I can’t determine where the routing was broken, but it appears that between 2014-08-27T18:27:59.594Z and 2014-08-28T01:27:58.573Z no requests went through to that site from our servers.
Given that exosite, at first glance, appears to be hosted within amazon AWS, that’s even freakier…
I got the same Status code 28 on a synchronous GET call to an Azure hosted Web API. Has been working perfectly for months. This exception was caught and the request was resend after 15secs which was prcessed as usual.
As it was successfully caught and handled, I’m not too worried, but is this something that we need to keep in mind => Agent http requests to normally very reliable hosts (Azure) sometimes failing ?