A city worker process calls a silent Firepower FDM controller and waits forever, pinning the worker while other municipal jobs starve. What should the REST consumer set to avoid that hang?
Select an answer to reveal the explanation.
Short Explanation
Waiting forever on a quiet phone line ties up the clerk and the whole counter. A finite connect/read deadline turns silence into a timeout you can retry or fail cleanly.
Full Explanation
A REST consumer that waits forever on a silent Firepower FDM controller pins the worker and starves other municipal jobs. Setting finite connect and read timeouts turns prolonged silence into a raised error the process can catch, retry with policy, or fail cleanly—freeing the worker. Connect timeout bounds dialing the socket; read timeout bounds waiting for bytes after the connection is up.
An infinite connect deadline deliberately recreates the hang. Placing a load-balancer HA pair in front of every Python process may improve controller reachability architecture but does not stop a single client from blocking indefinitely on one attempt. Restricting to HTTP/1.0 because “timeouts exist only in older protocols” is false; timeouts are client (and sometimes proxy) behaviors independent of that version myth.
Exam caveat: a timeout is not the same as an HTTP error status—you may get no status line at all when the read deadline fires. Operational check: configure explicit connect and read deadlines on the FDM client session, simulate a black-holed host in a test harness, and confirm the worker exits the wait and releases capacity instead of pinning forever. Separate connect versus read values when the library allows it: a fast-fail connect protects against black-hole routes, while a slightly longer read accommodates large FDM config payloads without inviting infinite waits. Document those deadlines in the municipal runbook so on-call knows a timeout is expected failure, not a hung clerk process.