J'ai une application cliente simple serveur. Tout fonctionne, mais à un moment donné, il faut plus de 5 minutes pour obtenir une réponse du serveur (qui est normal et qu'il doit être comme ça). Le problème est que s'il faut plus de 5 minutes, je continue à obtenir cette exception: Alors je me demandais s'il y a un délai d'attente de prise par défaut sur Windows ou sur la machine virtuelle Java, je pourrais définir? Je ne peux pas changer le code client afin que Utilisation de Windows XP ..
Edit: si j'ai bien compris, c'est que la connexion de socket n'est pas ouverte du côté du client. Sa transmission du serveur. J'ai donc décompilé AllSo le fichier JAR de serveur. Mais je ne peux toujours rien trouver sur le délai d'attente. java.net.sockettimeTimeException: lu expiché .
setingotimeout () n'est pas une option pour moi.
4 Réponses :
Le délai d'attente de socket par défaut est 0, ce qui signifie jamais délai d'attente. S'il est effectif après 5 minutes, cela signifie qu'il a été défini dans le code. Si la source n'est pas disponible et qu'il n'y a pas de configuration, vous pouvez essayer de décompiler la classe et recherchez Depuis les commentaires, et le fait que les recherches ne trouvaient pas d'appels SetSotimeOut (), vous pouvez adopter une approche différente. Il suffit de laisser tomber le temps et écrivez un petit script qui réessayera l'appel au cas où il le ferait. Si vous pouvez appeler votre client à partir de la ligne de commande, vous pouvez analyser la sortie, s'il passe sur stardr. setSotimeout appels.
J'ai décompilé et recherché les appels setsotimeout mais n'a rien trouvé. Il doit être placé quelque part ailleurs alors?
@ hs2d je pense qu'il utilise la valeur par défaut du champ 0
Garder la connexion TCP inutilisée ouverte pendant de longues fois sans trafic n'est pas ce trivial. De nombreux pare-feu / routeurs ferment les ports inutilisés après un délai d'attente.
Une option peut être de mettre en œuvre un protocole de conserve simple d'envoi de paquets factices de temps en temps, mais si vous ne pouvez pas toucher le code client, ce n'est probablement pas une option.
Edit: Je ne suis pas au courant d'une autre façon de remplacer SetSotimeOut () définie dans le code client.
@benez je ne suis pas d'accord. Si le routeur considère la connexion comme une telle ressource précieuse que cela puisse sortir, vous n'avez aucune entreprise qui l'achée pour le garder ouvert. En tout cas, vous devez toujours faire face aux pertes de connexion de toute façon. L'ajout de Pings Keepalive est vraiment une douleur inutile dans le cou.
@EJP Je n'ai pas encore vu une implémentation appropriée pour gérer les pertes de connexion. Il y a des cas où vous attendez des mises à jour réel et vous avez besoin de deux parties constamment connectées à la synchronisation de leurs données. Les pertes de connexion ne sont pas simplement traitées avec une reconnexion simple. Vous manquerez un message important ou allez-y en retard. par exemple. Les marchés boursiers envoient toujours des battements cardiaques et le protocole IRC vous oblige à répondre à un ping avec pong. Et oui, vous devez faire face aux pertes de connexion, mais vous voudrez peut-être les éviter dans certains programmes.
@EJP Ajout de battements de coeur peut être crucial. Il suffit d'imaginer le scénario suivant: après avoir été inactif pendant un certain temps, l'un des ordinateurs a une panne de courant. Avec une déconnexion propre, le protocole TCP / IP notifie l'autre côté de cela, mais en contrastant lorsque l'un des ordinateurs a une panne de courant, alors bien sûr, personne n'est notifié à ce sujet. Et cela ne sera pas détecté automatiquement. Dans de telles situations, selon l'autre ordinateur, la connexion est toujours établie et tout semble bien. Ce n'est que lorsque le client essaie d'envoyer quelque chose, qu'il détectera le problème.
Réponse que 0 est le délai d'attente par défaut n'est pas tout à fait vrai. Depuis par exemple, l'axis2 Client a par défaut de 60 secondes de secondes, il dépendra donc de quel type de mise en œuvre vous utilisez pour faire l'appel.
Pouvez-vous fournir plus de détails? Désolé d'écrire dans la section des réponses mais je n'ai pas assez de réputation pour faire des commentaires :)
En regardant le code ici, je ne peux voir que java.io.inputtream . Donc, la connexion doit être effectuée à partir du serveur au client?
Eh bien, oui, pour Java, la valeur par défaut est infinie, mais une bibliothèque peut changer cela. Peut-être est un indice, HS2D, avez-vous un pot inclus? Ou peut-être, vous pouvez adopter une approche différente, laissez-la simplement sortir et réessayer s'il échoue.
et avez-vous besoin de garder la connexion vivante? Pourquoi ne repensez-vous pas cela pour le rendre plus asynchrone. Ce schéma n'est pas à l'échelle du tout. À un moment donné, tous vos threads disponibles pourraient attendre une réponse longue du serveur.
Il a besoin de garder la connexion en vie s'il veut la lire. Ne peut pas faire la tête ou la queue de tout cela.
Vérifiez si le délai d'attente est configuré à l'aide des propriétés du système.
@Hannobinder, pouvez-vous expliquer ce que vous voulez dire par les propriétés du système?
Je veux dire quelque chose comme Sun.net.Client.defaultreadtimeout < / a>, ou quoi que ce soit peut s'appliquer à la manière de votre client de se connecter.
Les délais d'attente de socket sont définis par le client. «La connexion de socket n'est pas ouverte du côté du client. Sa transmission du serveur 'n'est pas correcte.