After N consecutive timeouts to the same FDM host, the city automation keeps issuing immediate new attempts and burning its timeout budget. What robust timeout handling should it apply next?
Select an answer to reveal the explanation.
Short Explanation
If the same door never opens, stop ringing it every second. Cool down, fail fast for a bit, then probe once—saving the timeout budget for when the host might actually answer.
Full Explanation
After N consecutive timeouts to the same FDM host, continuing immediate new attempts burns the timeout budget on a path that is already failing. Robust handling opens a short cool-down (fail fast for a period), then probes once before resuming normal call rates. That conserves worker time and reduces load on a sick appliance while still allowing recovery detection.
Instrumenting AppDynamics dashboards as the only next control-flow step may aid observability but does not change the client’s retry/cool-down behavior the question asks for. Relocating the entire application to a second continent is a site-HA project, not the immediate timeout-handling branch after consecutive failures. Removing all timeouts turns consecutive failures into infinite hangs and destroys the budget concept.
Exam caveat: cool-down is not the same as infinite abandon—define when probing resumes and when the unit becomes unrecoverable for operators. Operational check: after N FDM timeouts, assert the client stops immediate retries, waits the cool-down, issues a single probe, and only then returns to steady-state pacing if the probe succeeds. During cool-down, fail fast on new non-critical calls so other municipal work is not stuck behind known-bad FDM attempts. The probe should be a cheap read when available; only reopen full create/update traffic after a successful probe within policy.