Donnez à chaque worker HtmlUnit un proxy stable

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

Attribuez un HtmlUnit WebClient configuré à chaque identité de navigation simultanée. Ses WebClientOptions détiennent la ProxyConfig ; traitez la route comme fixe pendant l'exécution de la tâche. Une file de tâches partagée n'exige pas un navigateur mutable partagé. Pour les contrôles autorisés de pages publiques avec HTTP ProxyConfig, choisissez des points de terminaison candidats dans la liste de proxys HTTP avant de les attribuer aux workers.

Conservez la page, les chargements ultérieurs et l'état de session avec ce client. Changer les options de proxy ne peut pas transplanter des connexions déjà établies. Des clients séparés créent aussi un état de navigateur séparé ; planifiez donc toute connexion partagée prévue au lieu de supposer que le routage seul détermine l'identité. L'authentification du proxy utilise l'interface de la version installée de HtmlUnit et reste distincte de la connexion au site web.

Définissez l'achèvement avant de rendre un navigateur à un pool. La réponse de niveau supérieur peut arriver alors que des scripts ou des requêtes d'arrière-plan continuent. Terminez ou annulez ce travail, effacez l'état que l'identité suivante ne doit pas hériter et retirez le client si cette limite ne peut pas être établie de manière fiable.

Limitez le nombre de clients actifs et fermez les WebClients terminés. Un navigateur analyse et peut exécuter des scripts, ce qui coûte plus qu'un simple transfert. Pour une tâche qui n'a besoin que du HTML renvoyé, un client HTTP plus petit peut prendre en charge davantage de requêtes simultanées dans le même budget de ressources.