Да, все объекты в единственном числе. Пример показывает вложенность переменных, содержащих на них адреса. Объекты 4 и 5 работают в разных потоках. Мьютекс обеспечивает экран для объектов 1 и 3, но те в свою очередь обращаются к неэкранированному общему объекту 2. Понимаю, что логичным реением может показаться обернуть второй объект мьютексами, но я предполагаю, что такие ошибки могут возникнуть при большей вложенности. Или я ошибаюсь и при грамотной архитектуре такого возникнуть не может? На что нужно обращать внимание, чтобы грамотно выстраивать архитектуру приложения?
nezzard: да, я забыл присваивать результат, кажется это важно:
promise = promise.then( (results) => {
Если не поможет, попробуйте эмулировать возвращаемые данные из массива, чтобы понять, что проблема именно в нашем коде, а не на сервере. Если окажется в коде, буду разбираться. Прошу в любом случае отписаться - самому стало интересно.
nezzard: есть вариант с Promise.all - он передаёт массив результатов. Но он обрабатывает запросы не последовательно, а параллельно. Если такой вариант не подходит, проще создать массив на верхнем уровне, который замыкается на колбэке промиса и в который добавляются результаты.
Антон Л: да всё просто. Мы приходим к синхронным запросам из множества потоков - по одному на каждого пользователя. В идеале хотелось бы как-то ставить заглушку в этой функции, как это делает yield, чтобы по возвращении ловить event loop и продолжать с того же места в одном потоке. Но именно этот оператор в геттере пользы не принесёт.
Если всё правильно, сразу возникает следующий вопрос: можно ли разделить контекст очередей, чтобы не заставлять ждать те потоки, которые не могут помешать в конкретной ситуации? Иначе весь сервер будет зависать, пока один из сценариев не завершится полностью, чтобы передать очередь следующему.
Спасибо, но сейчас я не ищу лёгких путей, я ищу правильные (т.е. универсальные) способы. Логирование действий уместно только когда в этом есть особая необходимость, иначе это большая трата ресурсов. Разность не подходит, когда мы имеем дело с текстом (да, в этом примере я использовал числа, но это пример). Дополнительные запросы тоже не дают гарантий (просто уменьшают вероятность ошибки), но дополнительно нагружают файловую систему.
Спасибо, хочу уточнить как это работает. В начале обработки запроса создаётся соединение с базой в режиме очереди, дальше отправляются запросы, соединение закрывается. Остальные открытые соединения сохраняют запросы, но ждут закрытия предыдущего соединения, после чего последовательно обращаются к базе. Всё правильно?)
Как ты себе это представляешь? Представь онлайн игру: от одного пользователя приходит действие - нанести урон, от другого - подлечиться. Это 2 разных запроса, какие могут быть колбэки?
Не сумбур, всё понятно)
Согласен, при двусторонней подписке объекты замыкают друг друга - это как раз тот случай, о котором идёт речь. И если перезаписать down, а из него генерируются события таймаутом, наш экземпляр Up будет продолжать получать новые события, но потеряет доступ к источнику.
Окей, подождём ещё ответы.
Александр Вульф: нет, косяк был теперь - я просто закинул весь код в 1 файл для публикации и вызывал пустой скрипт.
Mysql работает, захожу через phpMyAdmin. Ошибка та же.
В грамотно построенном приложении все компоненты выполняют узко специализированную задачу, из-за чего не составляет труда их изолировать. Возможно, вам стоит пересмотреть архитектуру на предмет рефакторинга.
