I actually think we may want to look at the problem you're trying to solve. Note that what we're talking about here (in all cases, regardless of the language) are *transport* timeouts. It's likely that you're being caught with such a timeout given the length of those sync jobs. Note that this can happen in at minimum four different spots: the client stack, the client library (via socket options set), the bigip stack on the management port, and the Apache/iControl timeouts set there (which translate to socket options as well). Intermediate devices can do it too, of course.
So, rewinding a bit - what is the nature of this workflow, and is it worth considering other options to solve the problem? For scheduled jobs like this BigIP has some solid native facilities to manage this type of thing. But in the absence of more info it's hard not to speculate.
--Matt Cauthorn