Nous avons une pile de serveurs normaux incluant BlazeDS, Tomcat et Hibernate.Comment forcer Apache Tomcat à ne pas réutiliser un thread du pool de threads?
Nous aimerions arranger des choses telles que si certaines erreurs (en particulier AssertionError) sont levées, le thread courant est considéré comme étant dans un état inconnu et ne sera pas utilisé pour d'autres requêtes HTTP. (En partie parce que nous stockons certaines choses, telles que la session de transaction Hibernate, dans le stockage local de threads.) Maintenant, nous pouvons attraper des jetables et nous assurer d'annuler les transactions et de les relancer, mais il n'y a aucune garantie. sait quoi dans le stockage local du thread.)
Tomcat avec le comportement de pool de threads par défaut réutilise les threads. Nous avons essayé de spécifier notre propre exécuteur, qui semble être la méthode la plus spécifique pour changer son comportement de pool de threads, mais il n'appelle pas toujours Executor.execute() avec une nouvelle tâche pour chaque requête. (Très probablement, il réutilise le même contexte d'exécution pour toutes les demandes dans la même connexion HTTP.)
Une option consiste à désactiver keepalive, de sorte qu'il n'y ait qu'une seule requête par connexion HTTP, mais c'est moche.
Quoi qu'il en soit, j'aimerais savoir. Existe-t-il un moyen de dire à Tomcat de ne pas réutiliser un thread, ou de tuer ou de quitter le thread afin que Tomcat soit obligé d'en créer un nouveau? De la source Tomcat, Tomcat va fermer la connexion et abandonner la tâche/thread après avoir envoyé une réponse HTTP 500, mais je ne sais pas comment obtenir BlazeDS pour générer une réponse 500, c'est un autre angle que je J'aimerais en savoir plus sur.)
Vous pouvez dire cela à propos de l'odeur; OTOH on pourrait aussi argumenter que c'est quelque chose que Tomcat devrait faire de toute façon (par défaut, les exceptions non interceptées et les erreurs, y compris AssertionError, semblent être à peu près abandonnées, sauf si je manque quelque chose - nous avons déjà écrit un filtre connectez l'existence de ces throwables). Quoi qu'il en soit, il ne s'agit pas de faire fonctionner Tomcat avec notre application, ou quoi que ce soit d'inhabituel, je pense - ça marche, ça continue avec un peu trop d'enthousiasme après les exceptions, et je veux m'assurer que toutes les bases sont couvert. – metamatt
Et oui, notre filtre pourrait nettoyer après l'état local thread-périmé, ou tout code que nous écrivons qui place des trucs dans l'état thread-local peut utiliser try/catch/finally pour s'assurer qu'il est nettoyé, mais. Quelque chose d'autre ailleurs dans le système pourrait également oublier de le faire. J'essaie juste d'éviter ce genre d'erreur. – metamatt
Encore une pensée. Il est assez simple d'amener Tomcat à abandonner un thread en générant une réponse de 500, donc vouloir le faire ne semble pas être un abus de la conception de Tomcat. Vraiment, c'est la combinaison de Tomcat + BlazeDS + Hibernate qui rend cela à la fois désirable et difficile. – metamatt