Je dois effectuer une tâche asynchrone lorsqu'un point de terminaison de service Web reposant est appelé. Effectivement, le noeud final est invité à effectuer un travail de travail avec une opération postale. Il devrait immédiatement renvoyer à 200 OK à l'appelant, reprogrammer un fil et effectuer une tâche intensive de ressources. À la fin, le thread posterait alors à un point d'extrémité correspondant sur l'appelant (un autre serveur de repos) indiquant le succès (passant un jeton qui représente la demande de transaction initiale).
Quelles sont les approches des meilleures pratiques pour effectuer des actions asynchrones à l'intérieur d'un servlet que je devrais être au courant?
4 Réponses :
servlet 3.0 a la prise en charge de Opérations asynchrones . Tomcat 7.0 est déjà stable, vous pouvez donc l'obtenir et essayer les nouvelles fonctionnalités.
Si vous n'avez pas besoin de sortir des données de manière continue, mais simplement de démarrer un processus d'arrière-plan, vous pouvez utiliser tout mécanisme asynchrone disponible:
Nouveau thread (Nouveau Runnable ())
-
@Async (printemps / ejb)
Nous utilisons Tomcat 7 mais ma compréhension avec le modèle d'opérations asynchrones est que cela est destiné aux opérations de style comète? J'exige que la demande d'origine renvoie immédiatement l'état 200 OK, et commence alors à traiter l'opération intensive. Est-ce possible?
Le seul avis de votre scénario serait d'utiliser la piscine de thread plutôt que de créer un nouveau fil par demande. En Java, il est très facile, il suffit de créer une piscine une fois lors du démarrage de l'application (regardez exécuteurs classe) et soumettez de nouvelles tâches à chaque fois que vous devez effectuer une opération asynchrone. Pour votre scénario, ces tâches effectueront des opérations intensives de ressources et un deuxième appel de repos d'un fil différent, longtemps après que la demande initiale a été servie avec 200.
Mis à part les complexités de la codage ASYNC en Java, une autre "meilleure pratique" dans les services Web reposants consiste à utiliser des codes d'état HTTP pour décrire la réponse de votre serveur aussi précisément que possible. Sauf si vous avez une raison convaincante de coller avec 200 (c'est-à-dire qu'un client que vous ne pouvez pas changer attend cela), vous devriez revenir 202 accepté
La demande a été acceptée pour le traitement, mais le traitement n'a pas été achevé.
Dans un conteneur Java EE, la manière recommandée est d'utiliser l'API de WorkManager (JSR-237). Vérifiez Cet article pour un aperçu.
Un conteneur J2EE peut servir plusieurs utilisateurs en même temps (en parallèle) en gérant un pool de fils, mais pour diverses raisons ouvertes indépendantes Fils dans un seul conteneur J2EE n'est pas recommandé. Des conteneurs ' Les gestionnaires de sécurité ne permettront pas l'utilisateur programmes pour ouvrir les threads. De plus, si Certains conteneurs autorisés ouverture threads, alors ils ne gèrent pas ces threads et donc non Les services gérés par les conteneurs seraient Disponible pour les threads.
Non ce n'est pas le cas. JSR-237 a été retiré et il constitue actuellement une fonctionnalité spécifique Oracle-IBM. L'API Workmanager ne peut pas être faite pour travailler avec JBoss 7.x
JSR 237 a été fusionné avec JSR 236, fournissant une spécification unique et cohérente pour Java Ee Concurrency ( jcp.org/fr/jsr/detail?id=236 )