Probleme récurrent, threads/EJB/Servlets

Bonjour,

Je viens parler d'un probleme que je vois partout dans les forum disponible sur la toile !

Est-ce vrai que nous ne pouvons pas exécuter de thread a partir d'un EJB ? (ça je crois comprendre qu'en effet, c'est pas possible) MAIS SURTOUT si on ne peu pas, peut-on en créer et en exécuter dans une serlvet ?

Cette deuxième question est souvent posée, mais a toujours des réponses différentes qui ne me satisfont pas...

Soit on peut le faire, donc, c'est cool, soit on peut pas et dans ces cas la, aucunes solutions alternative n'est proposée...

J'aimerais donc, une fois pour toute, avoir une réponse sur ce probleme car il me faut des threads à partir d'une servlet !!!

MERCI BEAUCOUP A QUI POURRA ME REPONDRE !!!!

pour etre clair techniquement tu peux le faire : en effet rien ne t'empeche de lancer un thread.
C'est plutot en terme de conception que cela pose un probleme : en effet c'est le container qui gere le cycle de vie des objets et tu transgresse ce principe en créant des threads.

En effet que devient ta poigné sur ton thread lorsque ton ejb est passivé ? et meme si tu ne garde pas de poignée sur ton thread tu peux avoir potentiellement un ensemble de thread que le container ne peut gérer. En plus si je dis pas de betise, le container doit utiliser des ThreadLocal et cela peut etre problematique.

J'ai moi meme fais le test de créer des threads et cela fonctionne, cependant je te deconseille d'appeler des EJB depuis ces threads pour les raisons évoqués précedemment.

pose toi la question de l'interet des threads avant tout : ne peut tu pas faire autrement ?

En fait, j'ai plein d'ejb qui se connecte chacun a une base différente et renvoi des données...

Le but est de créer un thread par EJB dans la servlet, chaque EJB retourne alors les réponses qui sont concaténés dans la servlet. Ceci permet de ne pas attendre et cumuler tous les temps d'attente de chaque base !

Si il y a 1 seconde d'attente de connection a une base et que je fais 100 demande, je vais avoir 100 seconde d'attente, si je fait des demandes en parallele, les temps d'attente se s'additionneront plus. Mais comment puis-je faire sous weblo... On m'a parlé d'RMI, croyez vous que ça peut m'aider ??!!

Merci beaucoup !

Je précise qu'en fait, les thread ont une durée de vie relativement courte... Il interroge la base et retourne des info, point !!!

Donc, la fonction run() s'exécute très vite, et quand elle se termine, elle kill le thread en principe !! Donc, il ne devrait pas y avoir de probleme !! Enfin, je prefere quand meme avoir l'avis d'expert !!

dans ce cas utilise plutot des EJB MDB. Ce sont des ejb asynchrones qui utilisent des files d'attentes jms.

Dans ton cas il suffit d'interroger un ejb session qui va exploser ta requete en plusieurs appel mdb. comme c'est asynchrone ta servlet recoit le retour de l'ejb avant meme que le travail soit terminé. Il suffit que ta servlet se redirige vers une queue JMS et attende le résultat. Pendant ce temps ton ejb session explose la requete vers plusieurs mdb qui lui répondent en retour aussi par jms et une fois que tout le travail est terminé il envoie le résultat dans une file JMS au bout de laquelle attend la servlet.

Oulala !!

Comme on dis chez moi, "c'est prendre une pelleteuse pour arracher une marguerite" non ???

JMS, ça implique un serveur JMS qui n'est pas forcément des plus rapide !! Et si j'ai 100 clients de connectent en meme temps !!

Je pense que l'idée des threads n'est pas mauvaise, j'aimerais juste savoir comment et ou les exécuter !!! Mais je vais quand meme voir plus d'info sur ces EJB MDB, tu as un liens qui explique bien tout ça ??? (en français, si possible, sinon, anglais)

Merci encore en tout cas !

ce sera a peine plus lourd que si tu utilises des threads
la charge sera réparti puisqu'il est possible de maitriser le nombre de mdb en cours d'execution alors que ta gestion de thread sera chaotique. Avec les thread le risque c'est de ne pas pouvoir maitriser ta montée en charge puisque tu ne maitrise pas le nombre d'execution en cours : au final c'est un beau OutOfMemory qui t'attend.

de plus le serveur jms et les ejb mdb sont "natif" depuis jee 1.3 (donc ton serveur jee intègre un serveur jms).

pour la doc cf google

Merci encore... Mais je viens de voir un autre probleme !!

Les EJB dont je parle et qui se connecte chacun a une base pour retourner des infos, ce sont eux qu'il faudrait faire en MDB !!

Seulement, ces EJB sont déjà créés, et je ne peut pas les modifer puisqu'ils sont utilisés par d'autre application qui les appel un par un !!! :aie: :aie:

Arf !!! Merci beaucoup pour ton aide, j'en ai vraiment besoin !!! :bug:

Si je part sur l'idée du JMS !

Je dois donc créer une queue, et de mon EJB principal, j'envois plusieurs messages, un par ejb a executer !! Les ejb s'executent et renvoi, via JMS le résultat à l'EJB principal !

Par contre, est ce que le traitement de tous les ejb se fera bien en parallele ??? Et, dois-je faire une queue par ejb ??? (j'espere que non)

Dis moi si j'ai dit des bétises !!

Merci beaucoup !!

Citation:

---

Envoyé par tinico

Si je part sur l'idée du JMS !

Je dois donc créer une queue, et de mon EJB principal, j'envois plusieurs messages, un par ejb a executer !! Les ejb s'executent et renvoi, via JMS le résultat à l'EJB principal !

---

correct

Citation:

---

Envoyé par tinico

Par contre, est ce que le traitement de tous les ejb se fera bien en parallele ???

---

c'est de l'asynchrone donc oui par contre rien ne prédit l'ordre d'execution

Citation:

---

Envoyé par tinico

Et, dois-je faire une queue par ejb ??? (j'espere que non)

---

dans l'absolu oui
cependant tu peux peut etre regrouper plusieurs appels vers des ejb dans un mdb suivant tes besoins
créer un queue par ejb c'est pas trop grave puisque c'est simplement déclaratif

en pratique tu aurai un ejb mdb par ejb qui accède à la bdd (sauf si tu fais des regroupement)
chacun de ces mdb appel l'ejb et repond dans la queue de consolidation des données. Pour recuperer l'info dans la queue de consolidation tu peux mettre aussi un mdb qui consolide les données a chaque réception de message et une fois qu'il a tout recu, envoie un message dans une queue finale destiné à la servlet.
La servlet envoie un message dans la queue d'interrogation et ensuite

2 cas possible
1 - attend sur la queue finale mais ton interface utilisateur est bloqué
2 - se redirige vers une page qui toute les 3 secondes par exemple (avec un header refresh)fait un appel à une autre servlet qui elle scanne la queue final : si pas de reponse elle retourne une page du genre "please wait..." et si il y a quelque chose dans la queue affiche les informations consolidées.

voilou
ca parait compliqué mais quand tu auras utilisé une fois les mdb tu verras que c'est super simple

Ceci me parrait surtout un peu gros pour de simple requette comme celle que je veux faire !!!

Je pensais, moi, appeler l'ejb principal (à partir d'une portlet comme c'est prévu), qui lui, envois directement les messages déclencheurs dans les queues JMS !!! Les ejb mdb receptionnent et font leur boulot (se connecte a la base et récupere l'info voulu). Ensuite, ils envoient leurs résultats dans les queue que l'EJB récupère et renvoi a l'appelant (la portlet).

C'est trop simple pour que ça marche ????

Sinon, il est vrai que je peut passer par des ejb mdb pour appeler mes ejb deja existant, mais bon, je vais essayer de modifier directement les ejb deja existant, c'est peut etre possible en fait ! Qu'en penses-tu ?

Citation:

---

Envoyé par tinico

Je pensais, moi, appeler l'ejb principal (à partir d'une portlet comme c'est prévu), qui lui, envois directement les messages déclencheurs dans les queues JMS !!! Les ejb mdb receptionnent et font leur boulot (se connecte a la base et récupere l'info voulu). Ensuite, ils envoient leurs résultats dans les queue que l'EJB récupère et renvoi a l'appelant (la portlet).

---

c'est exactement ce que j'ai décrit précedemment à une différence près que les mdb, plutot que d'acceder à la base, accède aux ejb existant. Pour la servlet tu peux attendre que l'ejb principal reponde plutot que d'utiliser un mdb mais potentiellement tu ne sais pas en combien de temps donc le risque c'est que ton interface web reste bloqué et déconcerte l'utilisateur

Citation:

---

Envoyé par tinico

Sinon, il est vrai que je peut passer par des ejb mdb pour appeler mes ejb deja existant, mais bon, je vais essayer de modifier directement les ejb deja existant, c'est peut etre possible en fait ! Qu'en penses-tu ?

---

bof modifier tes ejb existant alors qu'ils sont utilisés par d'autres appli c'est risqué

mais bon c'est toi qui vois

Oui, c'est vrai !!!

En principe, les requettes sont des requettes courtes et rapides (quelques ms), donc, si le travail est bien fait en parallele, le traitement devrait etre rapide !! donc, pas besoin de page d'attente et donc, pas de servlet !

en fait, j'ai plus du tout besoin de servlet avec ça ! ça simplifie un peu le truc ! Mais j'ai tout le systeme JMS a mettre derriere (mais sous weblo, je crois que c'est fait en graphique hi hi) !

Je vais voir pour les EJB, en fait, un EJB session ou un EJB mdb peuvent faire la meme chose, c'est juste la méthode d'invocation qui change !!?? Donc, peut etre pourrais-je modifier les modules qui utilisent deja les EJB de connexion !! ça devrait pas etre long !

Au fait, c'est rapide JMS ??? J'ai vu sur des forums qu'il pouvait y avoir des temps nom négligeable de navigation de message !!??

j'ai jamais remarqué de temps de réponse si lent que ça
cependant il ne faut pas d'étonner d'une latence due à un système asynchrone

après tout dépend de ce que tu met dans ton message

Dans les message, ce seront des objets, mais relativement léger !!
Comme peut etre une hashtable avec uniquement 2 ou 3 entrés, et peut etre une map avec aussi 2 ou 3 entrés et quelques string (peut etre)

Donc, cela restera relativement legé !!!

Bonjour,

je répond a ma question pour que cela puisse servir a d'autre !!
(Par cotnre, c'est ce que j'ai compris, ça serait cool de me corriger si je dit une c.......)

La question d'origine était : Est-ce vrai que nous ne pouvons pas exécuter de thread a partir d'un EJB ? (ça je crois comprendre qu'en effet, c'est pas possible) MAIS SURTOUT si on ne peu pas, peut-on en créer et en exécuter dans une serlvet ?

Dans l'EJB, clairement : NON, c'est dit dans la spec :

"The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread; or to change a thread's priority or name. The enterprise bean must not attempt to manage thread groups. These functions are reserved for the EJB Container. Allowing the enterprise bean to manage threads would decrease the Container's ability to properly manage the runtime environment.”

ça, c'est clair !!

Pour la servlet, c'est déconseillé dans le sens ou les servlet ne sont pas "thread safe". En fait, cela vient de leur mode d'éxécution (un thread par méthode service() mais une seul instance). Donc cela peu poser probleme dans la gestion des threads, mais pour des threads court et bien géré, il n'y a aucune interdiction... Voila voila ce que j'ai compris !!

Il me semble que ce topic est en lien avec mon pb alors je poste ma question ici :

Voilà, j'ai une servlet. Celle-ci est censée répondre à la requête POST appelante par un message de bonne réception puis lancer un ensemble de threads.
Sauf que problème, ma servlet ne répond pas tant que les threads n'ont pas terminé leur cycle de vie...

Comment faire donc?

Sachant que je dois normalement respecter ce choix d'Archi même s'il n'est pas le meilleur...

Bonjour,
dans weblogic il me semble qu'on peut lancer des taches en parallèle , as tu regardé WorkManager ?

Houlà, le vieux post tout bidon.
Ca fait longtemps que j'ai résolu mon pb.
Je faisais juste une erreur au lancement de mes threads.
un bon vieux run au lieu d'un start.
La classique