Depuis que le système SEOTcs a mis à jour l'algorithme de scoring SEO le 24 novembre, un problème qui me dérange est survenu. L'erreur suivante sera souvent signalée lors de l'exécution de la tâche de travail de données Java :
"03/12/2011 18:00:32 DefaultHttpClient [INFO] Exception d'E/S (java.net.SocketException) interceptée lors du traitement de la demande : connexion réinitialisée par un homologue : erreur d'écriture de socket
2011-12-03 18:00:32 DefaultHttpClient [INFO] Nouvelle tentative de demande »…
À cette fin, j'ai recherché sur certains sites Web en chinois et en anglais, fouillé dans tous les coins que j'ai pu trouver et découvert la raison pour laquelle cette situation se produit. Cette exception Java peut se produire à la fois du côté client et du côté serveur. deux raisons :
1. Si le Socket à une extrémité est fermé (ou activement fermé, ou fermé en raison d'une sortie anormale), l'autre extrémité envoie toujours des données et le premier paquet de données envoyé déclenche cette exception (réinitialisation de la connexion par son homologue).
2. Une extrémité se termine, mais la connexion n'est pas fermée lors de la sortie. Si l'autre extrémité lit les données de la connexion, l'exception (réinitialisation de la connexion) sera levée. En termes simples, cela est dû aux opérations de lecture et d'écriture après la déconnexion de la connexion.
J'ai donc simplement pensé que cela pourrait être résolu en définissant des délais d'attente pour les sockets :
Mais après la mise en place, la situation est toujours la même.
Ce problème me préoccupe depuis plusieurs jours, et je réfléchis et fais des tests comparatifs chaque jour afin de découvrir le code qui a causé ce problème. Je ne peux m'empêcher de penser, en partant du même nombre de mots-clés, pourquoi. il n'y a eu aucune erreur dans les données de classement des requêtes par lots précédentes, mais des erreurs ont été fréquemment signalées récemment. Pourquoi ? Le site Web de l'interface demandée bloque-t-il l'adresse IP de notre serveur ? Cette raison n'est pas très suffisante. Elle doit être causée par l'échec de la libération correcte de la connexion quelque part dans le programme !
Sous la direction de cette idée, après plusieurs jours de travail acharné et de pratique continue, j'ai enfin découvert aujourd'hui l'essence du problème, qui est causé par la méthode de la minuterie ! La situation est la suivante. Au cours des derniers jours, j'ai déclenché manuellement certaines tâches par lots et j'ai constaté que lorsque la valeur de classement du filtre est de 100, l'erreur java.net.SocketException : la réinitialisation de la connexion dans Java continuera à être générée et l'écran sera affiché. Le rafraîchissement est particulièrement puissant, après avoir soigneusement comparé ce code de minuterie.
Finalement, j'ai soudain réalisé que oui ! Il y a un problème ici, laissez-moi l'analyser moi-même :
Une valeur de fonction, la valeur qu'elle renvoie est une valeur critique, mais dans ma méthode de minuterie, on estime que si la valeur renvoyée est une valeur critique, elle la forcera à continuer d'exécuter cette méthode dans les 10 secondes, et cette méthode consiste à Pour obtenir une donnée spécifique du code source d'une page, chaque exécution de cette méthode consommera des dizaines de millisecondes, ce qui équivaut à établir une connexion socket dans ce temps, mais comme elle renvoie toujours la valeur critique, cette méthode va donc continuellement établissez une connexion socket dans les 10 secondes pour obtenir des données. Si cette méthode prend environ 80 ms à exécuter à chaque fois (après test, le temps d'exécution de chacune de ces méthodes est d'environ 80 ms), en 10 secondes. Dans ce délai, 10*1000/80 = 125 connexions de socket seront établies, soit 12,5 connexions de socket par seconde. De plus, puisqu'il s'agit d'un programme de filtrage, plusieurs valeurs critiques apparaîtront ensemble en continu, donc, en quelques secondes, le nombre de sockets. les connexions à la même page du site Web monteront en flèche, atteignant des centaines, voire des milliers, ce qui rendra trop élevé le nombre de connexions de requêtes en attente de traitement :
Pourquoi avez-vous utilisé cette méthode de minuterie pour exécuter une méthode plusieurs fois en premier lieu ? La raison était d'obtenir une valeur stable des données. Mais maintenant que j'y pense, l'impact négatif est si coûteux et l'effet ne peut pas être sous-estimé. , mais après plusieurs jours d'analyses et de tests approfondis, le coupable a finalement été découvert. Une fois le problème résolu, mon esprit s'est soudainement senti soulagé et j'ai pu dormir paisiblement. . .