Que 5 pipes soient créés est normal, lodex-worker est un serveur qui fonctionne en mode cluster multi process.
Il ne réagit pas selon le nombre de documents envoyés, mais selon le nombre CPU de la machine (et le paramètre concurency).
Le serveur prépare à l'avance des processus de traitement, il les utilise quand il reçoit des données.
si curl ne rend pas la main, c'est probablement qu'un flux de données n'est pas fermé quelque part.
OK, merci pour l'explication.
Ça n'explique pas pourquoi le flux n'est pas fermé.
Je vais ré-essayer de lancer le démon IRC3sp.pl tout seul, et voir si ça marche encore sans passer par ezs.
et tester avec le irc3_wrapper.sh
ezs ne fait rien d'autres qu'un ou plusieurs (en parallele)
/app/public/irc3_wrapper.sh < input.jsonl > output.jsonl
En supprimant tous les processus IRC3, et en relançant su-exec daemon:daemon ./public/irc3_wrapper.sh start, ça marche localement:
bash-5.1# echo '{"id":"1", "value": ["Pseudopercis semifasciata, Acanthistius patachonicus, Pinguipes brasilianus and Sebastes oculatus were studied"]}' | su-exec daemon:daemon public/irc3_wrapper.sh job
[
{
"id": "1",
"species": [
"Acanthistius patachonicus",
"Pinguipes brasilianus",
"Pseudopercis semifasciata",
"Sebastes oculatus"
]
}
]
et le fifo du job est bien supprimé:
bash-5.1# ls -l /tmp total 8 prw-r--r-- 1 daemon daemon 0 Aug 25 07:37 fifo_irc3 drwxr-xr-x 3 daemon daemon 4096 Aug 25 06:56 store drwxr-xr-x 1 daemon daemon 4096 Aug 9 21:03 v8-compile-cache-0
en ligne de commande c'est echo qui termine le flux stdin et qui en cascade coupe le flux stdout, car les deux sont directement connectés
en mode server, la connexion entre le flux d'entrée et le flux de sortie est assurée par spawn - https://nodejs.org/api/child_process.html#child_processspawncommand-args-options
et je ne crois pas que la documentation précise explicitement que les deux sont connectés. Il faut peut-être que le wrapper ferme lui-même le flux de sortie ou tout seulement s’arrête avec un exit. Le test unitaire dédié aux scripts bash fonctionne un peu comme ça https://github.com/Inist-CNRS/ezs/blob/master/packages/spawn/test/cmd.sh
Je pense que le problème vient du fait que lodex-worker lance plusieurs processus car on a dans “irc3_wrapper” :
if [[ -p /tmp/fifo_irc3 ]]
then
mkfifo -m 0666 /tmp/fifo_job_$$
(echo "%% JOB POUR FIFO /tmp/fifo_job_$$";
cat;
echo "";
echo "%% FIN JOB") > /tmp/fifo_irc3
cat /tmp/fifo_job_$$
rm -f /tmp/fifo_job_$$
fi
On voit que le FIFO a été créé, donc le programme a envoyé le début du message et attend ce qui vient de l’entrée
standard avec cat. En fait, les 5 programmes lancés ont fait cela en même temps alors que ce shell a été écrit avec
l’idée qu’un seul à la fois serait appelé.
Solution : il faut stocker les données venant de l’entrée standard et seulement après les envoyer vers IRC3sp. Pour
éviter de créer un fichier temporaire, on peut stocker ces données dans une variable, comme avec :
if [[ -p /tmp/fifo_irc3 ]]
then
mkfifo -m 0666 /tmp/fifo_job_$$
data=$(cat)
(echo "%% JOB POUR FIFO /tmp/fifo_job_$$";
echo "$data";
echo "%% FIN JOB") > /tmp/fifo_irc3
cat /tmp/fifo_job_$$
rm -f /tmp/fifo_job_$$
fi
On peut également préciser que les données viennent de l’entrée standard avec data=$(cat /dev/stdin).
Cette fois j'obtiens une réponse, mais c'est une erreur ezs.
$ curl -X POST --data '[{"id": "1", "value": ["Pseudopercis semifasciata, Acanthistius patachonicus, Pinguipes brasilianus and Sebastes oculatus were studied"]}]' http://localhost:31976/irc3sp
Error: item #1 [delegate] <Error: item #2 [expand] <Error: [exec] <Error: [unpack] <SyntaxError: Unexpected end of JSON input>>>>
Je n'arrive pas à me figurer d'où vient l'erreur exactement.
Du fichier irc3sp.ini, c'est sûr.
La partie delegate fait référence à l'exécution du fichier lui-même.expand est bien visible dans le script (lignes 26 et 32).exec est sur la ligne 32, mais le unpack de l'erreur suivante a l'air d'être une instruction ezs, mais elle serait appelée par expand ?
Ah non, c'est exec qui fait appel à unpack: https://github.com/Inist-CNRS/ezs/blob/561b0cc480a3a6d9c5369f4081df7cfdfd64519d/packages/spawn/src/exec.js#L46
J'imagine que l'erreur arrive lors du parsing des données: https://github.com/Inist-CNRS/ezs/blob/7a7f1c27ce93c365950658a8e946b988cc607436/packages/core/src/statements/unpack.js#L12
J'ai ajouté un peu de debug dans la fonction travail:
function travail
{
if [[ -p /tmp/fifo_irc3 ]]
then
mkfifo -m 0666 /tmp/fifo_job_$$
data=$(cat)
{
echo "DEBUT<<<<<<<<<<<<<<<<<<";
echo "$data";
echo "FIN >>>>>>>>>>>>>>>>>>>";
} >> /tmp/debug_input_$$ # debug
(echo "%% JOB POUR FIFO /tmp/fifo_job_$$";
echo "$data";
echo "%% FIN JOB") > /tmp/fifo_irc3
cat /tmp/fifo_job_$$
rm -f /tmp/fifo_job_$$
fi
}
Et en faisant le traditionnel
curl -X POST --data '[{"value":["bob"]}]' --header 'Content-Type: application/json' http://localhost:31976/irc3sp
Je peux voir, dans le container:
bash-5.1# cat /tmp/debug_input_198
DEBUT<<<<<<<<<<<<<<<<<<
{"id":"00000000000000000001","value":["bob"]}
FIN >>>>>>>>>>>>>>>>>>>
(et cette fois il ne reste plus que 4 fifo_job_ ouverts, signe qu'un des 5 a été consommé)
Le JSON reçu par la commande lancée par exec m'a l'air valide.
Ça doit être une histoire de découpage des données, car l'erreur se décompose comme suit:
expand, mais sur le deuxième élément du tableau ?!?)expand/exec)this.resource n'existe pas, donc elle est initialisée via handle.acquire(), ce qui paraît normal, mais peut-être pas pour le deuxième élément -même si le deuxième élément est censé être vide)J'ai essayé avec deux éléments, et le message d'erreur est différent:
$ curl -X POST --data '[{"id": "1", "value": ["Pseudopercis semifasciata, Acanthistius patachonicus, Pinguipes brasilianus and Sebastes oculatus were studied"]},{"id": "2", "value":["bob"]}]' http://localhost:31976/irc3sp
Error: item #1 [delegate] <Error: item #3 [expand] <Error: [mergeWith] <ReadError: key cannot be `null` or `undefined`>>>
Ce qui se passe dans le container:
bash-5.1# ls -l /tmp
total 20
-rw-r--r-- 1 daemon daemon 95 Aug 25 12:11 debug_input_198
-rw-r--r-- 1 daemon daemon 202 Aug 25 12:19 debug_input_238
-rw-r--r-- 1 daemon daemon 248 Aug 25 12:34 debug_input_267
prw-r--r-- 1 daemon daemon 0 Aug 25 12:07 fifo_irc3
prw-rw-rw- 1 daemon daemon 0 Aug 25 12:11 fifo_job_202
prw-rw-rw- 1 daemon daemon 0 Aug 25 12:11 fifo_job_204
prw-rw-rw- 1 daemon daemon 0 Aug 25 12:11 fifo_job_209
prw-rw-rw- 1 daemon daemon 0 Aug 25 12:11 fifo_job_213
prw-rw-rw- 1 daemon daemon 0 Aug 25 12:19 fifo_job_242
prw-rw-rw- 1 daemon daemon 0 Aug 25 12:19 fifo_job_245
prw-rw-rw- 1 daemon daemon 0 Aug 25 12:19 fifo_job_249
prw-rw-rw- 1 daemon daemon 0 Aug 25 12:19 fifo_job_253
prw-rw-rw- 1 daemon daemon 0 Aug 25 12:34 fifo_job_271
prw-rw-rw- 1 daemon daemon 0 Aug 25 12:34 fifo_job_274
prw-rw-rw- 1 daemon daemon 0 Aug 25 12:34 fifo_job_278
prw-rw-rw- 1 daemon daemon 0 Aug 25 12:34 fifo_job_282
drwxr-xr-x 3 daemon daemon 4096 Aug 25 12:11 store
drwxr-xr-x 1 daemon daemon 4096 Aug 9 21:03 v8-compile-cache-0
bash-5.1# cat /tmp/debug_input_267
DEBUT<<<<<<<<<<<<<<<<<<
{"id":"00000000000000000001","value":["Pseudopercis semifasciata, Acanthistius patachonicus, Pinguipes brasilianus and Sebastes oculatus were studied"]}
{"id":"00000000000000000002","value":["bob"]}
FIN >>>>>>>>>>>>>>>>>>>
Hors sujet: il faudra s'arranger pour nettoyer les
fifo_jobà un moment ou à un autre, parce que ça va finir par polluer le/tmp, j'ai l'impression qu'il y en a 4 (ou 5?) qui sont créés à chaque requête.
pour les messages de debug du script exécuté, il est préférable de les envoyer sur stderr car stdout doit être un très propre en respectant le format JSON Lines sinon le serveur va généré une erreur de syntaxe lors du parsing des lignes json
Je constate dans ton fichier debug_input que le JSON ne correspond pas à ce que tu as envoyé.
Ça a été découpé en sous éléments et ça n'est plus conforme à la syntaxe JSON.
Mon programme lit le tout avant de convertir le JSON en variables Perl, mais il est très strict.
Normalement, tu devrais avoir une réponse avec garbage after JSON object, at character offset
Et est-ce que par hasard le fichier nohup.out contient quelque chose ?
l'erreur [expand] du genre "key cannot be null or undefined" semble vouloir indiqué que un id envoyé par le script ne correspond pas exactement un l'id envoyé par le serveur (ou qu'il n'y a plus d'id)
Je constate dans ton fichier debug_input que le JSON ne correspond pas à ce que tu as envoyé.
Si, je t'explique plus bas.
Ça a été découpé en sous éléments et ça n'est plus conforme à la syntaxe JSON.
Un objet { .... } est du JSON.
Ce n'est juste pas un tableau.
Mon programme lit le tout avant de convertir le JSON en variables Perl, mais il est très strict.
Normalement, tu devrais avoir une réponse avec garbage after JSON object, at character offset
En tout cas, j'ai déjà vérifié plus haut que ton programme accepte bien un objet seul.
Et est-ce que par hasard le fichier nohup.out contient quelque chose ?
Non, il n'est même pas créé. J'ai pas compris pourquoi.
AAAAhhhh... Mais ça doit être ça: quand il y a plusieurs lignes dans le fichier, c'est du JSON Lines et non du JSON, tu as raison Dominique.
C'est sans doute au parsing du JSON que ton programme doit râler.
En envoyant le fichier d'exemple fourni par Dominique:
$ cat ~/data/irc3/exemple1.json | curl -X POST --data-binary @- http://localhost:31976/irc3sp Error: item #1 [delegate] <Error: item #4 [expand] <Error: [mergeWith] <ReadError: key cannot be `null` or `undefined`>>>
Je peux lire ça dans le fichier /tmp/debug_input_297 du container:
DEBUT<<<<<<<<<<<<<<<<<<
{"id":"00000000000000000001","value":["SEVERAL SPECIES: 'CICHLASOMA' FACETUM, 'CICHLASOMA' TEMBE, CANIS SP., .... VAPPACULUM SUPERBIENS AND 'GAMMARUS' HETEROCLITUS WERE FOUND. ","The diets of the most conspicuous reef......fish species from northern Patagonia, the carnivorous species Pseudopercis semifasciata, Acanthistius patachonicus, Pinguipes brasilianus and Sebastes oculatus were studied. Pinguipes brasilianus had the narrowest diet and most specialized feeding strategy, preying mostly on reef......dwelling organisms such as sea urchins, limpets, bivalves, crabs and polychaetes.","The samples used in the SIA were from fishes caught in one reef of the San Jose Gulf (Conos Reef, Fig. 1) during November 2003. Fishes were divided into the following groups: P. semifasciata small (range = 36......43 cm LT), medium (range = 53......61 cm LT) and large (range = 78......87 cm LT) with four specimens per group; A. patachonicus small (range = 12......19 cm LT) and large (range = 32......35 cm LT) with four specimens per group; S. oculatus small (range = 15......22 cm LT) and large (range = 26......30 cm LT) with three specimens per group; P. brasilianus small (range = 20......26 cm LT) and large (range = 38......41 cm LT) with three specimens per group.","Trophic diversity accumulation curves of (a) Pseudopercis semifasciata, (b) Acanthistius patachonicus and (c) Pinguipes brasilianus. Horizontal lines show Brillouin diversity index (Hz) values (Hz.... 0....05 Hz) and the vertical line shows a value n...... 2 (n = number of stomachs)."]}
{"id":"00000000000000000002","value":["Carnivore diet analysis based on next......generation sequencing: application to the leopard cat (Prionailurus bengalensis) in Pakistan","Sequence alignment showing the specificity of the PrioB blocking oligonucleotide. The first six nucleotides of the PrioB blocking oligonucleotide overlap with the 12SV5R amplification primer. This sequence alignment contains two other Felidae species (Felis catus and Panthera tigris), another carnivore species from the Ursidae family (Ursus arctos), two rodents (Rattus rattus and Microtus kikuchii), one insectivore (Crocidura russula), one bird (Gallus gallus), one amphibian (Rana nigromaculata) and one fish (Cyprinus carpio).","Phasianus colchicus/versicolor: in our study, the best match (99%) for MOTU number 3 in public databases corresponded to two species of the genus Phasianus (P.....colchicus and P.....versicolor)."]}
{"id":"00000000000000000003","value":"independent evolution of a blunt snout and short lower jaw in Etheostoma bellator Suttkus & Bailey, 1993 and E. longimanum (A), a pointed snout and elongate lower jaw in Percina squamata and E. sagitta."}
FIN >>>>>>>>>>>>>>>>>>>
Le fait que chaque objet soit sur une ligne, c’est bien. Mais pourquoi les id ont-ils été modifiés ?
Considérant que j’y mets le nom du fichier, lorsqu'il y a des données provenant de plusieurs fichiers,
c’est une information que j’aimerais bien récupérer.
C'est dû au script .ini qui regroupe les éléments du tableau de la requête en lots de 100. Il leur affecte des identifiants uniques.
Mais ils ont déjà des identifiants uniques.
Oui, tu considères que l'identifiant a du sens.
Mais ici chaque ligne correspond bien à un même identifiant (pas celui que tu avais donné, certes) et contient un tableau de valeurs (ou pas, dans le dernier cas).
Pour Nicolas, voilà le contenu de exemple1.json:
[
{
"id": "Arthropodes_02467",
"value": [
"SEVERAL SPECIES: 'CICHLASOMA' FACETUM, 'CICHLASOMA' TEMBE, CANIS SP., × VAPPACULUM SUPERBIENS AND 'GAMMARUS' HETEROCLITUS WERE FOUND. ",
"The diets of the most conspicuous reef‐fish species from northern Patagonia, the carnivorous species Pseudopercis semifasciata, Acanthistius patachonicus, Pinguipes brasilianus and Sebastes oculatus were studied. Pinguipes brasilianus had the narrowest diet and most specialized feeding strategy, preying mostly on reef‐dwelling organisms such as sea urchins, limpets, bivalves, crabs and polychaetes.",
"The samples used in the SIA were from fishes caught in one reef of the San Jose Gulf (Conos Reef, Fig. 1) during November 2003. Fishes were divided into the following groups: P. semifasciata small (range = 36–43 cm LT), medium (range = 53–61 cm LT) and large (range = 78–87 cm LT) with four specimens per group; A. patachonicus small (range = 12–19 cm LT) and large (range = 32–35 cm LT) with four specimens per group; S. oculatus small (range = 15–22 cm LT) and large (range = 26–30 cm LT) with three specimens per group; P. brasilianus small (range = 20–26 cm LT) and large (range = 38–41 cm LT) with three specimens per group.",
"Trophic diversity accumulation curves of (a) Pseudopercis semifasciata, (b) Acanthistius patachonicus and (c) Pinguipes brasilianus. Horizontal lines show Brillouin diversity index (Hz) values (Hz± 0·05 Hz) and the vertical line shows a value n− 2 (n = number of stomachs)."
]
},
{
"id": "Batraciens_00626",
"value": [
"Carnivore diet analysis based on next‐generation sequencing: application to the leopard cat (Prionailurus bengalensis) in Pakistan",
"Sequence alignment showing the specificity of the PrioB blocking oligonucleotide. The first six nucleotides of the PrioB blocking oligonucleotide overlap with the 12SV5R amplification primer. This sequence alignment contains two other Felidae species (Felis catus and Panthera tigris), another carnivore species from the Ursidae family (Ursus arctos), two rodents (Rattus rattus and Microtus kikuchii), one insectivore (Crocidura russula), one bird (Gallus gallus), one amphibian (Rana nigromaculata) and one fish (Cyprinus carpio).",
"Phasianus colchicus/versicolor: in our study, the best match (99%) for MOTU number 3 in public databases corresponded to two species of the genus Phasianus (P. colchicus and P. versicolor)."
]
},
{
"id": "Poissons_002097",
"value": "independent evolution of a blunt snout and short lower jaw in Etheostoma bellator Suttkus & Bailey, 1993 and E. longimanum (A), a pointed snout and elongate lower jaw in Percina squamata and E. sagitta."
}
]
l'erreur [expand] du genre "key cannot be null or undefined" semble vouloir indiqué que un id envoyé par le script ne correspond pas exactement un l'id envoyé par le serveur (ou qu'il n'y a plus d'id)
Je ne peux pas en être certain, mais je pense que c'est parce qu'il n'y a plus d'id.
L'erreur apparaît sur un numéro d'item supérieur de 1 au nombre d'objets qu'on envoie.
C'est comme si le flux n'était pas fermé.
tous les webservices fonctionnent uniquement avec le champ value:
le champ id: est facultatif.
Si un ws est utilisé dans lodex, lodex enverra un champ id: mais c'est un propre à lodex
par contre lors de l'échange entre le ws et un script/programme de la machine, le champ id: est obligatoire
id est généré automatiquement il est unique dans le flux . Mais un même identifiant peut être utilisé dans 2 flux différents.
L'erreur [mergeWith] <ReadError: key cannot be null or undefined
indique que le serveur reçoit du programme chargé du traitement, une ligne contenant une valeur JSON valide (car le parsing ne génère pas d'erreur) mais que cette valeur est :
le serveur considère que la ligne ne contient pas d'ID ( un id qu'il a lui même envoyé)
Dominique a modifié son programme pour fonctionner en JSON Lines.
J'ai corrigé un oubli (e7ff94e) de chemin absolu.
$ cat ~/data/irc3/exemple1.json | curl -X POST --data-binary @- http://localhost:31976/irc3sp Error: item #1 [delegate] <Error: item #4 [expand] <Error: [exec] <Error: [unpack] <SyntaxError: Unexpected end of JSON input>>>>
Je n'ai pas non plus vu de modification de Dominique qui justifierait le fait qu'il n'y ait plus fifo surnuméraires dans /tmp (mais c'est a priori une amélioration):
# ls -l /tmp total 8 prw-r--r-- 1 daemon daemon 0 Aug 29 13:36 fifo_irc3 -rw-r--r-- 1 daemon daemon 0 Aug 29 13:36 logIrc3.txt drwxr-xr-x 3 daemon daemon 4096 Aug 29 13:37 store drwxr-xr-x 1 daemon daemon 4096 Aug 9 21:03 v8-compile-cache-0
En rétablissant les logs de debug, on voit que seules des lignes vides passent par le wrapper:
bash-5.1# ls -l /tmp total 28 -rw-r--r-- 1 daemon daemon 50 Aug 29 13:48 debug_input_271 -rw-r--r-- 1 daemon daemon 50 Aug 29 13:48 debug_input_279 -rw-r--r-- 1 daemon daemon 50 Aug 29 13:48 debug_input_283 -rw-r--r-- 1 daemon daemon 50 Aug 29 13:48 debug_input_289 -rw-r--r-- 1 daemon daemon 50 Aug 29 13:48 debug_input_298 prw-r--r-- 1 daemon daemon 0 Aug 29 13:36 fifo_irc3 -rw-r--r-- 1 daemon daemon 0 Aug 29 13:36 logIrc3.txt drwxr-xr-x 3 daemon daemon 4096 Aug 29 13:37 store drwxr-xr-x 1 daemon daemon 4096 Aug 9 21:03 v8-compile-cache-0 bash-5.1# cat /tmp/debug_input_2* DEBUT<<<<<<<<<<<<<<<<<< FIN >>>>>>>>>>>>>>>>>>> DEBUT<<<<<<<<<<<<<<<<<< FIN >>>>>>>>>>>>>>>>>>> DEBUT<<<<<<<<<<<<<<<<<< FIN >>>>>>>>>>>>>>>>>>> DEBUT<<<<<<<<<<<<<<<<<< FIN >>>>>>>>>>>>>>>>>>> DEBUT<<<<<<<<<<<<<<<<<< FIN >>>>>>>>>>>>>>>>>>>
Bizarre: en supprimant le /dev/stdin en paramètre du cat, je récupère des lignes non vides (et un comportement similaire des fifos par job).
Et exactement la même erreur à la requête.
Mon poste:
$ cat ~/data/irc3/exemple1.json | curl -X POST --data-binary @- http://localhost:31976/irc3sp Error: item #1 [delegate] <Error: item #4 [expand] <Error: [exec] <Error: [unpack] <SyntaxError: Unexpected end of JSON input>>>>%
Le conteneur:
bash-5.1# ls -l /tmp
total 12
-rw-r--r-- 1 daemon daemon 2761 Aug 29 13:52 debug_input_319
prw-r--r-- 1 daemon daemon 0 Aug 29 13:36 fifo_irc3
prw-rw-rw- 1 daemon daemon 0 Aug 29 13:52 fifo_job_323
prw-rw-rw- 1 daemon daemon 0 Aug 29 13:52 fifo_job_326
prw-rw-rw- 1 daemon daemon 0 Aug 29 13:52 fifo_job_331
prw-rw-rw- 1 daemon daemon 0 Aug 29 13:52 fifo_job_335
-rw-r--r-- 1 daemon daemon 0 Aug 29 13:36 logIrc3.txt
drwxr-xr-x 3 daemon daemon 4096 Aug 29 13:37 store
drwxr-xr-x 1 daemon daemon 4096 Aug 9 21:03 v8-compile-cache-0
bash-5.1# cat /tmp/debug_input_*
DEBUT<<<<<<<<<<<<<<<<<<
{"id":"00000000000000000001","value":["SEVERAL SPECIES: 'CICHLASOMA' FACETUM, 'CICHLASOMA' TEMBE, CANIS SP., à VAPPACULUM SUPERBIENS AND 'GAMMARUS' HETEROCLITUS WERE FOUND. ","The diets of the most conspicuous reefâ43 cm LT), medium (range = 53â61 cm LT) and large (range = 78â87 cm LT) with four specimens per group; A. patachonicus small (range = 12â19 cm LT) and large (range = 32â35 cm LT) with four specimens per group; S. oculatus small (range = 15â22 cm LT) and large (range = 26â30 cm LT) with three specimens per group; P. brasilianus small (range = 20â26 cm LT) and large (range = 38â41 cm LT) with three specimens per group.","Trophic diversity accumulation curves of (a) Pseudopercis semifasciata, (b) Acanthistius patachonicus and (c) Pinguipes brasilianus. Horizontal lines show Brillouin diversity index (Hz) values (Hz± 0·05 Hz) and the vertical line shows a value nâ 2 (n = number of stomachs)."]}
{"id":"00000000000000000002","value":["Carnivore diet analysis based on nextâbash-5.1#
J'ai comme l'impression que Dominique n'avait pas tort en me signalant des problèmes d'encodage.
Peut-être est-dû à des variables comme LOCALE ou LANG qui ne sont pas positionnées ?
L'affichage du cat est médiocre, mais un less fournit plutôt ça (il y a bien 3 lignes d'objets JSON bien formés -- je n'ai pas recollé les lignes coupées par un passage à la ligne correspondant au copier-coller que j'ai fait, mais un wc -l /tmp/debug_input_319 confirme qu'il y a bien 5 lignes):
DEBUT<<<<<<<<<<<<<<<<<<
{"id":"00000000000000000001","value":["SEVERAL SPECIES: 'CICHLASOMA' FACETUM, 'CICHLASOMA' TEMBE, CANIS SP., Ã VAPPACULUM SUPERBIENS AND 'GAMMARUS' HETEROCLITUS WERE FOUND. ","The diets of t
he most conspicuous reefâe studied. Pinguipes brasilianus had the narrowest diet and most specialized feeding strategy, preying mostly on reefâolychaetes.","The samples used in the SIA were from fishes caught in one reef of the San Jose Gulf (Conos Reef, Fig. 1) during November 2003. Fishes were divided into the following groups: P. s
emifasciata small (range = 36â43 cm LT), medium (range = 53â61 cm LT) and large (range = 78â87 cm LT) with four specimens per group; A. patachonicus small (range = 12â19 cm
LT) and large (range = 32â35 cm LT) with four specimens per group; S. oculatus small (range = 15â22 cm LT) and large (range = 26â30 cm LT) with three specimens per group; P. bras
ilianus small (range = 20â26 cm LT) and large (range = 38â41 cm LT) with three specimens per group.","Trophic diversity accumulation curves of (a) Pseudopercis semifasciata, (b) Acant
histius patachonicus and (c) Pinguipes brasilianus. Horizontal lines show Brillouin diversity index (Hz) values (Hz± 0·05 Hz) and the vertical line shows a value nâ 2 (n = number of
stomachs)."]}
{"id":"00000000000000000002","value":["Carnivore diet analysis based on nextânt showing the specificity of the PrioB blocking oligonucleotide. The first six nucleotides of the PrioB blocking oligonucleotide overlap with the 12SV5R amplification primer. This sequence ali
gnment contains two other Felidae species (Felis catus and Panthera tigris), another carnivore species from the Ursidae family (Ursus arctos), two rodents (Rattus rattus and Microtus kikuchii),
one insectivore (Crocidura russula), one bird (Gallus gallus), one amphibian (Rana nigromaculata) and one fish (Cyprinus carpio).","Phasianus colchicus/versicolor: in our study, the best match
(99%) for MOTU number 3 in public databases corresponded to two species of the genus Phasianus (P. colchicus and P. versicolor)."]}
{"id":"00000000000000000003","value":"independent evolution of a blunt snout and short lower jaw in Etheostoma bellator Suttkus & Bailey, 1993 and E. longimanum (A), a pointed snout and elongat
e lower jaw in Percina squamata and E. sagitta."}
FIN >>>>>>>>>>>>>>>>>>>
Dans l’expression P. colchicus, il y a un blanc insécable et ce que l’on voit là, P. colchicus,
est le résultat d’un surencodage. Le texte a été converti d'ISO latin 1 vers UTF-8 alors qu'il était
déjà en UTF-8.
Est-ce que curl n’aurait pas besoin d’un -H "Content-type: application/json" ?
C'est possible, oui.
Mais après test, ça ne change rien.
Et avec -H "Content-type: application/json; charset=utf-8" ?
J'ai essayé aussi. Aucune différence.
Cette fois, le serveur a une réponse vide (pas d'erreur, mais pas de réponse).
Rien dans le debug, non plus. Comme s'il ne passait pas dans la fonction travail.
Ou plus précisément, s'il ne dépassait pas le stade data=$(cat).
Mais dans ce cas, pourquoi curl rend-il la main, sans erreur ?
$ cat ~/data/irc3/exemple1.json | curl -v -H 'Content-type: application/json; charset=utf-8' --data-binary @- http://localhost:31976/irc3sp * Trying 127.0.0.1... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 31976 (#0) > POST /irc3sp HTTP/1.1 > Host: localhost:31976 > User-Agent: curl/7.58.0 > Accept: */* > Content-type: application/json; charset=utf-8 > Content-Length: 2771 > Expect: 100-continue > < HTTP/1.1 100 Continue * We are completely uploaded and fine < HTTP/1.1 200 OK < Access-Control-Allow-Origin: * < Access-Control-Allow-Methods: POST, OPTIONS < Access-Control-Allow-Headers: * < Content-Encoding: identity < Content-Disposition: inline < Content-Type: application/json < Date: Tue, 30 Aug 2022 11:34:05 GMT < Connection: keep-alive < Keep-Alive: timeout=5 < Content-Length: 0 < * Connection #0 to host localhost left intact
Tout semble normal, sauf que rien n'est renvoyé (Content-Length: 0).
Sur la suggestion de Dominique, j'ai ajouté du debug au début du wrapper, au début et à la fin de la fonction travail.
État du /tmp quand le serveur est lancé, avant toute requête:
bash-5.1# ls -l /tmp total 8 -rw-r--r-- 1 daemon daemon 48 Aug 30 13:55 debug_input_37 prw-r--r-- 1 daemon daemon 0 Aug 30 13:55 fifo_irc3 -rw-r--r-- 1 daemon daemon 0 Aug 30 13:55 logIrc3.txt drwxr-xr-x 1 daemon daemon 4096 Aug 9 21:03 v8-compile-cache-0 bash-5.1# cat /tmp/debug_input_37 Tue Aug 30 13:55:27 UTC 2022 irc3_wrapper.sh ws
Le serveur IRC3 est bien lancé (sous-commande ws ).
La requête:
$ cat ~/data/irc3/exemple1.json | curl -v -H 'Content-type: application/json; charset=utf-8' --data-binary @- http://localhost:31976/irc3sp * Trying 127.0.0.1... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 31976 (#0) > POST /irc3sp HTTP/1.1 > Host: localhost:31976 > User-Agent: curl/7.58.0 > Accept: */* > Content-type: application/json; charset=utf-8 > Content-Length: 2771 > Expect: 100-continue > < HTTP/1.1 100 Continue * We are completely uploaded and fine < HTTP/1.1 500 Internal Server Error < Access-Control-Allow-Origin: * < Access-Control-Allow-Methods: POST, OPTIONS < Access-Control-Allow-Headers: * < Content-Encoding: identity < Content-Disposition: inline < Content-Type: text/plain < X-Error: RXJyb3I6IGl0ZW0gIzEgW2RlbGVnYXRlXSA8RXJyb3I6IGl0ZW0gIzQgW2V4cGFuZF0gPEVycm9yOiBbZXhlY10gPEVycm9yOiBbdW5wYWNrXSA8U3ludGF4RXJyb3I6IFVuZXhwZWN0ZWQgZW5kIG9mIEpTT04gaW5wdXQ+Pj4+CgkJCQkgICAgYXQgSlNPTi5wYXJzZSAoPGFub255bW91cz4pCgkJCQkgICAgYXQgL2FwcC9ub2RlX21vZHVsZXMvQGV6cy9jb3JlL2xpYi9zdGF0ZW1lbnRzL3VucGFjay5qczo0MToyMQoJCQkJICAgIGF0IEFycmF5LmZvckVhY2ggKDxhbm9ueW1vdXM+KQoJCQkJICAgIGF0IE9iamVjdC51bnBhY2sgKC9hcHAvbm9kZV9tb2R1bGVzL0BlenMvY29yZS9saWIvc3RhdGVtZW50cy91bnBhY2suanM6NDA6MjUpCgkJCQkgICAgYXQgRW5naW5lLmV4ZWNXaXRoICgvYXBwL25vZGVfbW9kdWxlcy9AZXpzL2NvcmUvbGliL2VuZ2luZS5qczoyMTQ6NDApCgkJCQkgICAgYXQgL2FwcC9ub2RlX21vZHVsZXMvQGV6cy9jb3JlL2xpYi9lbmdpbmUuanM6NzM6MTIKCQkJCSAgICBhdCBkcmFpbkl0ZW0gKC9hcHAvbm9kZV9tb2R1bGVzL2NvbmN1cnJlbnQtcXVldWUvaW5kZXguanM6OTY6MjEpCgkJCQkgICAgYXQgSW1tZWRpYXRlLmRyYWluIFthcyBfb25JbW1lZGlhdGVdICgvYXBwL25vZGVfbW9kdWxlcy9jb25jdXJyZW50LXF1ZXVlL2luZGV4LmpzOjc3Ojg0KQoJCQkJICAgIGF0IHByb2Nlc3NJbW1lZGlhdGUgKGludGVybmFsL3RpbWVycy5qczo0NjQ6MjEpCgkJCSAgICBhdCBFbmdpbmUuZXhlY1dpdGggKC9hcHAvbm9kZV9tb2R1bGVzL0BlenMvY29yZS9saWIvZW5naW5lLmpzOjIyMToxNyk= < Date: Tue, 30 Aug 2022 13:58:19 GMT < Connection: keep-alive < Keep-Alive: timeout=5 < Transfer-Encoding: chunked < * Connection #0 to host localhost left intact Error: item #1 [delegate] <Error: item #4 [expand] <Error: [exec] <Error: [unpack] <SyntaxError: Unexpected end of JSON input>>>>%
L'état du conteneur:
bash-5.1# ls -l /tmp total 32 -rw-r--r-- 1 daemon daemon 2852 Aug 30 13:58 debug_input_224 -rw-r--r-- 1 daemon daemon 76 Aug 30 13:58 debug_input_230 -rw-r--r-- 1 daemon daemon 76 Aug 30 13:58 debug_input_234 -rw-r--r-- 1 daemon daemon 76 Aug 30 13:58 debug_input_240 -rw-r--r-- 1 daemon daemon 76 Aug 30 13:58 debug_input_244 -rw-r--r-- 1 daemon daemon 48 Aug 30 13:55 debug_input_37 prw-r--r-- 1 daemon daemon 0 Aug 30 13:55 fifo_irc3 prw-rw-rw- 1 daemon daemon 0 Aug 30 13:58 fifo_job_230 prw-rw-rw- 1 daemon daemon 0 Aug 30 13:58 fifo_job_234 prw-rw-rw- 1 daemon daemon 0 Aug 30 13:58 fifo_job_240 prw-rw-rw- 1 daemon daemon 0 Aug 30 13:58 fifo_job_244 -rw-r--r-- 1 daemon daemon 0 Aug 30 13:55 logIrc3.txt drwxr-xr-x 3 daemon daemon 4096 Aug 30 13:58 store drwxr-xr-x 1 daemon daemon 4096 Aug 9 21:03 v8-compile-cache-0
Je ne comprends pas pourquoi un cat sur le fichier de debug contenant le JSON est tronqué à l'affichage (sans doute à cause du sur-encodage).
En tout cas, il contient:
Tue Aug 30 13:58:19 UTC 2022 irc3_wrapper.sh job Mise en attente du job 224 DEBUT<<<<<<<<<<<<<<<<<< ... FIN >>>>>>>>>>>>>>>>>>> Fin du job 224
Et les autres jobs ont un debug conforme à ce qu'on attend.
bash-5.1# cat /tmp/debug_input_230 Tue Aug 30 13:58:19 UTC 2022 irc3_wrapper.sh job Mise en attente du job 23
Hors-sujet: je devrais peut-être limiter
EZS_CONCURRENCYà 1, ça éviterait de polluer le système avec des jobs qui attendent des données et n'en reçoivent jamais.
Est-il possible que l'encodage pose problème?
Je vais essayer d'envoyer une requête sans caractères spéciaux.
J'ai supprimé les caractères exotiques de exemple1.json, pour créer exemple1-ascii.json:
[
{
"id": "Arthropodes_02467",
"value": [
"SEVERAL SPECIES: 'CICHLASOMA' FACETUM, 'CICHLASOMA' TEMBE, CANIS SP., x VAPPACULUM SUPERBIENS AND 'GAMMARUS' HETEROCLITUS WERE FOUND. ",
"The diets of the most conspicuous reef-fish species from northern Patagonia, the carnivorous species Pseudopercis semifasciata, Acanthistius patachonicus, Pinguipes brasilianus and Sebastes oculatus were studied. Pinguipes brasilianus had the narrowest diet and most specialized feeding strategy, preying mostly on reef-dwelling organisms such as sea urchins, limpets, bivalves, crabs and polychaetes.",
"The samples used in the SIA were from fishes caught in one reef of the San Jose Gulf (Conos Reef, Fig. 1) during November 2003. Fishes were divided into the following groups: P. semifasciata small (range = 36–43 cm LT), medium (range = 53–61 cm LT) and large (range = 78–87 cm LT) with four specimens per group; A. patachonicus small (range = 12–19 cm LT) and large (range = 32–35 cm LT) with four specimens per group; S. oculatus small (range = 15–22 cm LT) and large (range = 26–30 cm LT) with three specimens per group; P. brasilianus small (range = 20–26 cm LT) and large (range = 38–41 cm LT) with three specimens per group.",
"Trophic diversity accumulation curves of (a) Pseudopercis semifasciata, (b) Acanthistius patachonicus and (c) Pinguipes brasilianus. Horizontal lines show Brillouin diversity index (Hz) values (Hz± 0·05 Hz) and the vertical line shows a value n- 2 (n = number of stomachs)."
]
},
{
"id": "Batraciens_00626",
"value": [
"Carnivore diet analysis based on next-generation sequencing: application to the leopard cat (Prionailurus bengalensis) in Pakistan",
"Sequence alignment showing the specificity of the PrioB blocking oligonucleotide. The first six nucleotides of the PrioB blocking oligonucleotide overlap with the 12SV5R amplification primer. This sequence alignment contains two other Felidae species (Felis catus and Panthera tigris), another carnivore species from the Ursidae family (Ursus arctos), two rodents (Rattus rattus and Microtus kikuchii), one insectivore (Crocidura russula), one bird (Gallus gallus), one amphibian (Rana nigromaculata) and one fish (Cyprinus carpio).",
"Phasianus colchicus/versicolor: in our study, the best match (99%) for MOTU number 3 in public databases corresponded to two species of the genus Phasianus (P. colchicus and P. versicolor)."
]
},
{
"id": "Poissons_002097",
"value": "independent evolution of a blunt snout and short lower jaw in Etheostoma bellator Suttkus & Bailey, 1993 and E. longimanum (A), a pointed snout and elongate lower jaw in Percina squamata and E. sagitta."
}
]
J'ai ré-essayé, mais je n'ai pas vu de différence:
cat ~/data/irc3/exemple1-ascii.json | curl -v -H 'Content-type: application/json; charset=utf-8' --data-binary @- http://localhost:31976/irc3sp * Trying 127.0.0.1... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 31976 (#0) > POST /irc3sp HTTP/1.1 > Host: localhost:31976 > User-Agent: curl/7.58.0 > Accept: */* > Content-type: application/json; charset=utf-8 > Content-Length: 2841 > Expect: 100-continue > < HTTP/1.1 100 Continue * We are completely uploaded and fine < HTTP/1.1 500 Internal Server Error < Access-Control-Allow-Origin: * < Access-Control-Allow-Methods: POST, OPTIONS < Access-Control-Allow-Headers: * < Content-Encoding: identity < Content-Disposition: inline < Content-Type: text/plain < X-Error: RXJyb3I6IGl0ZW0gIzEgW2RlbGVnYXRlXSA8RXJyb3I6IGl0ZW0gIzQgW2V4cGFuZF0gPEVycm9yOiBbZXhlY10gPEVycm9yOiBbdW5wYWNrXSA8U3ludGF4RXJyb3I6IFVuZXhwZWN0ZWQgZW5kIG9mIEpTT04gaW5wdXQ+Pj4+CgkJCQkgICAgYXQgSlNPTi5wYXJzZSAoPGFub255bW91cz4pCgkJCQkgICAgYXQgL2FwcC9ub2RlX21vZHVsZXMvQGV6cy9jb3JlL2xpYi9zdGF0ZW1lbnRzL3VucGFjay5qczo0MToyMQoJCQkJICAgIGF0IEFycmF5LmZvckVhY2ggKDxhbm9ueW1vdXM+KQoJCQkJICAgIGF0IE9iamVjdC51bnBhY2sgKC9hcHAvbm9kZV9tb2R1bGVzL0BlenMvY29yZS9saWIvc3RhdGVtZW50cy91bnBhY2suanM6NDA6MjUpCgkJCQkgICAgYXQgRW5naW5lLmV4ZWNXaXRoICgvYXBwL25vZGVfbW9kdWxlcy9AZXpzL2NvcmUvbGliL2VuZ2luZS5qczoyMTQ6NDApCgkJCQkgICAgYXQgL2FwcC9ub2RlX21vZHVsZXMvQGV6cy9jb3JlL2xpYi9lbmdpbmUuanM6NzM6MTIKCQkJCSAgICBhdCBkcmFpbkl0ZW0gKC9hcHAvbm9kZV9tb2R1bGVzL2NvbmN1cnJlbnQtcXVldWUvaW5kZXguanM6OTY6MjEpCgkJCQkgICAgYXQgSW1tZWRpYXRlLmRyYWluIFthcyBfb25JbW1lZGlhdGVdICgvYXBwL25vZGVfbW9kdWxlcy9jb25jdXJyZW50LXF1ZXVlL2luZGV4LmpzOjc3Ojg0KQoJCQkJICAgIGF0IHByb2Nlc3NJbW1lZGlhdGUgKGludGVybmFsL3RpbWVycy5qczo0NjQ6MjEpCgkJCSAgICBhdCBFbmdpbmUuZXhlY1dpdGggKC9hcHAvbm9kZV9tb2R1bGVzL0BlenMvY29yZS9saWIvZW5naW5lLmpzOjIyMToxNyk= < Date: Wed, 31 Aug 2022 09:20:14 GMT < Connection: keep-alive < Keep-Alive: timeout=5 < Transfer-Encoding: chunked < * Connection #0 to host localhost left intact Error: item #1 [delegate] <Error: item #4 [expand] <Error: [exec] <Error: [unpack] <SyntaxError: Unexpected end of JSON input>>>>
Edit: il y a une différence mais c'est dans l'affichage du debug dans le conteneur. Cette fois, tout s'affiche normalement. Et je n'y vois pas d'anomalie.
bash-5.1# cat /tmp/debug_input_269
Wed Aug 31 09:20:14 UTC 2022
irc3_wrapper.sh job
Mise en attente du job 269
DEBUT<<<<<<<<<<<<<<<<<<
{"id":"00000000000000000001","value":["SEVERAL SPECIES: 'CICHLASOMA' FACETUM, 'CICHLASOMA' TEMBE, CANIS SP., x VAPPACULUM SUPERBIENS AND 'GAMMARUS' HETEROCLITUS WERE FOUND. ","The diets of the most conspicuous reef-fish species from northern Patagonia, the carnivorous species Pseudopercis semifasciata, Acanthistius patachonicus, Pinguipes brasilianus and Sebastes oculatus were studied. Pinguipes brasilianus had the narrowest diet and most specialized feeding strategy, preying mostly on reef-dwelling organisms such as sea urchins, limpets, bivalves, crabs and polychaetes.","The samples used in the SIA were from fishes caught in one reef of the San Jose Gulf (Conos Reef, Fig. 1) during November 2003. Fishes were divided into the following groups: P. semifasciata small (range = 36â43 cm LT), medium (range = 53â61 cm LT) and large (range = 78â87 cm LT) with four specimens per group; A. patachonicus small (range = 12â19 cm LT) and large (range = 32â35 cm LT) with four specimens per group; S. oculatus small (range = 15â22 cm LT) and large (range = 26â30 cm LT) with three specimens per group; P. brasilianus small (range = 20â26 cm LT) and large (range = 38â41 cm LT) with three specimens per group.","Trophic diversity accumulation curves of (a) Pseudopercis semifasciata, (b) Acanthistius patachonicus and (c) Pinguipes brasilianus. Horizontal lines show Brillouin diversity index (Hz) values (Hz± 0·05 Hz) and the vertical line shows a value n- 2 (n = number of stomachs)."]}
{"id":"00000000000000000002","value":["Carnivore diet analysis based on next-generation sequencing: application to the leopard cat (Prionailurus bengalensis) in Pakistan","Sequence alignment showing the specificity of the PrioB blocking oligonucleotide. The first six nucleotides of the PrioB blocking oligonucleotide overlap with the 12SV5R amplification primer. This sequence alignment contains two other Felidae species (Felis catus and Panthera tigris), another carnivore species from the Ursidae family (Ursus arctos), two rodents (Rattus rattus and Microtus kikuchii), one insectivore (Crocidura russula), one bird (Gallus gallus), one amphibian (Rana nigromaculata) and one fish (Cyprinus carpio).","Phasianus colchicus/versicolor: in our study, the best match (99%) for MOTU number 3 in public databases corresponded to two species of the genus Phasianus (P. colchicus and P. versicolor)."]}
{"id":"00000000000000000003","value":"independent evolution of a blunt snout and short lower jaw in Etheostoma bellator Suttkus & Bailey, 1993 and E. longimanum (A), a pointed snout and elongate lower jaw in Percina squamata and E. sagitta."}
FIN >>>>>>>>>>>>>>>>>>>
Fin du job 269
En tout cas, en sélectionnant la partie données du debug, et en l'envoyant manuellement à traiter, ça marche:
bash-5.1# cat /tmp/debug_input_269 | sed -n 5,7p | public/irc3_wrapper.sh job
[
{
"id": "00000000000000000001",
"species": [
"Acanthistius patachonicus",
"Pinguipes brasilianus",
"Pseudopercis semifasciata",
"Sebastes oculatus"
]
},
{
"id": "00000000000000000002",
"species": [
"Crocidura russula",
"Cyprinus carpio",
"Felis catus",
"Gallus gallus",
"Panthera tigris",
"Phasianus colchicus",
"Phasianus versicolor",
"Prionailurus bengalensis",
"Rana nigromaculata",
"Rattus rattus",
"Ursus arctos"
]
},
{
"id": "00000000000000000003",
"species": [
"Etheostoma bellator",
"Etheostoma longimanum",
"Etheostoma sagitta",
"Percina squamata"
]
}
]
La question que je me pose: expand s'attend-il à un tableau JSON ou bien à du JSON Lines ?
en retour [expand] attend ce qui a envoyé cad du JSON lines...
Dominique a corrigé IRC3sp.pl pour qu'il renvoie du JSON Lines.
$ cat ~/data/irc3/exemple1-ascii.json | curl -H 'Content-type: application/json; charset=utf-8' --data-binary @- http://localhost:31976/irc3sp
[{"id":"Arthropodes_02467"},{"id":"Batraciens_00626"},{"id":"Poissons_002097"}]
: il n'y plus d'erreur, on récupère du JSON
on ne récupère pas les valeurs. :'(
Y-a quand même du progrès : on récupère les id originaux. 
Mais, peut-être que le serveur attend value en sortie et pas species.
J'ai voulu tester à l'intérieur du conteneur, mais le résultat est décevant. Le programme ne rend pas la main, je suis obligé de l'arrêter avec un Ctrl-C:
bash-5.1# echo '{"id":"1", "value": ["Pseudopercis semifasciata, Acanthistius patachonicus, Pinguipes brasilianus and Sebastes oculatus were studied"]}' | su-exec daemon:daemon public/irc3_wrapper.sh job
^Ccat: can't open '/tmp/fifo_job_433': No such file or directory
Est-ce que ça a à voir avec la création tardive du fifo?
J'ai essayé en la remettant à son ancienne place (début de la fonction travail), mais le résultat est le même.
Après l'ajout du champ value par Dominique (j'avoue que je n'avais pas repéré que la structure n'était pas celle attendue), ça marche !
cat ~/data/irc3/exemple1.json | curl -H 'Content-type: application/json; charset=utf-8' --data-binary @- http://localhost:31976/irc3sp
[{"id":"Arthropodes_02467","value":{"species":["Acanthistius patachonicus","Pinguipes brasilianus","Pseudopercis semifasciata","Sebastes oculatus"]}},{"id":"Batraciens_00626","value":{"species":["Crocidura russula","Cyprinus carpio","Felis catus","Gallus gallus","Panthera tigris","Phasianus colchicus","Prionailurus bengalensis","Rana nigromaculata","Rattus rattus","Ursus arctos"]}},{"id":"Poissons_002097","value":{"species":["Etheostoma bellator","Etheostoma longimanum","Etheostoma sagitta","Percina squamata"]}}]
Le commit 5dc6074 résout le problème.
Une fois que le serveur est en route, si on fait
curl -X POST --data '[{"id": "1", "value": ["Pseudopercis semifasciata, Acanthistius patachonicus, Pinguipes brasilianus and Sebastes oculatus were studied"]}]' http://localhost:31976/irc3spcurl ne rend pas la main, et 5 pipe nommés sont créés dans le container.
Avant:
Après:
Normalement, un seul pipe nommé devrait être suffisant (un seul objet passé).
Et il devrait être lu par le démon
IRC3sp.pl, puis supprimé, une fois la réponse fournie.Ce n'est pas le cas.