vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2017-05-22T17:09:00+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2011Ne pas lancer fuse quand le nombre de samples est trop important ?2017-05-22T17:09:00+02:00Vidjil TeamNe pas lancer fuse quand le nombre de samples est trop important ?Discussion cet après-midi, suite aux problèmes de place sur /mnt/result : Mathieu propose de ne pas lancer fuse lorsque le nombre de samples est supérieur à un nombre (p. ex. 20). Cela permet d'économiser de la place (et du temps CPU : u...Discussion cet après-midi, suite aux problèmes de place sur /mnt/result : Mathieu propose de ne pas lancer fuse lorsque le nombre de samples est supérieur à un nombre (p. ex. 20). Cela permet d'économiser de la place (et du temps CPU : un fuse sur 100 fichiers prend du temps).
De plus le fuse est lancé autant de fois qu'il appartient à de sample sets (donc au moins 2, non ?).
***
753e78c : On ne garde que les 16 premiers. C'est peut-être un peu brutal de faire cela au niveau de fuse.py, mais bon, cela renvoie tout de même un .vidjil pour une visualisation sur les premiers échantillons.
***
Ça me paraît un peu rapide. On n'a pas vraiment de solution pour « degrade gracefully ».
Garde les 16 premiers : est-ce que ça veut dire qu'on va fusionner toujours les mêmes sur le serveur s'il y a plus de 16 fichiers ? Comment on fait pour avoir les autres ? Le custom fuse ne permet pas de sauvegarder les analyses.
Côté serveur il faudrait avertir les utilisateurs qu'ils ne verront que 16 fichiers.
Il y a des utilisateurs avec plus de 16 fichiers, et ça peut faire sens : http://rbx.vidjil.org/browser/index.html?patient=790&config=25
Le problème est surtout avec les runs ou avec Kiel qui met plein d'échantillons différents dans un même patient. Les clones n'ont rien à voir d'un échantillon à l'autre et donc on se retrouve avec des dizaines de milliers de clones dans le fichier. Une autre solution peut être de réduire le top lorsque le nombre de fichier augmente.
***
D'autant plus que l'utilisateur qui nous pause problème à ce sujet n'utilise pas le fuse automatique mais plutôt le custom_fuse, non ? Ne pourrait-ton pas simplement avoir des configs qui fusent et d'autres non ?
***
Oui, effectivement ça serait une solution simple de proposer à Kiel une config sans fuse (on sait faire ça ?).
***
Je pense qu'il y a un bout de code à changer pour que le run accepte de ne pas fuse, mais oui je pense que c'est possible.
***
Oui, le coup de la config en plus, pourquoi pas !
Ou même... la config par défaut pourrit faire 16 fichiers au plus, et on a une config spéciale si quelques gens veulent avoir beaucoup de points.
> « degrade gracefully ».
> Garde les 16 premiers : est-ce que ça veut dire qu'on va fusionner toujours les mêmes sur le serveur s'il y a plus de 16 fichiers
C'est une bonne question. Mais que cela soit oui ou non, c'est un "degrade gracefully" si on montre 16 points... et si on dit qu'on a une autre config si vraiment on veut avoir d'autre chose.
Enfin, quitte à avoir une autre config, on pourrait aussi régler plus finement les paramètres du fuse (top et autres).
***
Ça me semble plus simple de demander à Kiel d'utiliser une config sans fuse, plutôt que de mettre en place le nécessaire pour avertir les utilisateurs que quand il y a plus de X fichiers ils ne verront pas tous les résultats et qu'ils doivent lancer avec une autre config (en espérant qu'il y ait une config correspondante avec un fuse infini).
Autre exemple, si j'uploade 20 fichiers dans mon run (ce qui n'est pas délirant), j'ai envie de savoir si j'ai de la conta entre mes 20 fichiers pas entre 16 fichiers plus ou moins choisis aléatoirement (dont l'ordre dépendra de l'upload).
En fait plus j'y réfléchis, plus j'ai l'impression qu'un top qui diminue progressivement avec le nombre de fichiers fournit une solution plus satisfaisante (et même pas besoin de demander à Kiel d'utiliser une autre config, on peut mais ça n'est pas indispensable).
***
> plutôt que de mettre en place le nécessaire pour avertir les utilisateurs
Je ne suis pas d'accord sur ce point, c'est très simple avec les notifications. Cela permet d'avoir, par défaut, un comportement correct pour la majorité des utilisateurs, et de les inciter à utiliser correctement les patients. (Et s'ils leur manquent quelque chose, c'est facile de rajouter une config pour un user, pour des bonnes raisons). Je préfère être sûr, dès maintenant, que tous les utilisateurs font ce qu'il faut (et traiter au cas par cas quelques cas comme Kiel) plutôt que de retomber dans quelques mois sur un autre utilisateur qui fera pareil.
> Autre exemple, si j'uploade 20 fichiers dans mon run (ce qui n'est pas délirant)
Oui, tout à fait ! 16 est un exemple, cela peut être 32 ou 42 :-) Dans tous les cas, au-delà de 8-10 simples, on devrait cacher sur le graphe (cf une autre tâche). Et encore plus si on fait des SampleSets : peut-être que quelqu'un aura un SampleSet de 100/200 patients correspondant à un truc particulier... (Mais lance-t-on les mêmes configs dans tous les SampleSet ? Ce n'est pas obligé.)
> En fait plus j'y réfléchis, plus j'ai l'impression qu'un top qui diminue progressivement avec le nombre de fichiers fournit une solution plus satisfaisante
Oui, c'est aussi possible, par exemple (1000 / #samples)... mais on a déjà du mal à expliquer ce qu'est notre top, alors là cela va être encore plus dur. Ou alors, 1000 tant que #samples < 8, puis ensuite cela descend.
***
Par défaut, met-on le -f dans fuse.py à 0 et on fait une config pour Kiel où le -f est à 1 (ou X) ?
***
Kiel vient d'ajouter une centaine de fichiers → –10 Go
***
@magiraud @RyanHerb @mikael-sWeb 2017.05Mikaël SalsonMikaël Salsonhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2009CSS/JS manquant pour l'admin de dev.vidjil.org2016-11-29T14:43:10+01:00Vidjil TeamCSS/JS manquant pour l'admin de dev.vidjil.orgL'interface d'admin Web2py ne trouve pas ses CSS et JS : https://dev.vidjil.org/admin/default/site
Est-ce lié au HTTPS ? Si c'est spécifique à rbx (la machine), pas de souci. On va passer dev sur vda de toute façon.
***
Oui c'est le pass...L'interface d'admin Web2py ne trouve pas ses CSS et JS : https://dev.vidjil.org/admin/default/site
Est-ce lié au HTTPS ? Si c'est spécifique à rbx (la machine), pas de souci. On va passer dev sur vda de toute façon.
***
Oui c'est le passage au https qui a cassé le css de l'interface admin
***
Et c'est réparé
***
Merci :)
Pour l'historique, quel était le problème ?
***
la règle 'static' de http que j'ai migrée en https. En fait les css de admin passaient déjà en https et le nouveau routage introduisait une erreur
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2008Redirection de / vers /browser en HTTPS2016-11-29T14:43:09+01:00Vidjil TeamRedirection de / vers /browser en HTTPSEn allant sur https://dev.vidjil.org je ne suis pas redirigé vers le /browser, il faut le rentrer à la main dans l'URL.
***
@RyanHerbEn allant sur https://dev.vidjil.org je ne suis pas redirigé vers le /browser, il faut le rentrer à la main dans l'URL.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2007Empêcher l'upload ou de lancer des jobs lorsqu'il ne reste plus assez d'espac...2020-01-08T17:39:47+01:00Vidjil TeamEmpêcher l'upload ou de lancer des jobs lorsqu'il ne reste plus assez d'espace disqueOn sait où les séquences et les résultats sont stockés. Si on passe en dessous d'un seuil d'espace libre pour un de ces emplacements, il faut empêcher l'upload ou le run (c-à-d. avoir un test en plus dans VidjilAuth ?). De cette façon on...On sait où les séquences et les résultats sont stockés. Si on passe en dessous d'un seuil d'espace libre pour un de ces emplacements, il faut empêcher l'upload ou le run (c-à-d. avoir un test en plus dans VidjilAuth ?). De cette façon on ne se retrouve jamais avec un disque plein et pas avec des jobs en failed parce qu'il n'y a plus d'espace disque.
Par contre, prévoir de spammer les admins dès que la limite est atteinte pour qu'ils fassent quelque chose (en générant un ticket web2py ?)
***
C'est en prod. On a une limite en pourcentage qui se fixe dans defs.py. Actuellement réglé sur 1%. La limite est commune pour toutes les partitions mais la vérification est spécifique (donc il peut s'avérer que l'upload soit bloqué, mais pas les runs
***
Merci Ryan.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2000Lorsque le run est mal renseigné, ne pas permettre la soumission du formulaire2017-07-05T09:15:55+02:00Vidjil TeamLorsque le run est mal renseigné, ne pas permettre la soumission du formulaireLors de l'ajout d'un fichier, si on ajoute un run qui n'existe pas, il est coloré en rouge mais on peut soumettre le formulaire, ce qui génère ensuite une boite de dialogue disant : « [object Object] error INTERNAL SERVER ERROR », ce qui...Lors de l'ajout d'un fichier, si on ajoute un run qui n'existe pas, il est coloré en rouge mais on peut soumettre le formulaire, ce qui génère ensuite une boite de dialogue disant : « [object Object] error INTERNAL SERVER ERROR », ce qui n'est pas très parlant.
J'imagine que du côté client il y a moyen de contrôler que les champs run et patient sont remplis avec des données correctes.
***
Hotfix prête, déployée sur dev.
Pas encore poussée sur prod-server
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1986Affichage des logs du serveur web2023-06-28T16:37:56+02:00Vidjil TeamAffichage des logs du serveur webDans le panneau d'admin, les logs serveurs peuvent être affichés et c'est le fichier « ../log/nginx/access.log » qui est affiché (ou error.log pour les erreurs). Ce n'est pas très générique puisque cela dépend de l'emplacement des logs V...Dans le panneau d'admin, les logs serveurs peuvent être affichés et c'est le fichier « ../log/nginx/access.log » qui est affiché (ou error.log pour les erreurs). Ce n'est pas très générique puisque cela dépend de l'emplacement des logs Vidjil, des logs du serveur web, du serveur web lui-même et des droits affectés au fichier.
Au passage j'aurais bien ajouté une vérification dans showlog pour que showlog ne montre que les logs de Vidjil (et donc empêche de se balader où on veut dans l'arborescence).
Bref je retirerais bien ces deux liens.
***
@magiraud @RyanHerb @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1970mauvaise récupération des métadonnées sur Demo L42016-11-29T14:42:44+01:00Vidjil Teammauvaise récupération des métadonnées sur Demo L4En faisant la release 2016.08, j'ai testé sur Demo L4 et X5 (cf vdj/doc/vidjil/release.org).
Apparament cela a bien fonctionné (vu les logs, vu les compare patients)...
Mais le lien pour L4, http://rbx.vidjil.org/browser/index.html?pat...En faisant la release 2016.08, j'ai testé sur Demo L4 et X5 (cf vdj/doc/vidjil/release.org).
Apparament cela a bien fonctionné (vu les logs, vu les compare patients)...
Mais le lien pour L4, http://rbx.vidjil.org/browser/index.html?patient=146&config=26 indique, dans son 'info', MiXCR ! De la même manière, celui pour X5 indique un mauvais numéro de version. Est-ce juste l'analysis qui n'est pas le bon ?
***
Peut-être est-ce la même chose que "Lorsque une partie des fichiers est runné, des métadata des mauvais fichiers sont affichés" ?
***
Pour L4, je confirme que c'est juste un problème d'affichage de l'info : les résultats sont corrects et ont bien été obtenus avec Vidjil.
***
Oui, c'est une relique de l'analysis, comme on avait avec le champ log.
J'ai mis en place une hotfix, comme pour le champ log => 09e65aff7f32d79e53 + 7137057aa9030f8a9a00c
La solution est "hacky" mais si on devait faire proprement, ça prendrais beaucoup de temps... On peut en discuter si vous voulez :)
***
Est-ce toujours d'actualité ? La hotfix a été intégrée ?
***
Oui elle est intégrée :)
***
@magiraud @RyanHerb @mikael-s @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1962Erreur la page des logs lorsque connecté en tant que Aurélie2016-11-29T14:42:38+01:00Vidjil TeamErreur la page des logs lorsque connecté en tant que AurélieSe connecter en tant qu'Aurélie, aller sur la page, choisir la table patient… erreur serveur.
***
C'est bon.
***
@RyanHerb @DuezSe connecter en tant qu'Aurélie, aller sur la page, choisir la table patient… erreur serveur.
***
C'est bon.
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1960Relancer un pre-process qui a échoué2017-05-19T14:23:37+02:00Vidjil TeamRelancer un pre-process qui a échouéDans le cas où un pre-process échoue on ne ne peut pas le relancer (alors qu'on peut le faire pour un Vidjil). Pourtant les fichiers sont encore sur le disque et il est donc encore possible de le relancer, il manque juste le bouton en qu...Dans le cas où un pre-process échoue on ne ne peut pas le relancer (alors qu'on peut le faire pour un Vidjil). Pourtant les fichiers sont encore sur le disque et il est donc encore possible de le relancer, il manque juste le bouton en quelque sorte.
***
@DuezRyan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1950Trouver une autre méthode de scheduling, indépendante de web2py2022-06-20T11:59:42+02:00Vidjil TeamTrouver une autre méthode de scheduling, indépendante de web2py(Discuté lors de la Rando 2016)
Un scheduler idéal devrait pouvoir avoir :
1) des priorités fines (petits jobs passent devant gros jobs) (et aussi users Platinium :-)
2) une suspension de tâches
3) une assignation fine de certains (gr...(Discuté lors de la Rando 2016)
Un scheduler idéal devrait pouvoir avoir :
1) des priorités fines (petits jobs passent devant gros jobs) (et aussi users Platinium :-)
2) une suspension de tâches
3) une assignation fine de certains (groupes de) workers à certaines tâches
2) ou 3) permettrait de lancer des choses annexes et rapides (type FineSegmenter ou compare patients ou ...) même si des gros Vidjil (ou autres) tournent
Enfin, penser tout cela dans le cadre d'un "noeud de calcul", possiblement indépendant du serveur web. Le serveur de calcul ne reçoit que des lignes de commande à exécuter et à accès aux fichiers nécessaires par un montage.
Rien d'urgent, à réfléchir posément dans les prochains mois.
***
Task spooler: http://vicerveza.homeunix.net/~viric/soft/ts/ présente les fonctionnalités majeures que nous cherchons (tâches interdépendantes, changement d'ordre dans la file, etc), mais n'a pas d'API pour s'en servir en réseau.
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1948Base de données remplie avec des scheduler_task et scheduler_run2017-07-05T09:15:55+02:00Vidjil TeamBase de données remplie avec des scheduler_task et scheduler_runIl y a une semaine, le 17 juin, il y avait environ 8 000 scheduler_task dans la BD. Aujourd'hui (24/06) il y en a environ 93 000. À raison d'environ 90 000 par semaine la BD risque de s'alourdir rapidement.
À quoi est-ce dû ?
***
Un cert...Il y a une semaine, le 17 juin, il y avait environ 8 000 scheduler_task dans la BD. Aujourd'hui (24/06) il y en a environ 93 000. À raison d'environ 90 000 par semaine la BD risque de s'alourdir rapidement.
À quoi est-ce dû ?
***
Un certain nombre de pre_process... J'imagine que cela vient des pre_process reprogrammés par task.py ?
Au passage, veut-on tout garder les scheduler_task et scheduler_run ? Effacer, au moins pour les pre_process / ou bien au moins pour les vieux trucs ? (on veut les log)
***
Non pas du tout. Ce sont des vidjil. Pour les id > 10000, il y a 82000 vidjil ((db.scheduler_task.id>10000) & (db.scheduler_task.task_name =='vidjil'))
Cela semble etre des vidjil relancés car en attente de la fin du pre-process.
***
ok. Il faudrait donc supprimer ces tâches "vidjil" dans la db, pour qu'il n'y ait que la dernière qui soit enregistrée.
task.py:161, est-ce qu'on pourrait mettre autre chose qu'un "return SUCCESS" et supprimer ces tâches ?
Ou bien utiliser "repeats" + "period" lors du queue_task, et de ne pas relancer de tâche (mais mettre à jour le "repeats" à la bonne valeur quand le vidjil est finalement lancé) ? Ou bien quelque chose avec "retry_failed"
***
Aïe, avec un "repeats", cela créerait quand même plein d'objets scheduler_run...
***
Ça continue encore (probablement les 24 QUEUED qui sont là depuis le problème de Myriam). On a environ 1600 entrées par jour dans scheduler_run qui annoncent « still pending ».
***
J'ai supprimé les runs et les task associés. J'ai backup la bdd avant de faire quoi que ce soit, donc si j'ai fait des bétises on peut revert.
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1946Erreurs serveurs dans les runs2016-11-29T14:42:27+01:00Vidjil TeamErreurs serveurs dans les runsLorsque, sur la page de la liste des runs, on clique sur le nom d'une config pour ouvrir un résultat → erreur serveur
***
Lorsqu'on clique sur un « completed » pour voir le log de Vidjil → erreur serveur
***
Confirmé. Maintenant que les ...Lorsque, sur la page de la liste des runs, on clique sur le nom d'une config pour ouvrir un résultat → erreur serveur
***
Lorsqu'on clique sur un « completed » pour voir le log de Vidjil → erreur serveur
***
Confirmé. Maintenant que les runs sont en prod, cela va vite se voir :-)
***
hotfix poussée: 32d560d2ba3df03876a et b16d5e1be7865bd
J'ai pull sur dev; et fait un petit test: Le pull n'a pas encore été fait sur prod-server (mais le merge, oui)
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1940Lorsque une partie des fichiers est runné, des métadata des mauvais fichiers ...2016-11-29T14:42:23+01:00Vidjil TeamLorsque une partie des fichiers est runné, des métadata des mauvais fichiers sont affichésJ'ai lancé le 2è et le 3è fichier (R2 et fichier mergé) mais les infos affichées (commentaires sur le fichier plus nom des fichiers) sont celles de R1 et R2 : http://rbx.vidjil.org/browser/index.html?sample_set_id=7859&config=34
En reva...J'ai lancé le 2è et le 3è fichier (R2 et fichier mergé) mais les infos affichées (commentaires sur le fichier plus nom des fichiers) sont celles de R1 et R2 : http://rbx.vidjil.org/browser/index.html?sample_set_id=7859&config=34
En revanche les résultats sont bien ceux de R2 et du fichier mergé. C'est donc un problème postérieur au lancement de Vidjil (fuse ou récupération des infos).
***
Ryan, Martin ne t'avait pas parlé d'un bug de ce genre ?
Confirmé par Jona. Ce sont les métadonnées des premiers fichiers qui sont affichés, alors que ce sont les derniers fichiers qui ont été analysés :
http://rbx.vidjil.org/browser/index.html?sample_set_id=3447&config=30
***
Si ! Et Marc l'a corrigé, mais on dirait que ce n'est pas encore dans prod-server.
***
C'est bon, merci.
***
@mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1931Pre-process is still pending, re-schedule2017-07-05T09:15:55+02:00Vidjil TeamPre-process is still pending, re-scheduleToute la nuit, un (des ?) pre-process ont été re-schédulés : cf. la table db.scheduler_run de dev.vidjil.org (https://dev.vidjil.org/vidjil/appadmin/select/db). Donc ça a l'air de tourner en boucle. Ça me semble bloquant avant de mettre ...Toute la nuit, un (des ?) pre-process ont été re-schédulés : cf. la table db.scheduler_run de dev.vidjil.org (https://dev.vidjil.org/vidjil/appadmin/select/db). Donc ça a l'air de tourner en boucle. Ça me semble bloquant avant de mettre cela en prod.
***
Mikaël, tu confirmes qu'il n'y a plus de problème ?
***
apparemment
***
soyons généreux alors, fermons les tâches :-)
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1930Tout ce qui est dans task.py devrait être lancé par un autre utilisateur2022-06-20T18:11:04+02:00Vidjil TeamTout ce qui est dans task.py devrait être lancé par un autre utilisateurDiscussion à l'instant: dans task.py, il peut y avoir des choses méchantes de faites, que ce soit via les configs ou les pre-process.
On pourrait échapper des choses, faire un chroot...
Le plus simple semble de faire tous les lancements...Discussion à l'instant: dans task.py, il peut y avoir des choses méchantes de faites, que ce soit via les configs ou les pre-process.
On pourrait échapper des choses, faire un chroot...
Le plus simple semble de faire tous les lancements par un *autre utilisateur*, qui n'aurait des droits en écriture que sur tmp/. Cela devrait passer tout seul pour vidjil / mixcr (le fichier de résultat étant copié), à voir pour les pre-process.
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1928MiXCR : supprimer les fichiers align.vdjca2016-11-29T14:42:15+01:00Vidjil TeamMiXCR : supprimer les fichiers align.vdjcaAprès avoir lancé MiXCR il faut supprimer les fichiers align.vdjca qui prennent (beaucoup) trop de place.
***
d730289, au doigt mouillé.
***
@RyanHerbAprès avoir lancé MiXCR il faut supprimer les fichiers align.vdjca qui prennent (beaucoup) trop de place.
***
d730289, au doigt mouillé.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1927Sécurité : tout le monde aurait le droit de changer les configs ?2017-01-31T17:37:21+01:00Vidjil TeamSécurité : tout le monde aurait le droit de changer les configs ?En répondant à Shugay, je voulais lui dire de faire un db.call('index/configs') juste pour voir les configs... et, en essayant de mon côté en étant impersonated sur son compte, je me suis rendu compte que je peux *éditer* les configs (al...En répondant à Shugay, je voulais lui dire de faire un db.call('index/configs') juste pour voir les configs... et, en essayant de mon côté en étant impersonated sur son compte, je me suis rendu compte que je peux *éditer* les configs (alors que le droit n'est que de "read" normalement).
***
Ca va meme plus loin, en creusant un peu, je m'apperçois que lancer un db.call avec les bons parametres dans la console affiche la page meme si on n'est pas connecté.
ex: db.call('sample_set/index', {'id' :'62' , 'config_id' : 5 } )
De là, je peux même télécharger le fichier results.
***
J'ai rajouté des vérifications avec la méthode existante dans auth: can_modify_config et j'ai caché les boutons pour les personnes non-admin.
***
Rando 2016: ok pour Ryan. merci !
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1920Retour à l'utilisateur lorsque la requête prend un peu de temps2017-11-24T11:05:20+01:00Vidjil TeamRetour à l'utilisateur lorsque la requête prend un peu de tempsÀ partir de quelques dixièmes de seconde, afficher « Loading » en haut de la page, puis au bout de une seconde « Still loading » avec un fond un peu plus voyant. Cela ne changera rien aux timeouts, mais cela devrait éviter que les utilis...À partir de quelques dixièmes de seconde, afficher « Loading » en haut de la page, puis au bout de une seconde « Still loading » avec un fond un peu plus voyant. Cela ne changera rien aux timeouts, mais cela devrait éviter que les utilisateurs appuient de nombreuses fois sur le bouton (en pensant que la requête n'a pas été prise en compte), surchargeant encore plus le serveur.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1919Multi-threader web2py2017-03-22T17:36:24+01:00Vidjil TeamMulti-threader web2pyApparemment web2py par défaut devrait être multi-threadé, voir pourquoi il ne l'est pas. Cela pourrait résoudre pas mal de timeouts.
***
Tiens, on apprend des choses au redémarrage de web2py :
*** Python threads support is disabled. You...Apparemment web2py par défaut devrait être multi-threadé, voir pourquoi il ne l'est pas. Cela pourrait résoudre pas mal de timeouts.
***
Tiens, on apprend des choses au redémarrage de web2py :
*** Python threads support is disabled. You can enable it with --enable-threads ***
***
Après vérification, nous avons 4 processus web2py qui tournent. D'après ce post: https://groups.google.com/forum/#!topic/web2py/mPdn1ClxLTI c'est tout à fait ce qu'il faut avoir.
Les requêtes sont encore bloquantes.
Activer le flag enable-threads n'a rien changé sur mon environnement.
***
@RyanHerbWeb 2017.03https://gitlab.inria.fr/vidjil/vidjil/-/issues/1912Browser help : 4042016-11-29T14:42:04+01:00Vidjil TeamBrowser help : 404http://rbx.vidjil.org/browser/help
***
Disparu à cause de la scission entre prod-server et prod-browser
***
@magiraud @mikael-shttp://rbx.vidjil.org/browser/help
***
Disparu à cause de la scission entre prod-server et prod-browser
***
@magiraud @mikael-s