always put timeouts on your connection code..number of times I see shit blocked forever ..and we know it’s not good to have your shit blocked

  • 2
    If I see this 10 minutes before, I wouldn't broke my computer with infinite API call
  • 1
    This is why api calls shoud happen in separate threads and results should reach main thread via callbacks. Main thread should never be blocked.
  • 1
    Some of our Devs randomly pick some http lib and use the default configuration. And default configuration is to wait forever.

    Entire Queue gets blocked and it keeps growing like Mountain
  • 0
    Maybe no.

    What most devs do wrong are 2 fundamental things:

    1) logging
    2) exception and error handling

    Usually a TCP connection cannot stay forever and if it does there is something very wrong. "Popping" timeouts here, there, everywhere is a nightmare of maintenance.

    Abstract properly the HTTP client and set a global timeout with an option to override it (which should be used sparingly).

    Coming back to exception handling... Close the connection properly in the timeout.

    Otherwise you might end up in the situation that system A ends up with massive open connections spawned by B which has a timeout shredding the connections to A after timeout and not closing it properly...

    Fun to debug. Especially when the dev sprinkled literally the timeouts seemingly generated by a random number all across the codebase.
  • 0
    @IntrusionCM well I’m primarily talking about database connections which can block a client thread forever and exhaust the pool.
Add Comment