Wrap all calls to responsys with a Timeout::timeout(X) {}

[evantahler]

I've noticed that responsys' API often becomes un-responsive when you have many simultaneous connections. For example, maybe you have 40 resque workers trying to update responsys with a new column of data about your users... The client doesn't see a 500, error, or timeout. It just... hangs. I've seen processes last over a day. This can "clog" up your resque queues (or your unicorns) and cause bad things to happen.

In all cases, I would prefer that an exception be truly thrown so it can be handled in the normal way (error to users, resque-retry, etc).

I believe that this is actually an error with savon, but we have the opportunity to provide safety to users of the gem.

[florrain]

I agree that the API response time can completely diverge some time. We also have nightly quite busy jobs but we're catching Savon timeout exceptions though.

We also added the ability to set the Savon timeout values when initializing the Gem with these keys : open_timeout and read_timeout if you're timeout is too high.

A typical stack we have is that the timeout is fired by HTTPClient and raised through Savon::SOAPFault:

Savon::SOAPFault: (soapenv:Server) UnexpectedErrorFault
HTTPClient::ConnectTimeoutError: execution expired

If you want to catch the existing timeout fired by Savon or make sure than any hanging calls is not waiting more than X seconds inside the Gem, I'd say why not.