2009-05-03 18 views
3

Je travaille avec open esb sur un serveur glassfish. Nous avons un pool de connexion qui fonctionne avec une base de données as400.Existe-t-il un moyen de libérer un pool de connexions saturées?

Tous les deux jours, nous obtenons cette erreur: Erreur lors de l'allocation d'une connexion. Cause: Les connexions en cours d'utilisation sont égales à au format pool et ont expiré au maximum. Impossible d'allouer plus de connexions

La meilleure façon de soulager le cp est de redémarrer le serveur. Nous avons également réussi à définir un autre cp avec les mêmes attributs.

Mes questions sont: Y at-il un moyen de "dire" activement au cp de libérer toutes ses connexions ouvertes?

Cheers, Eran

Répondre

5

Avant de le faire, comprendre pourquoi les connexions ne sont pas libérés correctement. On dirait qu'il y a un seul endroit où cela est oublié (avez-vous tous les close() dans les clauses finally?).

Je peux fortement recommander Michael Nygards "Release It!" des techniques pour préparer la production de logiciels. EDIT # 1: Si je comprends bien votre description, vos programmes backend vont dans MSGW dans QSYSOPR ce qui aboutit à une connexion suspendue jusqu'à ce que la réponse soit donnée, ce qui dans votre cas est proche de jamais. Est-ce une option d'utiliser un profil avec une réponse par défaut de "C" qui permet à la faute de se propager à vous en tant qu'exception?

Sinon, vous pouvez définir un délai d'attente pour les connexions ou pour l'ensemble du serveur de 24 heures? Alors au moins les connexions finiront par être fermées. Cette solution n'est pas à l'échelle, mais peut faciliter le développement.

Veuillez noter qu'il est également possible d'avoir un fil de surveillance séparé qui recherche régulièrement MSGW et leur envoie automatiquement une réponse APRÈS avoir saisi la pile de rappel pour l'analyse post mortem.

+0

Merci pour la réponse rapide. J'ai une clause close() dans toutes les clauses finally pertinentes (enfin, très probablement) Le problème est que cette exception qui pourrait être lancée du côté as400, ouvre une boîte de dialogue de confirmation de l'utilisateur. Jusqu'à ce que ce ne soit pas fermé, la connexion ne sera pas libérée. Je voulais savoir s'il y avait un moyen de ne pas attendre pour toujours cette confirmation que personne sur l'as400 ne surveille réellement. Je vais essayer de creuser un peu en ce qui concerne le Michael Nygards "Release It!" Merci –

1

Si vous pouvez déterminer une limite supérieure pour l'utilisation de la connexion "normale" en secondes, vous pouvez utiliser le mécanisme de détection de fuite de connexion de GlassFish. Dans la console d'administration de GF (j'utilise v2.1), allez dans Ressources/JDBC/Pools de connexions/[votre cp]/Avancé et sous Paramètres de connexion, réglez Perte de récupération sur true et définissez une durée en secondes pour le délai de fuite.

+0

Est-ce que cela fonctionnera si la connexion est au milieu d'une requête, ou doit-elle être "inactive"? –

0

Vous avez mentionné dans votre commentaire à Andersen que vous recevez des messages AS400. Il est possible de configurer des réponses automatiques à ces messages pour éviter de laisser le message d'exception ouvert. Consultez la commande WRKRPYLE (Work List List Entry) sur l'AS400 pour répondre automatiquement à ces erreurs et éviter un blocage.

+1

Étant donné que ces tâches se produisent sur le serveur (pour cette question), cette option peut poser problème. Le définir pour un travail de ce type le définit également pour chaque travail du même type (c'est-à-dire, toute connexion au serveur). Il peut y avoir plusieurs connexions qui ne peuvent pas tolérer les réponses par défaut. Mettre en œuvre avec soin. – user2338816

1

J'ai eu ce problème et il s'est avéré être la gestion des transactions. L'ajout de @TransactionManagement (TransactionManagementType.BEAN) à la classe a résolu le problème. Dans mon cas, je ne voulais pas de code de transaction, mais votre kilométrage peut varier en fonction de vos besoins.