Forum Discussion

Alscion_68122's avatar
Icon for Nimbostratus rankNimbostratus
Feb 01, 2012

iControl timeout

Hi all,



Where can I configure the iControl timeout to exexute a command?



I have two BigIPs driven by iControl. iControl periodically sends synchronisation instruction on the active BigIP. But I have many objects on my boxes and the synchronisation took more than 5 minutes (~ 5.20, 5.50) and the timeout of iControl (seems to be 5 mn) is triggered.



How can I change this 5 minutes timeout?







5 Replies

  • Probably a knob on whatever method you are using to access iControl. If you are using pycontrol, which uses suds as its SOAP library, you can probably set the suds client timeout.



    IE. See Matt Cauthorn's post on the Fedora Suds mailing list:




  • mhite is right. The timeout is a property of the client library you are using. What language are you using for iControl? I believe this setting is configurable in .Net and Java but I'm not sure about the other languages.
  • Hi,



    Thanks for your feedback.



    We use Java, how can we set this timeout?



  • I included the code in the iControl java library but unfortunately didn't expose it outside of the iControl.Interfaces class. There is an internal variable m_timeout that defaults to 60 seconds.



    private int m_timeout = 60000; // 60000 ms.




    The *BindingStub classes I create as members in the iControl.Interfaces class are derived from org.apache.axis.client.Stub which has a setTimeout() method.




    In the interfaces class, there is another private method called setupInterface(org.apache.axis.client.Stub stub). In there, I'm setting the timeout.




    You could always call the timeout method directly on the object








    I haven't tried it but it should work.






  • 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