Gib jedem HtmlUnit-Worker einen stabilen Proxy

job A → WebClient A → proxy A → destination
job B → WebClient B → proxy B → destination

Weise jeder gleichzeitigen Browsing-Identität einen konfigurierten HtmlUnit WebClient zu. Dessen WebClientOptions besitzt die ProxyConfig; behandle die Route als fest, solange der Auftrag läuft. Eine gemeinsame Auftragswarteschlange erfordert keinen gemeinsamen veränderlichen Browser. Für erlaubte Prüfungen öffentlicher Seiten mit HTTP ProxyConfig wähle Kandidaten-Endpunkte aus der HTTP-Proxy-Liste, bevor du sie Workern zuweist.

Behalte die Seite, spätere Ladevorgänge und den Sitzungszustand bei diesem Client. Das Ändern von Proxyoptionen kann bestehende Verbindungen nicht übertragen. Getrennte Clients erzeugen auch getrennten Browserzustand; plane daher jede beabsichtigte gemeinsame Anmeldung, statt anzunehmen, dass allein das Routing die Identität bestimmt. Die Proxy-Authentifizierung nutzt die Schnittstelle der installierten HtmlUnit-Version und bleibt von der Website-Anmeldung getrennt.

Definiere den Abschluss, bevor ein Browser in einen Pool zurückkehrt. Die Antwort der obersten Ebene kann eintreffen, während Skripte oder Hintergrundanfragen weiterlaufen. Beende oder brich diese Arbeit ab, lösche Zustand, den die nächste Identität nicht erben darf, und nimm den Client außer Betrieb, wenn diese Grenze nicht zuverlässig hergestellt werden kann.

Begrenze die Anzahl aktiver Clients und schließe abgeschlossene WebClients. Ein Browser analysiert und führt möglicherweise Skripte aus, was mehr kostet als eine reine Übertragung. Für einen Auftrag, der nur zurückgegebenes HTML benötigt, kann ein kleinerer HTTP-Client mehr gleichzeitige Anfragen innerhalb desselben Ressourcenbudgets unterstützen.