The MTurk SDK sorely needs some kind of rate-limiting logic. I have been battling a problem with MTurk where I post a large batch of HITs and then am unable to retrieve the completed assignments because of "Service Unavailable" responses from MTurk. I can only assume that this is because my connection requests are too frequent. This is despite the fact that I have a rate-limiter on my end which ensures that I make no more than 1 connection every n seconds (currently set at 4.5 seconds).
It took me forever to discover that this was actually the problem because the SDK completely concealed the fact that MTurk was returning this error. What I actually saw, in a profiler, was the SDK spinning endlessly in its retry logic. Indeed, what I am seeing on an app that is running RIGHT NOW is that each call to getAllAssignmentsForHIT takes anywhere from 30-45 seconds and then eventually returns nothing. Yet if I sign into my MTurk requester account, I can see that all of the assignments for all of my HITs have indeed been completed.
I can only assume that when this happens, MTurk and the SDK enter into some kind of mutual rate limiting death spiral and nothing makes progress. This is super super frustrating and is costing me (a student, at a university, working on my dissertation) hundreds of dollars per failure. I would gladly implement some kind of exponential backoff on my end, but I get no indication from the API that anything is at all wrong (except that calls take a very long time), which would make doing this a challenge.
I don't know if this is a feature request or a bug. Any help that you can offer would be appreciated. I will gladly fork over logs, source code, etc., if you want to try to reproduce this.
Never mind. I just discovered that I was passing "Server.ServiceUnavailable" to your retry mechanism. I have now disable this, which in principle means that I can implement my own backoff mechanism since the SDK ought to just throw an exception. Feel free to close this ticket.