Discussion :

[Thetortuga]

Bonjour,

Lors de mes tests, il m'arrive souvent de laisser tourner mon application serveur assez longtemps, c'est à dire que je ne la redémarre pas en faisant des modifications côté client. Or, j'ai régulièrement des erreurs de ce type, qui me plantent l'application :



Lorsque que je regarde les connexions tcp ouvertes sur mon pc, je constate qu'il y en a énormément entre mon application et le démon sql :



N'y aurait il pas un oubli de fermeture de socket au niveau de QxOrm ?
(désolé pour les grandes captures d'écran)

[QxOrm]

C'est bizarre !
Normalement, le module QxService utilise une connexion par thread au niveau de ton serveur.
Combien de threads as-tu défini par la méthode qx::service::QxConnect::getSingleton()->setThreadCount(XXX) ?

Ou peut-être que tu utilises ton propre pool de connexions ?

Sinon, tu peux aussi fermer automatiquement la connexion à la BDD après exécution de chaque requête.
Dans ta classe de service héritée de qx::service::IxService (je sais que tu en as créé une pour gérer un mécanisme d'authentification), tu peux surcharger la méthode virtual void onAfterProcess() (ou bien mettre le code dans le destructeur du service) pour fermer la connexion à la BDD, quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
virtual void onAfterProcess()
{
   // Get the connection for the current thread and close it
   QSqlDatabase db = qx::QxSqlDatabase::getDatabase();
   db.close();
}

[Thetortuga]

J'ai défini 200 threads pour l'instant. Mais cette valeur est bien le nombre de clients simultanés connectés à un serveur via les services n'est ce pas ?
Le problème ici est bel et bien le nombre de connexions entre le serveur et la base de données.

Je vais essayer ta méthode. Je te tiens au courant.

[QxOrm]

J'ai défini 200 threads pour l'instant.

Ça me parait énorme 200 : même si tu as 200 clients qui se connectent exactement au même moment à ton serveur et que tu as mis une valeur à 50 par exemple, il y a un mécanisme de file d'attente.
Et comme une requête en général est extrêmement rapide, pour l'utilisateur final, c'est dans la plupart des cas complètement transparent.

Mettre 200 signifie qu'au bout d'un moment, tu auras effectivement 200 connexions ouvertes à ta BDD, car les threads disponibles sont utilisés au fur et à mesure des requêtes clientes.
Donc il faut vérifier que ta BDD supporte 200 connexions simultanées (c'est peut-être un paramétrage de ta BDD).
Ou alors baisse ce chiffre et mets une valeur à 50 par exemple.