Etherpad-lite: Les attributs appliqués peuvent entraîner une application non concordante. Nécessite une couverture de test de charge pour être répliquée.

Créé le 22 mai 2020 · 9Commentaires · Source: ether/etherpad-lite

Ce premier commentaire semble hors de propos.

C'est un peu un cas limite mais cela peut arriver. Cela ne se produit que sur des pads très actifs (pensez à 10 secondes de modifications par seconde).

A reproduire.

Activer loadTesting .
Exécuter le test de charge
Copiez/collez le padId dans le navigateur.

Ce qui se produit

Le tampon ne se charge pas

Que devrait-il se passer

Le tampon devrait se charger.

Plus d'informations sur le débogage

Le pad se chargera avec succès et pourra être modifié une fois le test de charge terminé
Si vous êtes déjà sur le pad, aucune erreur ne vient et cela fonctionne très bien.

L'erreur est

Error: Failed assertion: mismatched apply: 10984 / 11740

Hypothèse

Mon hypothèse est qu'entre le moment où nous livrons l'objet pad , y compris la baseRev #, il y a eu un changement supplémentaire, ce qui signifie que le prochain changement échoue, provoquant une application incompatible.

Considérez ce scénario..

Rev # | 
1    | <-- we connect here
2    | <-- has been an edit here.
3    | <-- is the first commit we receive from the server

La logique est la suivante :

exports.applyToText = function (cs, str) {
  var unpacked = exports.unpack(cs);
  exports.assert(str.length == unpacked.oldLen, "mismatched apply: ", str.length, " / ", unpacked.oldLen);

Je pense que la solution est qu'Etherpad peut "demander" une révision précédente lors de la réception d'une révision "dans le futur" et l'appliquer avant la dernière révision. Essentiellement après avoir reçu 3 et sachant que c'est à 1 il demande également [2] et applique [2] avant 3 ?

J'ai essayé de créer ce même problème sur le etherpad-cli-client avec etherpad-load-test et je ne peux pas. Les messages semblent toujours se charger dans l'ordre. L'étape suivante consiste à simuler un délai entre CLIENT_VARS et NEW_CHANGES et voir ce qui se passe.

Minor Bug

Source

JohnMcLear

Commentaire le plus utile

A noté @yorickreum. Mais si je peux résoudre ce problème, il est probable/possible que cela résoudra votre problème. L'application incompatible est essentiellement une condition de concurrence à laquelle je dois remédier et ce correctif de bogue couvrira, espérons-le, toutes les éventualités de cette condition de concurrence, quelle qu'en soit la cause.

JohnMcLear le 17 juil. 2020

👍2

Tous les 9 commentaires

Fait intéressant, en utilisant le client CLI, cela ne se produit jamais. Il doit donc s'agir d'un problème de client Web.

Ligne 283 de collab_client.js

    if (msg.type == "NEW_CHANGES")

C'est de là que l'erreur semble provenir..

Il semble que le nombre de révisions ne soit pas bien géré.

JohnMcLear le 28 mai 2020

Salut Jean, c'est vrai !
J'ai exécuté le loadTest sur le serveur de test : node app.js http://127.0.0.1 :9001/p/load -d 180 -l 100 -a 500
et aussi sur le Productif : node app.js http://127.0.0.1 :9001/p/load -l 50 -a 12
il n'y avait pas de problèmes.

Un utilisateur m'a confirmé, si vous êtes déjà dans le pad, vous n'avez aucun problème. Le problème se produit avec nous de 10 à 15 utilisateurs.

sus16cn le 17 juil. 2020

180 / 500 sont des nombres irréalistes à mon humble avis ! 500 auteurs faisant chacun 1 édition par seconde vont casser Internet ️

JohnMcLear le 17 juil. 2020

Salut @JohnMcLear , bien sûr. Mais je peux l'affirmer, les installations Etherpad y ont résisté ! Impressionnant. Cependant, cela signifie également que tout ce qui plante exactement notre instance (voir le problème fermé https://github.com/ether/etherpad-lite/issues/4090) ne dépend probablement pas vraiment de l'activité dans le pad, ce qui signifie probablement qu'il est encore un autre problème.

yorickreum le 17 juil. 2020

JohnMcLear le 17 juil. 2020

👍2

Intéressant. mismatched apply ne s'applique qu'à l'application d'un ensemble de modifications à une chaîne, pas à un "ajout" de contenu de pad qui est la seule chose que fait l'outil loadTest.

Je dois faire en sorte que l'outil loadTest simule également l'application d'un ensemble de modifications à une chaîne.

JohnMcLear le 18 juil. 2020

Juste une mise à jour à ce sujet au cas où les choses deviendraient périmées.

Je ne me souviens pas de la logique pour appliquer un attribut à une sélection en utilisant uniquement changeset.js sans le gestionnaire d'attributs de document, j'ai donc demandé de l'aide.

C'est quelque chose que quelqu'un de plus récemment familier pourra aider. Une fois que j'aurai cette logique, je l'inclurai dans les tests de charge et j'espère pouvoir simuler le bogue.

S'il n'y a pas d'autres mises à jour de ma part à ce sujet, c'est parce que j'ai manqué de temps.

JohnMcLear le 18 juil. 2020

Juste une courte mise à jour/rapport :

Hier, le problème s'est à nouveau produit pour moi dans un pad avec seulement 2 utilisateurs donc je ne semble pas dépendre du nombre d'utilisateurs comme @yorickreum l'a déjà écrit (voir https://github.com/ether/etherpad-lite/issues /4090). Le problème est survenu au bout de 2 minutes et a duré 1 minute avant de fermer l'onglet et de rouvrir le bloc-notes dans un nouvel onglet, ce qui a finalement résolu le problème pour l'heure suivante. J'utilise Firefox 78.0.2.

Oremountainflorian le 22 juil. 2020

@Oremountainflorian Je serais tenté de suggérer des tests sans plugins pour voir si cela continue.

Dans la minute qui a suivi la persistance de l'erreur, avez-vous tenté d'actualiser votre navigateur ? Les ensembles de modifications ne sont pas stockés de manière persistante, il n'est donc pas logique qu'une actualisation d'une faible activité n'ait pas été corrigée. Je sens qu'un putain de plugin pourrait être en cours

JohnMcLear le 22 juil. 2020

Cette page vous a été utile?

0 / 5 - 0 notes