vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2021-11-08T16:16:22+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/1609Revoir la liste dans germline.js2021-11-08T16:16:22+01:00Vidjil TeamRevoir la liste dans germline.jsApparitions impromptues de différents TRD dans d'autres germlines.
***
Merci Florian pour la tâche :)
N'hésite pas à nous mettre en followers au moins. Ça nous permet d'être au courant de la création de la tâche et de son évolution.
***
...Apparitions impromptues de différents TRD dans d'autres germlines.
***
Merci Florian pour la tâche :)
N'hésite pas à nous mettre en followers au moins. Ça nous permet d'être au courant de la création de la tâche et de son évolution.
***
@nobody @mikael-s @Duez @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1607Des e-valeurs sont supérieures à 12023-03-01T17:05:07+01:00Vidjil TeamDes e-valeurs sont supérieures à 1Pour moi, elles ne pouvaient pas être supérieures à 1 pourtant quand on va ici : http://rbx.vidjil.org/browser/index.html?patient=614&config=25 on a deux i orange et les deux e-valeurs sont supérieures à 1.
***
Le patient a été supprimé....Pour moi, elles ne pouvaient pas être supérieures à 1 pourtant quand on va ici : http://rbx.vidjil.org/browser/index.html?patient=614&config=25 on a deux i orange et les deux e-valeurs sont supérieures à 1.
***
Le patient a été supprimé... à voir si on peut le refaire sur un autre fichier, et surtout sur la nouvelle version. En attendant, la séquence en question est dans notable, et elle donne une e-valeur correcte seule.
***
Ici on en a aussi : http://rbx.vidjil.org/browser/index.html?patient=3837&config=2 : e-valeur de 568 pour le clone en J3
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1603top n'affiche pas le nombre de clones attendu2016-11-29T14:38:28+01:00Vidjil Teamtop n'affiche pas le nombre de clones attenduExemple : http://rbx.vidjil.org/browser/index.html?patient=609&config=2
Si on diminue le nombre de clones au minimum (top 5), au diag on a seulement deux clones affichés (mais le fichier .vidjil est correct et dans les top 5 on a bien 5 ...Exemple : http://rbx.vidjil.org/browser/index.html?patient=609&config=2
Si on diminue le nombre de clones au minimum (top 5), au diag on a seulement deux clones affichés (mais le fichier .vidjil est correct et dans les top 5 on a bien 5 clones pour chacun des points de suivi).
Cela ne semble pas être un problème du fuse.py mais de la visu.
***
Euh, pas reproductible ? (Ou l'exemple a changé ?) L'exemple a plein de clones mergés, c'est dur d'y voir clair, mais au Diag on voit bien plein de clones.
***
Au 4è point, on a que deux clones majoritaires et trois clones au total (en mettant le filter à 5).
***
ok
***
J'insiste : au 4è point, après un "reset user clones" et un top à 5, je vois bien... 5 clones, le dernier faisant 1.442%.
***
Ah oui… le reset user clones. On va dire que c'est bon alors.
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1597Nombre de délétions incorrects dans le J et (surtout) incohérent avec celui d...2016-11-29T14:38:23+01:00Vidjil TeamNombre de délétions incorrects dans le J et (surtout) incohérent avec celui du gène D90776df (sur bonsai)
***
notable/0298, à comprendre, cela devrait fonctionner avec les changements récents
***
60a1562. On faisait n'importe quoi sur les jonctions J/D depuis... toujours (février 2013, dccec03).
***
@magiraud90776df (sur bonsai)
***
notable/0298, à comprendre, cela devrait fonctionner avec les changements récents
***
60a1562. On faisait n'importe quoi sur les jonctions J/D depuis... toujours (février 2013, dccec03).
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1595Un test ne passe pas chez Ping2016-11-29T14:38:22+01:00Vidjil TeamUn test ne passe pas chez Pingpython ../../tools/format_json.py -1
n'est pas allée jusqu'au bout. Pb de sync ? parenthésage ?
***
On dirait que la sortie standard de
!LAUNCH: ../../vidjil -z 0 -G ../../germline/IGH -w 60 -r 5 -b data ../../data/Stanford_S22.fasta ...python ../../tools/format_json.py -1
n'est pas allée jusqu'au bout. Pb de sync ? parenthésage ?
***
On dirait que la sortie standard de
!LAUNCH: ../../vidjil -z 0 -G ../../germline/IGH -w 60 -r 5 -b data ../../data/Stanford_S22.fasta ; cat out/data.vidjil
***
C'était donc un pb de version python
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1580Décaler la window dans certains cas2020-04-15T09:18:25+02:00Vidjil TeamDécaler la window dans certains casMikaël (#1579) : "... Du coup cela décale la fenêtre vers la droite et on a une moins bonne spécificité."
Indépendamment de cela, on a souvent des soucis à aller trop vers la droite. Les J sont courts (ou tout du moins la position de ...Mikaël (#1579) : "... Du coup cela décale la fenêtre vers la droite et on a une moins bonne spécificité."
Indépendamment de cela, on a souvent des soucis à aller trop vers la droite. Les J sont courts (ou tout du moins la position de certaines amorces...).
Y aurait-il des cas où on aimerait plus revenir à gauche ? Surtout si on prend un grand `-w`, 80, 100 ou plus.
(Avoir un truc flexible, en fonction de la taille de la read, semble difficile, puisqu'on veut avant tout regrouper les reads en clones...)
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1576Pas de représentative pour les séquences étiquetées2017-07-05T09:15:56+02:00Vidjil TeamPas de représentative pour les séquences étiquetéesstanford-labels.should_get passe... mais génère une exception "No representative for junction".
C'est normal vu les conditions de WindowsStorage::getRepresentativeComputer().
Cela veut dire qu'on peut utiliser -FaW... mais à la conditio...stanford-labels.should_get passe... mais génère une exception "No representative for junction".
C'est normal vu les conditions de WindowsStorage::getRepresentativeComputer().
Cela veut dire qu'on peut utiliser -FaW... mais à la condition de mettre -r 1.
En tout cas, c'est un bug.
***
f3cab65
***
@magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1565Les affect values ne sont pas alignées avec la séquence dans le segmenteur2021-04-08T08:30:17+02:00Vidjil TeamLes affect values ne sont pas alignées avec la séquence dans le segmenteurPar exemple ici http://rbx.vidjil.org/browser/?patient=481&config=26 et aller voir les affectations pour le clone à 1,5%
***
Je me sens fautif :)
***
Mais alors assigne-toi la tâche, pour soulager ta peine :)
***
ah oui, je me sens très ...Par exemple ici http://rbx.vidjil.org/browser/?patient=481&config=26 et aller voir les affectations pour le clone à 1,5%
***
Je me sens fautif :)
***
Mais alors assigne-toi la tâche, pour soulager ta peine :)
***
ah oui, je me sens très soulagé :)
***
à voir en novembre, avec IMGT/CSV
***
-> François nov/déc
***
François va regarder très bientôt.
***
@magiraud @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1564Longueur des reads d'un clone, prendre tous les reads en compte2016-11-29T14:37:58+01:00Vidjil TeamLongueur des reads d'un clone, prendre tous les reads en compteLa longueur des reads d'un clone est actuellement calculée à partir de… [cherche dans le code] la moyenne de la longueur des premiers reads analysés pour calculer la représentative. Il ne s'agit pas de tous les reads stockés (ça peut en ...La longueur des reads d'un clone est actuellement calculée à partir de… [cherche dans le code] la moyenne de la longueur des premiers reads analysés pour calculer la représentative. Il ne s'agit pas de tous les reads stockés (ça peut en être très loin).
Problème : on peut avoir des chimères, et elles vont se trouver parmi les premières séquences considérées. Par exemple, la fameuse séquence de Yann (patient http://rbx.vidjil.org/browser/index.html?patient=444&config=11 clone TRDV1*01 -5/0/-3 TRDD2*01 -1/0/-7 TRAJ29*01), sur ma machine j'ai une représentative de 257 bp (58% of 438 bp). On pourrait se dire : c'est moche. En fait non.
On va dans le tableau de Yann et la taille en électrophorèse est 255 !
Bilan : il faudrait calculer la taille sur les reads stockés. Le BinReadStorage peut donner l'info (il peut même donner l'info pour tous les reads et pas seulement pour ceux qu'il stocke).
Maintenant qu'on propose le coverage comme un axe d'analyse en disant que c'est une bonne mesure de la qualité, c'est assez critique comme problème.
***
De mémoire, n'est-ce pas sur l'ensemble des 2000 premiers reads ? Est-ce que ce 2000 ne devrait pas atténuer les quelques chimères au début ? Est-ce que cela signifie, pour la séquence de Yann, que de nombreux reads chimériques sont là ?
Cela dit, même si c'est le cas, quand on a beaucoup de reads, les 2000 premiers peuvent faire sens "les plus gros"... Mais les résultats donc ne sont plus cohérents entre un gros clone 20 000 reads et un petit 2 000.
Donc tu as sans doute raison, il faudra faire cette moyenne sur *tous les reads*. Mais alors la coverage pourra être bien au-dessus de 1.00, s'il y a des petits reads...
***
Ben non, c'est pas sur les 2000 premiers… j'ai regardé dans le code. Tu avais mis le calcul de la longueur dans la boucle qui calcule la représentative. Mais pour le calcul de la représentative je ne parcours pas tous les reads. Je m'arrête au read qui m'a donné la meilleure représentative + stability_limit (30 par défaut).
***
Argh.
***
(Et j'ai donc mal répondu à Yann tout à l'heure.)
Et oui, ce serait bien de le faire sur l'ensemble des reads via BinReadStorage.
Idéalement instancier un objet Stats par BinReadStorage, cela permettra d'avoir plus que la longueur si un jour Stats fait mieux (la distribution par exemple)
***
Notons que le "av. len" dans les infos du run est lui bien calculé, sur toutes les reads (windowExtractor.cpp:57)
***
38cbe4d
Finalement le Stats est instancié dans windows.cpp : stats_by_windows, de la même manière que germline_by_windows, status_by_windows et seqs_by_windows.
(On devrait faire du ménage là-dedans, et bouger tous ces trucs dans le BinReads ?)
J'ai bien vu qu'il y avait aussi des calculs de longueur dans BinReads, on aurait pu le faire avec (voir tâche Stats / BinReads), mais je maîtrisais mieux l'autre côté :-)
***
Il y a quelque chose qu'on n'utilise pas assez dans producteev c'est le « in progress ». Avant d'aller manger j'avais un code qui faisait ça (en passant par BinReadStorage), mais qui ne compilait pas encore. Ni moi, ni toi n'avons utilisé le « in progress », d'où le doublon.
***
oui, tout à fait.
***
désolé...
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1552Une représentative, plusieurs clones2016-11-29T14:37:49+01:00Vidjil TeamUne représentative, plusieurs clonesCe sont des exemples donnés par Yann, par exemple sur ce patient http://rbx.vidjil.org/browser/index.html?patient=444&config=11
Le cas a été clusterisé par Yann, mais il suffit d'aller en TRD (il y a un seul clone). Ce clone correspond ...Ce sont des exemples donnés par Yann, par exemple sur ce patient http://rbx.vidjil.org/browser/index.html?patient=444&config=11
Le cas a été clusterisé par Yann, mais il suffit d'aller en TRD (il y a un seul clone). Ce clone correspond à un cluster de deux clones, l'un en VdJa et l'autre en TRD.
On ne voit plus ce cas-là avec la e-valeur, mais c'est peut-être pour une raison différente…
***
Cas ici aussi (même procédé pour le repérer) http://rbx.vidjil.org/browser/index.html?patient=169&config=11
ou encore ici (gros clone en TRD+ avec du Vd2/Dd3 repéré sans le Ja29) : http://rbx.vidjil.org/browser/index.html?patient=167&config=11 → on n'a plus le fichier de séquences
***
impressionnant, joli bug en effet
***
commit 07adde3
> Author: Mikael Salson <mikael.salson@univ-lille1.fr>
> kmerstore.h: Insert properly the revcomp kmers with unsymmetrical seeds.
> If the seed is not symmetrical (as with TRA and VdJa), we can't just reverse the seed.
> We need to take back the original substring, reverse it and then take the seed.
Impressionnant que cela ait passé tous les tests jusqu'à maintenant !
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1551Impossible d'afficher la fenêtre d'information à l'intérieur d'un cluster2017-04-06T18:25:10+02:00Vidjil TeamImpossible d'afficher la fenêtre d'information à l'intérieur d'un cluster
***
@Duez
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1550selected locus est initialisé avec le nombre de segmented reads2016-11-29T14:37:48+01:00Vidjil Teamselected locus est initialisé avec le nombre de segmented readsAlors qu'en fait la somme des reads segmentés sur les locus montrés ne fait pas forcément le nombre total de reads segmentés (il peut y avoir des systèmes non montrés avec des clones n'apparaissant pas dans le top 100).
Pour voir le bu...Alors qu'en fait la somme des reads segmentés sur les locus montrés ne fait pas forcément le nombre total de reads segmentés (il peut y avoir des systèmes non montrés avec des clones n'apparaissant pas dans le top 100).
Pour voir le bug : désélectionner des locus et en ré-sélectionner.
***
et de plus, si on déselectionne tout et resélectionne tout, le selected est... supérieur au nombre de segmented reads
http://rbx.vidjil.org/browser/index.html?patient=444&config=11
***
Apparemment ce n'est plus reproductible.
L'exemple précédent était très vieux.
Plus de soucis : http://rbx.vidjil.org/browser/index.html?patient=444&config=25
J'ai bien l'impression que, maintenant, à l'init, la somme est directement le segmented reads. Mikaël, tu confirmes ?
***
Oui ça semble bon. Marqué terminé.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1548Problème de D7-J1 en complémentaire2017-03-09T10:21:19+01:00Vidjil TeamProblème de D7-J1 en complémentaireSéquence D7-J1 trouvée en IGH (et pas IGH+) quand elle est en complémentaire ?
Le problème vient peut-être de leur protocole de séquençage qui n'est pas équivalent dans les deux sens (du coup on ne se retrouve pas avec les mêmes séquen...Séquence D7-J1 trouvée en IGH (et pas IGH+) quand elle est en complémentaire ?
Le problème vient peut-être de leur protocole de séquençage qui n'est pas équivalent dans les deux sens (du coup on ne se retrouve pas avec les mêmes séquences en aval et en amont et on pourrait détecter des trucs qui ressemblent à du V). Avec la e-valeur, je ne pense pas que ça passe.
À tester…
***
Probablement un problème similaire à 1 clone, 2 représentatives. Test ajouté, passe.
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1543bug de segmentation sur deux slaves2017-07-05T09:15:56+02:00Vidjil Teambug de segmentation sur deux slavesDepuis mes commits du 24 avril, le build est cassé... sur exactement deux slaves. Les autres fonctionnent.
ks.getSegmentationStatus() == UNSEG_TOO_FEW_J failed (testSegment.cpp:161)
# 9 ! seed TRG UNSEG too few (0) 1.000000e+00 5.2...Depuis mes commits du 24 avril, le build est cassé... sur exactement deux slaves. Les autres fonctionnent.
ks.getSegmentationStatus() == UNSEG_TOO_FEW_J failed (testSegment.cpp:161)
# 9 ! seed TRG UNSEG too few (0) 1.000000e+00 5.263273e17/1.000000e+00
+G+G+G+G+G+G+G+G+G _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Je devrais apprendre à me logguer en ssh sur les slaves pour comprendre ce qu'il se passe :)
***
C'est cadeau :
Add these lines to your .ssh/config file
Host *.ci
ProxyCommand ssh mgir001@ci-ssh.inria.fr "/usr/bin/nc `basename %h .ci` %p"
SSH command : ssh ci@bonsai-debian-squeeze.ci
Le mot de passe de l'utilisateur ci est… ci et celui de root est… password
***
Et évidemment mettre ta clé publique sur ci.inria.fr
***
merci !
Et pour devenir "Slave Admin" sur https://ci.inria.fr/project/bonsai/users, il faut que je corrompe un des Admin ?
***
done. bon we.
***
Cela fonctionne, merci et bon we !
Juste pour info, dans mon .ssh/config, comme j'utilise une "autre clé", j'ai du spécifier IdentityFile, mais pour la passerelle, en rajoutant :
Host ci-ssh.inria.fr
IdentityFile = ~/.ssh/id_dsa.xxxxxx
***
a72ef27
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1533Sélection par colonne/ligne et clone 'other'2016-11-29T14:37:33+01:00Vidjil TeamSélection par colonne/ligne et clone 'other'Le clone 'other' se sélectionne de temps en temps (si on clique sur '0', sur '?'). Ce n'est pas un vrai clone, il ne doit pas être sélectionné.
***
C'est toujours le cas ??
Si oui, quelle est la procédure pour voir ce bug ?
***
Effectiv...Le clone 'other' se sélectionne de temps en temps (si on clique sur '0', sur '?'). Ce n'est pas un vrai clone, il ne doit pas être sélectionné.
***
C'est toujours le cas ??
Si oui, quelle est la procédure pour voir ce bug ?
***
Effectivement, je n'arrive pas à le reproduire... pas de bug donc :-)
***
@Cyanaelhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1532Sélection par colonne/ligne : '?' sélectionne trop de choses2016-11-29T14:37:33+01:00Vidjil TeamSélection par colonne/ligne : '?' sélectionne trop de chosesbug vu par Mikaël : cliquer sur '?' sélectionne aussi les clones d'autres locus, ce qui n'est pas souhaitable.
***
commit : 0f455c2
***
@Cyanaelbug vu par Mikaël : cliquer sur '?' sélectionne aussi les clones d'autres locus, ce qui n'est pas souhaitable.
***
commit : 0f455c2
***
@Cyanaelhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1531Avec FF37, problèmes de chargement complet du browser2016-11-29T14:37:32+01:00Vidjil TeamAvec FF37, problèmes de chargement complet du browserC'est très reproductible sur un slave Jenkins. Ça m'est arrivé chez moi (mais exceptionnellement, d'ailleurs je n'ai pas FF37). C'est aussi arrivé chez Mathieu. Si on charge des données avec un seul point (scatterplot only) cela donne ce...C'est très reproductible sur un slave Jenkins. Ça m'est arrivé chez moi (mais exceptionnellement, d'ailleurs je n'ai pas FF37). C'est aussi arrivé chez Mathieu. Si on charge des données avec un seul point (scatterplot only) cela donne ce qui est dans l'image attachée. Dans ce cas on peut sélectionner des clones mais rien ne s'affichera dans le segmenteur. Cela peut aussi arriver avec plusieurs points de suivi, mais c'est beaucoup moins reproductible (sur Jenkins). Dans ce cas le graphe de suivi ne s'affiche pas (il reste un rectangle blanc à la place). Dans tous les cas un update du model permet de revenir à la situation normale.
L'erreur (que l'on peut voir dans la capture d'écran) provient de model.js : « TypeError: this.view[i].update is not a function model.js:834:12 ». On dirait en fait qu'une des vues n'est pas complètement construite lorsqu'il essaie de faire un update dessus (mais c'est juste une impression).
Ceci est un bug trouvé grâce aux tests fonctionnels.
***
c872e75 : super, Marc, les tests fonctionnels disent qu'ils sont contents !
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1530L'accès à la config n'est pas vérifié : bug ou feature ?2017-01-31T17:37:21+01:00Vidjil TeamL'accès à la config n'est pas vérifié : bug ou feature ?Dans la fonction get_data (controllers/default.py): on vérifie que l'utilisateur a les droits sur le patient, mais pas sur la config. Je pose juste la question. Si c'est un bug ne pas le corriger juste me le dire : je vais bientôt pousse...Dans la fonction get_data (controllers/default.py): on vérifie que l'utilisateur a les droits sur le patient, mais pas sur la config. Je pose juste la question. Si c'est un bug ne pas le corriger juste me le dire : je vais bientôt pousser des choses autour du module d'authentification (et je pourrais corriger…).
***
idem, à fermer ?
***
À vue de nez l'accès à la config ne m'a pas l'air vérifié dans get_data. Mais est-un bug ou une feature ? Ça permet de montrer des résultats à des utilisateurs (en leur donnant le lien) sur des configs auxquelles ils n'ont normalement pas accès.
***
Au lancement d'un run on vérifie bien que l'utilisateur ai le droit d'utiliser la config, de même à l'affichage dans la vue du sample-set.
***
Au lancement d'un run on vérifie bien que l'utilisateur ai le droit d'utiliser la config, de même à l'affichage dans la vue du sample-set.
***
merci. (Le fait d'avoir recrée un compte pour Marc fait que plein de "vieilles tâches" sont remontées, on peut nettoyer et fermer bcp de trucs sans trop se prendre la tête)
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1529should_get : * est parfois shell-étendu2016-11-29T14:37:30+01:00Vidjil Teamshould_get : * est parfois shell-étendu$ ok
1: bla.* 0
$ fait une extension (shell) du .*
1: bla .* 0
est-ce normal ?
***
Tu l'as corrigé par 83167c9 ?
***
Oui, d'ailleurs c'était une extension uniquement dans l'output (ça n'impactait pas la regex).
***
@mikael-s$ ok
1: bla.* 0
$ fait une extension (shell) du .*
1: bla .* 0
est-ce normal ?
***
Tu l'as corrigé par 83167c9 ?
***
Oui, d'ailleurs c'était une extension uniquement dans l'output (ça n'impactait pas la regex).
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1524web2py reste bloqué et ne répond plus2016-11-29T14:37:26+01:00Vidjil Teamweb2py reste bloqué et ne répond pluscf. mon message d'hier sur la tâche « Avoir une méthode non bloquante pour 'compare patient' » :
Serait-ce plus général ? Il y a en ce moment uwsgi qui tourne à 80% et mysql à 15% (depuis une dizaine de minutes) et rbx est complètement ...cf. mon message d'hier sur la tâche « Avoir une méthode non bloquante pour 'compare patient' » :
Serait-ce plus général ? Il y a en ce moment uwsgi qui tourne à 80% et mysql à 15% (depuis une dizaine de minutes) et rbx est complètement bloqué. J'ai lancé plusieurs Vidjil d'affilée mais rien d'autre sur le serveur. dev.vidjil.org continue à répondre.
***
uptime robot nous dit que rbx/web2py est resté dans les choux mercredi 15/04 entre 18h01 et 18h10 puis entre 18h16 et 18h30 (j'avais lancé plusieurs vidjil). Les requêtes que j'avais lancé (accéder à la page patients) sont visiblement restées bloquées sur le serveur et ont été exécutées à 18h30 (je n'étais plus au bureau, mon ordinateur était déconnecté). Mais il ne s'est rien passé entre 18h20 et 18h30…
[19664] 2015-04-15 18:20:34,535 INFO - task.py:313 None [2657] c26: 'fuse' finished - /mnt/result/tmp/out-002657//002657.fused
[19115] 2015-04-15 18:30:33,890 DEBUG - patient.py:411 134.206.10.234/team/LIFL <Mikaël> patient list (0.366s)
[19116] 2015-04-15 18:30:33,950 DEBUG - db.py:242 Creating logger
[19114] 2015-04-15 18:30:34,092 DEBUG - db.py:242 Creating logger
[19115] 2015-04-15 18:30:34,291 DEBUG - default.py:221 134.206.11.64/team/LIFL <Marc> get_data (394) c25 -> /mnt/result/results//fused_file.fused_file.a2c399ebfcb9feba.3030323430382e6675736564.fused
[19116] 2015-04-15 18:30:34,415 DEBUG - default.py:221 134.206.11.64/team/LIFL <Marc> get_data (394) c25 -> /mnt/result/results//fused_file.fused_file.a2c399ebfcb9feba.3030323430382e6675736564.fused
[20576] 2015-04-15 18:30:34,538 DEBUG - db.py:242 Creating logger
[20572] 2015-04-15 18:30:34,579 DEBUG - db.py:242 Creating logger
[20574] 2015-04-15 18:30:34,658 DEBUG - db.py:242 Creating logger
[19114] 2015-04-15 18:30:34,679 DEBUG - patient.py:411 134.206.10.234/team/LIFL <Mikaël> patient list (0.558s)
[20574] 2015-04-15 18:30:34,802 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (394)
[19115] 2015-04-15 18:30:34,911 DEBUG - patient.py:411 134.206.11.64/team/LIFL <Marc> patient list (0.438s)
[19117] 2015-04-15 18:30:35,235 DEBUG - patient.py:411 134.206.10.234/team/LIFL <Mikaël> patient list (0.329s)
[19057] 2015-04-15 18:30:35,451 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (394) c25 -> /mnt/result/results//fused_file.fused_file.a2c399ebfcb9feba.3030323430382e6675736564.fused
[19114] 2015-04-15 18:30:35,669 DEBUG - patient.py:411 134.206.11.64/team/LIFL <Marc> patient list (0.482s)
[19057] 2015-04-15 18:30:35,799 DEBUG - default.py:221 134.206.11.64/team/LIFL <Marc> get_data (394) c25 -> /mnt/result/results//fused_file.fused_file.a2c399ebfcb9feba.3030323430382e6675736564.fused
[19057] 2015-04-15 18:30:36,165 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (474)
***
Ce matin, rebelote, je visualise plusieurs patients de Fred et rbx/web2py est de nouveau dans les choux. Pendant ce temps dev.vidjil.org répond (c'est donc juste l'instance web2py qui rame, ce n'est pas le serveur physique). Même chose que hier uwsgi est ~85% et mysql ~15% du CPU
***
Reproduit sous dev. À partir des log on peut voir que la consultation ne posait pas problème mais ce qui posait problème ce sont les get_data apparemment. Visiblement web2py n'était pas complètement bloqué puisqu'il continuait à faire des « Creating logger » dans db.py toutes les 20 minutes :
[19112] 2015-04-16 17:50:46,357 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (435)
[19112] 2015-04-16 17:50:46,483 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (435)
[19112] 2015-04-16 17:50:46,778 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (436)
[19112] 2015-04-16 17:50:47,263 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (437)
[19112] 2015-04-16 17:50:47,667 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (438)
[19112] 2015-04-16 17:50:48,342 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (439)
[19112] 2015-04-16 17:50:48,952 DEBUG - patient.py:94 134.206.10.234/team/LIFL <Mikaël> patient (440)
[2250] 2015-04-16 18:10:51,326 DEBUG - db.py:242 Creating logger
[3624] 2015-04-16 18:30:53,367 DEBUG - db.py:242 Creating logger
[5082] 2015-04-16 18:50:55,571 DEBUG - db.py:242 Creating logger
[6679] 2015-04-16 19:10:57,785 DEBUG - db.py:242 Creating logger
[8030] 2015-04-16 19:30:59,971 DEBUG - db.py:242 Creating logger
[9394] 2015-04-16 19:51:01,214 DEBUG - db.py:242 Creating logger
[11057] 2015-04-16 20:11:03,395 DEBUG - db.py:242 Creating logger
[12409] 2015-04-16 20:31:05,566 DEBUG - db.py:242 Creating logger
[13773] 2015-04-16 20:51:08,579 DEBUG - db.py:242 Creating logger
[15375] 2015-04-16 21:11:09,977 DEBUG - db.py:242 Creating logger
[16730] 2015-04-16 21:31:11,276 DEBUG - db.py:242 Creating logger
[18096] 2015-04-16 21:51:13,396 DEBUG - db.py:242 Creating logger
[19711] 2015-04-16 22:11:15,589 DEBUG - db.py:242 Creating logger
[21074] 2015-04-16 22:31:17,812 DEBUG - db.py:242 Creating logger
[22440] 2015-04-16 22:51:20,011 DEBUG - db.py:242 Creating logger
[24037] 2015-04-16 23:11:21,230 DEBUG - db.py:242 Creating logger
[24037] 2015-04-16 23:11:21,339 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c2 -> /mnt/result/results-dev//fused_file.fused_file.af34bae840fa5459.3030323235392e6675736564.fused
[24037] 2015-04-16 23:11:21,447 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c1 -> /mnt/result/results-dev//fused_file.fused_file.9fecdb93375410bd.3030323236312e6675736564.fused
[24037] 2015-04-16 23:11:21,523 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c2 -> /mnt/result/results-dev//fused_file.fused_file.af34bae840fa5459.3030323235392e6675736564.fused
[24037] 2015-04-16 23:11:21,591 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c2 -> /mnt/result/results-dev//fused_file.fused_file.af34bae840fa5459.3030323235392e6675736564.fused
[24037] 2015-04-16 23:11:21,661 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c2 -> /mnt/result/results-dev//fused_file.fused_file.af34bae840fa5459.3030323235392e6675736564.fused
[24037] 2015-04-16 23:11:21,729 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c2 -> /mnt/result/results-dev//fused_file.fused_file.af34bae840fa5459.3030323235392e6675736564.fused
[24037] 2015-04-16 23:11:21,810 DEBUG - default.py:221 134.206.10.234/team/LIFL <Mikaël> get_data (440) c1 -> /mnt/result/results-dev//fused_file.fused_file.9fecdb93375410bd.3030323236312e6675736564.fused
***
Mais charger plein de data d'un coup ne semble pas lui poser problème. En revanche ce qui semble poser problème c'est bourriner le lien « prev » (sur une fiche patient) alors qu'on est déjà au bout.
***
Ah ben oui…
while db.patient[new_id] is None and int(new_id) > 0:
new_id = str(int(new_id)+int(request.vars["next"]))
Une jolie boucle infinie (next > 0)
***
merci et désolé :)
***
@magiraud @mikael-s @Duez