3

Environment

We have a solution running that interacts with the Twitter API. The Twitter API endpoint is:

api.twitter.com

We make many calls to the endpoint but we are hitting very rarely any API Limits defined by Twitter.

I presume that Twitter has a Load balancer set up on that URL and redirect internally to different machines.

The solution is a .Net application, partially an executable that does polling of data and a Web application that is used to reply and publish Tweets.

The Issue

Once in a week (sometimes more) for a few hours we get the following exception logged in the log files from our executable and web application.

Inner Exception : System.Net.WebException: Unable to connect to the remote    
server ---> System.Net.Sockets.SocketException: A connection attempt failed 
because the connected party did not properly respond after a period of time, 
or established connection failed because connected host has failed to 
respond 185.45.5.33:443
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.GetResponse()
at Hammock.Web.WebQuery.ExecuteGetDeleteHeadOptions(WebRequest request, WebException& exception) in f:\src\hammock\src\net35\Hammock\Web\WebQuery.cs:line 1021

... Ommited rest of exception ...

When I do a NSLOOKUP from the Server itself I have the following result

>nslookup api.twitter.com
Server:  4201082000200000000g00g021.ip.ssc.net
Address:  2001:820:2::9:218

Non-authoritative answer:
Name:    api.twitter.com
Addresses:  185.45.5.33
            185.45.5.44

Every time i do this lookup the faulty 185.45.5.33 server is listed, and there is only one alternative IP address present.

Note : We only have these two IP addresses from our production server, from other machines (in different countries) the nslookup returns at least 4 IP addresses in a 199.* range.

>nslookup api.twitter.com
Server:  kdns1.task.gda.pl
Address:  213.192.64.1

Non-authoritative answer:
Name:    api.twitter.com
Addresses:  199.16.156.104
          199.16.156.72
          199.16.156.231
          199.16.156.8

The Solution ?

I have tried during these faulty periods to edit the C:\Windows\System32\Drivers\etc\hosts file with this line

# localhost name resolution is handled within DNS itself.
#   127.0.0.1       localhost
#   ::1             localhost
    185.45.5.44     api.twitter.com

But this doesn't seem to work, the issues just continues. Although the issue is probably on Twitter their Servers, it does break our functionality to totally stop from working. So we need to be more pro active instead of waiting till Twitter resolves the issue.

This is probably not even the best way to solve this issue but we have For now. We recruited someone skilled for these ops issues, but he wont start before December. So any kind advice for a limited experienced person would be much appreciated to have a temporary solution for this issue.

So does anyone have a suggestion or a lead that might help us out to troubleshoot this on our side in the best way possible ?

I don't mind jumping into reading articles but a lead or a push in the right direction would be a great help.

Thank you for your time

1 Answer 1

1

Short answer: no.

There is very little you can do to mitigate third-party provider issues, other than to notify your users that there are upstream issues.

You could display descriptive error messages such as "There was a problem communicating with Twitter, please hold on.", or silently discarding the error and retry after a time.

For longer periods of outage, I would suggest displaying a notice to your users globally within the application.

In addition to this, I severely doubt that Twitter's API has that many issues - you are likely being rate-limited in some way. I would strongly suggest that you contact Twitter and raise a support case.

2
  • I have been screening all the log files multiple times for finding concentrations of limit exceeding and we programmed very defensively to not hit the limits since Twitter API provides a good mechanism to get the status quo on our API limit status. Of course we can always have leak, but we didn't scale recently with users and changes in a solution that worked well for a long time. So it can never be excluded that, that is the issue, but I am very confident :s. But Appreciate the feedback.
    – Segers-Ian
    Commented Sep 25, 2015 at 9:02
  • So as follow up, you did not entirely answer the question but you were correct on that Twitter could not have been the culprit itself. After lots of troubleshooting with the admins from the Server Park that hots our hardware we discovered that a former employee had requested a firewall block (by the Hosting company itself) on all low port numbers for outgoing traffic. After we removed it everything went to normal.
    – Segers-Ian
    Commented Oct 2, 2015 at 13:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .