Etherpad-lite: Примененные атрибуты могут привести к несоответствию применения. Для репликации требуется покрытие нагрузочным тестом.

Созданный на 22 мая 2020 · 9Комментарии · Источник: ether/etherpad-lite

Этот первоначальный комментарий кажется неуместным.

Это немного крайний случай, но это может случиться. Это происходит только на очень активных пэдах (подумайте, 10 секунд правок в секунду).

Тиражировать.

Включите loadTesting .
Запустить loadTesting
Скопируйте / вставьте padId в браузер.

Что происходит

Pad не загружается

Что должно произойти

Pad должен загрузиться.

Дополнительная информация об отладке

Пэд успешно загрузится, и его можно будет редактировать после завершения нагрузочного тестирования.
Если вы уже находитесь на планшете, никаких ошибок не возникает, и он отлично работает.

Ошибка

Error: Failed assertion: mismatched apply: 10984 / 11740

Предположение

Я предполагаю, что в период между доставкой объекта pad включая baseRev #, произошло дополнительное изменение, означающее, что следующее изменение не работает, вызывая несоответствие.

Рассмотрим этот сценарий ..

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

Логика такая:

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

Я думаю, что решение заключается в том, что Etherpad может «запросить» предыдущую ревизию после получения ревизии, которая «в будущем», и применить ее до последней ревизии. По сути, получив 3 и зная, что он находится в 1 он также запрашивает [2] и применяет [2] перед 3 ?

Я попытался создать ту же проблему на etherpad-cli-client с помощью etherpad-load-test и не смог. Сообщения всегда загружаются по порядку. Следующий шаг - смоделировать задержку между CLIENT_VARS и NEW_CHANGES и посмотреть, что произойдет.

Minor Bug

Источник

JohnMcLear

Самый полезный комментарий

Отметил @yorickreum. Но если я смогу исправить эту проблему, вероятно / возможно, это решит вашу проблему. Несоответствующее применение - это, по сути, состояние гонки, которое мне нужно исправить, и это исправление ошибок, надеюсь, покроет все возможные случаи возникновения этого состояния гонки, независимо от причины.

JohnMcLear 17 июл. 2020

👍2

Все 9 Комментарий

Интересно, что при использовании клиента CLI этого никогда не происходит. Так что это проблема веб-клиента.

Строка 283 из collab_client.js

    if (msg.type == "NEW_CHANGES")

Вот откуда, похоже, возникает ошибка ..

Похоже, подсчет исправлений ведется не очень хорошо.

JohnMcLear 28 мая 2020

Привет, Джон, верно!
Я запустил loadTest на тестовом сервере: node app.js http://127.0.0.1 : 9001 / p / load -d 180 -l 100 -a 500
а также в продуктивном: node app.js http://127.0.0.1 : 9001 / p / load -l 50 -a 12
Проблем не было.

Пользователь подтвердил мне, что если вы уже находитесь в планшете, у вас нет проблем. Проблема возникает у нас от 10 до 15 пользователей.

sus16cn 17 июл. 2020

180/500 - это нереальные числа имхо! 500 авторов, каждый из которых делает 1 правку в секунду, взорвут Интернет 🖌️

JohnMcLear 17 июл. 2020

Привет, @JohnMcLear , конечно. Но я могу утверждать, что установки Etherpad выдержали это! Впечатляет. Однако это также означает, что все, что именно приводит к сбою нашего экземпляра (см. Закрытую проблему https://github.com/ether/etherpad-lite/issues/4090), вероятно, на самом деле не зависит от активности в панели, что, вероятно, означает, что это это еще одна проблема.

yorickreum 17 июл. 2020

JohnMcLear 17 июл. 2020

👍2

Интересно. mismatched apply применимо только к применению набора изменений к строке, а не к «добавлению» содержимого панели, что является единственной вещью, которую выполняет инструмент loadTest.

Мне нужно сделать так, чтобы инструмент loadTest также имитировал применение набора изменений к строке.

JohnMcLear 18 июл. 2020

Просто обновите это на случай, если что-то устареет.

Я не могу вспомнить логику применения атрибута к выделению с использованием только файла changeset.js без диспетчера атрибутов документа, поэтому я попросил помощи.

Это то, с чем сможет помочь кто-то из недавних знакомых. Когда у меня будет эта логика, я включу ее в нагрузочные тесты и, надеюсь, смогу смоделировать ошибку.

Если от меня больше нет обновлений по этому поводу, это потому, что у меня не хватило времени.

JohnMcLear 18 июл. 2020

Просто краткое обновление / отчет:

Вчера проблема снова возникла для меня в планшете только с двумя пользователями, поэтому я, похоже, не зависим от количества пользователей, как уже писал @yorickreum (см. Https://github.com/ether/etherpad-lite/issues / 4090). Проблема возникла через 2 минуты и длилась 1 минуту, прежде чем я закрыл вкладку и снова открыл панель в новой вкладке, что в конечном итоге решило проблему на следующий час. Я использую Firefox 78.0.2.

Oremountainflorian 22 июл. 2020

@Oremountainflorian Я бы хотел предложить тестирование без плагинов, чтобы увидеть, продолжится ли оно.

Вы пытались обновить страницу в браузере в течение 1 минуты с момента появления ошибки? Наборы изменений не хранятся постоянно, поэтому не имеет смысла, что обновление низкой активности не исправило. Я чувствую, что может быть какая-то гребешок с плагинами

JohnMcLear 22 июл. 2020

Была ли эта страница полезной?

0 / 5 - 0 рейтинги