FireBird : INET/inet_error

Bonjour à tous,

Chez un client, j'ai une application Delphi Seattle/FireBird 3 qui tourne sous un serveur VM avec une vingtaine des clients connectés par TSE /Intranet.

Dans le dossier FireBird (FireBird.Log), je trouve des messages d'erreurs jamais systématique ou spécifique à une connexion :

Citation:

---

INET/inet_error: read errno = 10054, client host = server_vm, address = 127.0.0.1/53795, user = jean

---

Que signifie ce message, forcement, un problème de connexion ou une autre raison ?

Est-il possible d'intercepter ces erreurs dans mon appli svp ?

Cordialement

Citation:

---

Envoyé par fveto

Bonjour à tous,

Chez un client, j'ai une application Delphi Seattle/FireBird 3 qui tourne sous un serveur VM avec une vingtaine des clients connectés par TSE /Intranet.

Dans le dossier FireBird (FireBird.Log), je trouve des messages d'erreurs jamais systématique ou spécifique à une connexion :



Que signifie ce message, forcement, un problème de connexion ou une autre raison ?

Est-il possible d'intercepter ces erreurs dans mon appli svp ?

Cordialement

---

10054 c'est une erreur winsock : WSAECONNRESET

Citation:

---

Connexion réinitialisée par l'homologue.
une connexion existante a dû être fermée par l’hôte distant. Cela se produit généralement si l’application homologue sur l’hôte distant est soudainement arrêtée, que l’hôte est redémarré, que l’hôte ou l’interface réseau distante est désactivé, ou que l’hôte distant utilise une fermeture matérielle (consultez setsockopt pour plus d’informations sur l’option SO_LINGER sur le socket distant). Cette erreur peut également se produire si une connexion a été interrompue en raison d’une activité de maintien en état de la détection d’un échec alors qu’une ou plusieurs opérations sont en cours. Les opérations qui étaient en cours échouent avec WSAENETRESET. Les opérations suivantes échouent avec WSAECONNRESET.

---

ça doit correspondre au niveau du client à une déconnexion donc...je suppose que ça peut se produire aussi quand l'application plante, ou que tu la tues car c'est vraiment au niveau socket.

Merci pour la réponse !!!

Je pense que certains utilisateurs ferment la session TSE de façon sauvage (sans fermer l'application).

Cordialement

A savoir, à l'ouverture d'un TSE, les fenêtres reçoivent RecreateWnd ce qui libère les contrôles Windows de la fenêtre et les récréent, par exemple un TListView ou TTreeView est reconstruire, tous les items de dedans ... ayant eu cela a géré récemment, il faut voir si cela peut avoir un impact que les TWinControl soit recréés.

A la fermeture de la session TSE, je ne sais pas exactement ce que fait Windows mais il dégage des ressources mais le programme tourne dans un bureau virtuel sans GDI mais il peut continuer à vivre.
Après, as-tu sur ton Serveur TSE une mise en pause des WM, un Backup nocturne par exemple, une restauration d'un master pour garder des TSE propre dans le temps...

A voir un CITRIX qui permettait d'avoir une TSE simplifié, c'est à dire grace au système SeamLess, ton application apparaît comme une application locale pourtant lancer à distance, ainsi, fermer la session CITRIX similaire au TSE est disons plus difficile par un utilisateur lambda, cela les encourage à fermer l'application par sa propre croix ou bouton fermer au lieu d'utiliser la fermeture du TSE

Perso, je n'utiliserais pas la WM FireBird pour être directement le serveur TSE, ce dernier j'en ferai un dédié, régulièrement restauré depuis un master (pas de donnée dessus, y compris la base de registre), pas d'accès à ton FireBird en dehors de ce serveur TSE et des postes d'administration, c'est ce que j'avais en CITRIX mais avec 8 Serveurs (4 en 2008 ancien CITRIX, 4 en 2012 Citrix XenApp), un ExaData ORACLE et plutôt 100 utilisateurs CITRIX + 100 utilisateurs C\S classique.

Citation:

---

Envoyé par ShaiLeTroll

A savoir, à l'ouverture d'un TSE, les fenêtres reçoivent RecreateWnd...

---

Ca ne devrait pas être systématique mais seulement si l'échelle du client n'est pas à 100%.

J'avais constaté cela même sur une station de travail avec deux sessions ouvertes et une commutation entre-elles. La session mise en pause repasse en 96 dpi et revient au réglage à l'ouverture, d'où le RecreateWnd nécessaire sur certains éléments pour s'adapter à la nouvelle résolution.

Citation:

---

Envoyé par fveto

Je pense que certains utilisateurs ferment la session TSE de façon sauvage (sans fermer l'application).

---

Ce qui ne devrait pas être un problème, les applications tournent encore.
Tu n'as rien la nuit qui impacte comme "Fermer automatiquement les sessions RDS inactives" ou " fermeture automatique des sessions TSE" en option quelque part ?

En CITRIX, les applications distantes sont sur la session utilisateur, lorsque l'on ferme tous les programmes, la session se clôture réellement pas juste déconnectée.
Si les opérateurs généralement ferment tout, faut dire que j'ai conçu un portail pour justement tout fermer avec un gros bouton "QUITTER",
les responsables ayant plus d'applications ouvertes locales + distantes ne ferment que la session locale et laisse tout ouverte pour le lendemain,
lorsqu'ils ouvrent le lendemain matin, ils retrouvent tout leur local et dès qu'une application CITRIX est relancée, toutes celles ouvertes la veille reviennent avec à la reconnexion de Session distante (si le répartiteur de charge les a renvoyé sur le même serveur de la ferme)

As-tu pensé à gérer WM_ENDSESSION ?

Bonjour,

Merci pour ta réponse bien détaillée.

Effectivement, un redémarrage du serveur VM la nuit pour fermer les sessions TSE éventuellement ouvertes et réinitialiser le système.

Non, je ne gère pas le WM_ENDSESSION, je vais l'ajouter !!!

Cordialement