Bonjour
Il m’est arrivé plusieurs fois (sans savoir ni pourquoi ni comment) que l’interface scénari se bloque.
Je m’explique : l’item en cours se verrouille sans que je ne puisse plus le modifier.
Alors l’interface se modifie légèrement. j’ai fait une capture d’écran - Mon nom apparaît (alors que normalement non).
Et j’ai parfois beaucoup de mal à revenir à un fonctionnement normal… je sors, je reviens, je redémarre le PC, le navigateur … parfois j’en suis réduit à faire une copie de l’item…
Merci pour ce retour d’informations. Pourriez-vous décrire la configuration de votre réseau et comment est hébergé votre serveur ? Avez-vous déjà vu passer un message en haut de votre écran de ce type :
Il s’agit probablement d’une instabilité réseau qui provoque cette anomalie. Idéalement, il faudrait que nous parvenions à reproduire cette anomalie réseau pour mieux la comprendre et trouver le contournement adéquat.
bonjour
Le problème s’est produit sur mon compte scenari (nabfab) ainsi que sur le serveur scenari de l’Université de Lille
J’ai effectivement vu le message d’instabilité mais plus souvent que le verrouillage … mais peut-être effectivement le réseau a du mal à maitenir mon identification sur l’entrepôt et donc me verrouille à un moment …
merci pour votre aide (super réactive !)
fabien
Salut Sylvain,
Je découvre le ticket. Le serveur sur lequel Fabien se connecte est celui sur lequel on a installé le package SCServer/Dépot que vous nous avez configuré l’année dernier. LA VM est un quad core / 10Go de Ram, disques SSD et connexion 10Gb/s. De mon coté pas de souci de cette nature.
Est-ce qu’à ton avis il y a une chance de trouver une info dans un fichier de log ?
Merci pour les infos. Je creuse…
Je pense que ce sont des équipements réseaux intermédiaires qui interrompent la connexion WebSocket, mais, les « endPoints », à savoir le client et surtout le serveur n’en sont pas informés, et c’est là que le problème se pose : le serveur pense que la connexion est toujours opérationnelle et maintient par conséquent le verrou. Les logs ne devraient donc pas aider. Dans nos tests et nos hébergements en production, nous ne rencontrons pas ces problèmes car nous n’avons pas ce genre d’équipements réseaux intermédiaires. Un client nous a remonté un problème équivalent, dans une situation un peu différente, mais ca confirme le diagnostique. Il existe un mécanisme « heartbeat » avec des messages « ping/pong » dans le protocole WebSocket, mais il semble que le serveur Jetty ne l’exploite pas directement. Nous allons devoir l’implémenter nous même. A suivre…
