All task components of a workflow will always poll the SWF service using long polling. If an action is available for a particular activity or decision task, the service will immediately respond. When there are no tasks, the long polling request will allow the service to wait for a message about an action for up to 60 seconds. After 60 seconds, the service will respond with an empty request and close the connection. If an empty response is received by the task worker, then the worker will need to poll for the task again.

When developing a worker, the developers might implement an exponential back-off algorithm for polling, which will delay the polling attempts for longer and longer if an empty response is received. Make sure you understand that there is a possibility of a very long delay between polls due to exponential back-off when diagnosing the SWF. If the developer implements the delay by doubling it every time, the delay might quickly get very long. 

For example, every time an empty response is received, the application waits for an amount equal to the poll length before polling again. Once a second empty response in a row is received, it will double the wait time before polling again. In this example, the poll length is one minute, so the back-off algorithm will make the application wait for another minute before polling again. If another empty response is received, then the application will double the wait time to two minutes before polling again. If a third empty response is received, then the wait time will double to 4 minutes and then 8, 16, 32 , and so on. As you can see, this kind of approach works well when polls are short but with long poll times, it might get very long very quickly.