Eén worker vindt een bruikbare proxy. Je geeft het adres terug, roept cancel aan op de andere futures en verwacht dat de netwerkactiviteit stopt. Dat gebeurt misschien niet.

Een Future kan worden geannuleerd voordat de callable begint. Zodra een thread al een verzoek uitvoert, onderbreekt het annuleren van de Future die socketbewerking niet. De worker heeft zijn eigen begrensde netwerkbewerking en opruimpad nodig.

De levensduur van de executor is ook belangrijk. Een ThreadPoolExecutor-context verlaten wacht tot het werk klaar is. Eén snel resultaat vinden en dan op meerdere trage workers wachten kan de totale vertraging van de aanroeper er heel anders laten uitzien dan de gerapporteerde latency van de winnaar.

Begrens de race voordat die begint

  • Beperk het aantal gelijktijdige controles in plaats van een onbeperkte openbare lijst in te dienen. De gratis proxylijst levert kandidaten voor de invoer van de controleur, waarbij het protocol van elk eindpunt voor de worker wordt bewaard.
  • Geef elk verzoek een passend verbindings- en leesbeleid.
  • Geef de aanroeper een algeheel beslissingsbudget.
  • Bepaal wie resultaten van workers die de beslissing overleven, leegmaakt of sluit.

Korter wachten op een Future is niet hetzelfde als het onderliggende verzoek korter maken. Evenzo maakt het loslaten van het resultaat niet onmiddellijk elke netwerkbron vrij.

Het eerste succesvolle resultaat is ook alleen de eerste succesvolle controle. Het kan afhangen van planning, gecachte verbindingen en de specifieke controlebestemming. Het bewijst niet dat het eindpunt universeel het snelst is of dat de echte taak zal slagen.

Vaak is een kleine aangehouden pool met recente waarnemingen eenvoudiger dan voor elke download tegen de hele lijst racen. Gebruik het resultaat van de echte bewerking om het record bij te werken, met een gecontroleerd herstelbeleid voor fouten. De voorcontrole moet zijn kosten verdienen in plaats van uit gewoonte elke taak te verdubbelen.

Gerelateerde artikelen