Faire interagir/communiquer 2 travaux

IBM i, configuration, commandes, ...
Répondre
thomas.barberot
Messages : 58
Enregistré le : jeu. 12 avr. 2012, 14:50:53

Faire interagir/communiquer 2 travaux

Message par thomas.barberot »

Bonjour.

Je cherche comment faire communiquer 2 travaux (au sens job) pour que l'un pose une question à l'autre et reçoive la réponse, donc de manière synchrone (ce qui fait que j'ai éliminé l'utilisation des DTAQ, plus dédiées à des processus asynchrones de mon point de vue). J'explique le contexte :
Pour réaliser un calcul, il est nécessaire de rechercher beaucoup de paramètres dans différentes tables, plutôt bien peuplées, ce qui ralentit le processus. Comme ce processus est exposé en web service et doit être très réactif, je cherche à l'accélérer.
Mon idée, c'était de lancer un travail "de fond" qui chargerait tous les paramètres, puis qui se mettrait en attente de sollicitation pour effectuer le calcul et en renvoyer la réponse au solliciteur, puis qui se remettrait à attendre.

J'ai pensé au début utiliser les API socket (qui semblent tout à fait appropriées pour ce genre de configuration client/serveur), mais j'ai peur que l'instanciation de la connexion soit pénalisant pour un service web (mais je n'ai pas testé).

J'ai commencé à faire des tests avec des envois de messages (via API QMHSNDM) à une MSGQ scrutée par le travail de fond (via API QMHRCVM), et qui renvoie la réponse sous forme de réponse au message (via API QMHSNDRM). Mais je me heurte aux clés de messages que je n'arrive pas à faire coïncider entre celui qui poste le message (le programme qui sollicite un calcul) et celui qui le reçoit (le travail de fond) : l'API QMHSNDM renvoie une clé (ex. : 1), et l'API QMHRCVM reçoit le message avec une clé différente (ex : 17). Je n'arrive donc pas à envoyer la réponse au message d'origine, puisque je n'arrive pas à avoir sa clé.

Je vais essayer de passer des messages non *INQ avec des GUID pour être sûr que la réponse corresponde à la demande, mais j'ai l'impression de m'embarquer dans quelque chose de très complexe et fragile (si les programmes se décalent entre les demandes et les réponses, ça risque d'être joyeux).

Quelqu'un a-t'il déjà essayé ce genre de chose ? Avez-vous des conseils à me donner pour faire ce genre de processus ?

Merci.
Thomas

cmasse
Site Admin
Messages : 813
Enregistré le : mer. 14 févr. 2007, 18:00:03
Localisation : Nantes
Contact :

Re: Faire interagir/communiquer 2 travaux

Message par cmasse »

Les MSGQ me paraissent la bonne option, il faut envoyer des messages de type question et envoyer ensuite la réponse. dans ce cas la réponse a la même clef que la question (mais pas le même type)
Christian Massé (Volubis.fr)

thomas.barberot
Messages : 58
Enregistré le : jeu. 12 avr. 2012, 14:50:53

Re: Faire interagir/communiquer 2 travaux

Message par thomas.barberot »

Effectivement, après avoir bien relu la doc. des API, j'ai trouvé d'où venait l'erreur : la clé message renvoyée est celle du message *COPY et non celle du message *INQ. Et j'avais croisé 2 MSGQ (une écoutée par le travail de fond et une dans laquelle la réponse était postée, écoutée par le requérant).

Mais cette solution a une limite : la réponse ne peut pas dépasser 132 caractères. Je vais chercher une solution pour renvoyer des résultats plus longs.
Je pense que la solution d'envoyer des messages (non *INQ) croisés dans des MSGQ est compliquée, car dès qu'on n'envoie plus de message *INQ, on perd la notion de clé de message. Du coup, difficile de renvoyer un message réponse qui corresponde à la demande.
je pense faire passer en réponse du message le pointeur d'un user space dans lequel le programme de traitement écrit le résultat. A voir au niveau des temps de réponse de création et d'écriture de user space.
Si quelqu'un à une autre idée, je suis preneur.

Merci Christian.
Thomas

Répondre