Не правильно отображает статус в процессе (в списке другой) и не списало товар, хотя "типа" перешло на этап
1. Вот процесс https://baza.cn.ua/admin/customorder/issue/23224/edit/
Показывает вот такой бред https://prnt.sc/urq03m
То есть по истории этапов показывает "Йду на відправку"
В реальности типа показывает что на этапе "Передано в службу доставки"
Этого быть по логике не должно это какой то бред выходит
2. Предполагаю что проблема получилась из-за того что на этапе "Передано в службу доставки" идет перевод подзадач в другой этап и там где то была ошибка + переводили на этап не с ПК версии, а с МП (то есть возможно баг и там, баг вывода ошибки)
Так вот с трех подзадач оказалось что проблемный это вот этот https://baza.cn.ua/admin/customorder/order/23261/edit/
В нем по истории показывает что он находится на этапе "На відправку" но если посмотреть по списку процессов то он находится на этапе "Виконано"
Вот https://baza.cn.ua/admin/customorder/order/?filtershowprocess=&filterdeliver...
Так вот суть второго блока проблемы в том что все товары которые находятся в этом заказе они не списались https://prnt.sc/urq58q , а стоят в резерве
Еще заметил что последний товар
То есть этот https://baza.cn.ua/admin/shop/products/56517/storage/
У него вообще резерв не стоял то есть в продуктах таблицей тут https://prnt.sc/urq58q показывало что резерв, а вот тут https://baza.cn.ua/admin/shop/products/56517/storage/ было 0 здесь https://prnt.sc/urq6fl (из-за того что этот товар был в наличии и начали искать проблему, если бы он был не в наличии то тогда может быть и проблему не обнаружили)
Я сейчас нажал в продуктах таблицей отмену резерва, а потом еще раз резерв (что бы оно поставило в резерв) и товар стал не в наличии
Вобщем, сложно подобрать слова, хрень полная, жду решения !!!
Показывает вот такой бред https://prnt.sc/urq03m
То есть по истории этапов показывает "Йду на відправку"
В реальности типа показывает что на этапе "Передано в службу доставки"
Этого быть по логике не должно это какой то бред выходит
2. Предполагаю что проблема получилась из-за того что на этапе "Передано в службу доставки" идет перевод подзадач в другой этап и там где то была ошибка + переводили на этап не с ПК версии, а с МП (то есть возможно баг и там, баг вывода ошибки)
Так вот с трех подзадач оказалось что проблемный это вот этот https://baza.cn.ua/admin/customorder/order/23261/edit/
В нем по истории показывает что он находится на этапе "На відправку" но если посмотреть по списку процессов то он находится на этапе "Виконано"
Вот https://baza.cn.ua/admin/customorder/order/?filtershowprocess=&filterdeliver...
Так вот суть второго блока проблемы в том что все товары которые находятся в этом заказе они не списались https://prnt.sc/urq58q , а стоят в резерве
Еще заметил что последний товар
То есть этот https://baza.cn.ua/admin/shop/products/56517/storage/
У него вообще резерв не стоял то есть в продуктах таблицей тут https://prnt.sc/urq58q показывало что резерв, а вот тут https://baza.cn.ua/admin/shop/products/56517/storage/ было 0 здесь https://prnt.sc/urq6fl (из-за того что этот товар был в наличии и начали искать проблему, если бы он был не в наличии то тогда может быть и проблему не обнаружили)
Я сейчас нажал в продуктах таблицей отмену резерва, а потом еще раз резерв (что бы оно поставило в резерв) и товар стал не в наличии
Вобщем, сложно подобрать слова, хрень полная, жду решения !!!
Ответы:
В общем проблема в принципе очевидна .
Это происходит когда mysql не успевает обработать быстро запросы и блокирует таблицы , в эти моменты он отдает ошибку DEADLOCK либо подобное на has gone away . И часть данных (по типу история перехода статуса) могут попросту не вставиться в БД .
Решается 2мя путями
1) повышение мощности сервера
2) включения безопасного режима MYSQL который выдаст тебе на экран в лицо ошибку если какая-то из нужных ему таблиц заблокирована
на данный момент я тебе включил пункт 2
Это происходит когда mysql не успевает обработать быстро запросы и блокирует таблицы , в эти моменты он отдает ошибку DEADLOCK либо подобное на has gone away . И часть данных (по типу история перехода статуса) могут попросту не вставиться в БД .
Решается 2мя путями
1) повышение мощности сервера
2) включения безопасного режима MYSQL который выдаст тебе на экран в лицо ошибку если какая-то из нужных ему таблиц заблокирована
на данный момент я тебе включил пункт 2
02.10.2020, 17:16
Устименко Игорь OneBox CTO писал/а:
В общем проблема в принципе очевидна . Это происходит когда mysql не успевает обработать быстро запросы и блокирует таблицы , в эти моменты он отдает ошибку DEADLOCK либо подобное на has gone away . И часть данных (по типу история перехода статуса) могут попросту не вставиться в БД . Решается 2мя путями 1) повышение мощности сервера 2) включения безопасного режима MYSQL который выдаст тебе на экран в лицо ошибку если какая-то из нужных ему таблиц заблокирована на данный момент я тебе включил пункт 2
1. Что конкретно нужно повышать на сервере (оперативку, процессор) ?
2. Выходить у меня какие то сложные бизнес процессы (перевести подзадачи в нужный статусы и по подзадачам отправить статус в розетку) что сервер не может их отработать до конца ?
3. Почему не хватило мощности списать товар, но хватило перевести на финишный статус, при том что это последнее что должна сделать система ?
4. Почему возникла проблема по процессу у которого подпроцессов было 3 штуки, но ранее не возникала по процессу у которого было 14 подпроцессов ?
02.10.2020, 18:56
1. Я не занимаюсь бесплатной аналитикой твоего сервера чтобы отвечать на этот вопрос
2. Нет не думаю
3. Таблица могла быть заблокированна другим процессом (в фоне к примеру кроном)
4. Нет разницы сколько подпроцессов
2. Нет не думаю
3. Таблица могла быть заблокированна другим процессом (в фоне к примеру кроном)
4. Нет разницы сколько подпроцессов
05.10.2020, 09:15
Устименко Игорь OneBox CTO писал/а:
3. Таблица могла быть заблокированна другим процессом (в фоне к примеру кроном)
Если это так, то это очень похоже на баг, как по мне если есть с системе процедуры блокирующие запись или полностью таблицы то другие процедуры должны перед апдетом сначала уточнить не заблокирована ли запись или таблица и уже после этого проводить свою работу (при этом также блокировать запись или таблицу)
А здесь выходить так что идет кусок кода, в нем нужно что то апдейтить, процедура получила отказ от БД, и потом, ну и ладно пойду дальше, переведу в статус выполнено, мне пофиг что база дала отказ, моя задача перейти в статус выполнено
Насколько я помню вы не использовали особо нигде принцип блокировки, вы писали вроде код "кто последний того и тапки".
Или я не правильно рассуждаю и не правильно тебя понял (просто у меня сейчас баг висить выходит статус истории один, в реальности другой и кто это будет исправлять мне непонятно) ?
05.10.2020, 10:54
Куприян Владислав Валерьевич
Baza.cn.ua / Integrator (FOP Kupriyan) писал/а:
Устименко Игорь OneBox CTO писал/а:3. Таблица могла быть заблокированна другим процессом (в фоне к примеру кроном)Если это так, то это очень похоже на баг, как по мне если есть с системе процедуры блокирующие запись или полностью таблицы то другие процедуры должны перед апдетом сначала уточнить не заблокирована ли запись или таблица и уже после этого проводить свою работу (при этом также блокировать запись или таблицу)А здесь выходить так что идет кусок кода, в нем нужно что то апдейтить, процедура получила отказ от БД, и потом, ну и ладно пойду дальше, переведу в статус выполнено, мне пофиг что база дала отказ, моя задача перейти в статус выполненоНасколько я помню вы не использовали особо нигде принцип блокировки, вы писали вроде код "кто последний того и тапки".Или я не правильно рассуждаю и не правильно тебя понял (просто у меня сейчас баг висить выходит статус истории один, в реальности другой и кто это будет исправлять мне непонятно) ?
Твоя теория не верна. Влад я не готов сидеть и обучать тебя что такое транзакции MYSQL + LOCK таблиц.
05.10.2020, 10:56
Устименко Игорь OneBox CTO писал/а:
Куприян Владислав ВалерьевичBaza.cn.ua / Integrator (FOP Kupriyan) писал/а:Устименко Игорь OneBox CTO писал/а:3. Таблица могла быть заблокированна другим процессом (в фоне к примеру кроном)Если это так, то это очень похоже на баг, как по мне если есть с системе процедуры блокирующие запись или полностью таблицы то другие процедуры должны перед апдетом сначала уточнить не заблокирована ли запись или таблица и уже после этого проводить свою работу (при этом также блокировать запись или таблицу)А здесь выходить так что идет кусок кода, в нем нужно что то апдейтить, процедура получила отказ от БД, и потом, ну и ладно пойду дальше, переведу в статус выполнено, мне пофиг что база дала отказ, моя задача перейти в статус выполненоНасколько я помню вы не использовали особо нигде принцип блокировки, вы писали вроде код "кто последний того и тапки".Или я не правильно рассуждаю и не правильно тебя понял (просто у меня сейчас баг висить выходит статус истории один, в реальности другой и кто это будет исправлять мне непонятно) ?Твоя теория не верна. Влад я не готов сидеть и обучать тебя что такое транзакции MYSQL + LOCK таблиц.
Игорь, я также не готов изучать, мне это на текущий момент не нужно, мне нужно что бы система работала стабильно, пока возникают вещи которые пугают и не поддаются никакой адекватной логике (база выходит живет своей жизнью, менеджер который жмет кнопку в другой выходит реальности).
Пока мне непонятно в чем проблема изначально ты говорил что сервер, теперь блокировка таблицы (как по мне это не связанные вещи, глобально)
Ты можешь мне конкретно сказать что у тебя проблема в этой задаче с блокировкой таблицы, что бы решить эту проблему нужно .... или же что у тебя плохой сервер, мало оперативы (дальше я буду тестировать сервер и попробую получить еще раз эту ошибку и потом буду писать на хостера, что бы тестово мне увеличили параметры которых не хватает, как в прошлый раз, когда ты утверждал что нужно добавлять оперативку) ?
05.10.2020, 11:14
Свяжи то что я написал и ответишь на свой вопрос
Любая транзакция в БД блокирует таблицу, и период блокировки зависит от мощности сервера, чем он мощнее тем быстрее выполнит операцию и разблокирует таблицу и шанс попасть на LOCK будет меньше.
Так понятней?
Любая транзакция в БД блокирует таблицу, и период блокировки зависит от мощности сервера, чем он мощнее тем быстрее выполнит операцию и разблокирует таблицу и шанс попасть на LOCK будет меньше.
Так понятней?
05.10.2020, 11:32
Устименко Игорь OneBox CTO писал/а:
Свяжи то что я написал и ответишь на свой вопрос Любая транзакция в БД блокирует таблицу, и период блокировки зависит от мощности сервера, чем он мощнее тем быстрее выполнит операцию и разблокирует таблицу и шанс попасть на LOCK будет меньше. Так понятней?
Да, вполне
Почему тогда действие не проверило заблокирована запись или нет ?
05.10.2020, 11:59
Куприян Владислав Валерьевич
Baza.cn.ua / Integrator (FOP Kupriyan) писал/а:
Устименко Игорь OneBox CTO писал/а:Свяжи то что я написал и ответишь на свой вопрос Любая транзакция в БД блокирует таблицу, и период блокировки зависит от мощности сервера, чем он мощнее тем быстрее выполнит операцию и разблокирует таблицу и шанс попасть на LOCK будет меньше. Так понятней?Да, вполнеПочему тогда действие не проверило заблокирована запись или нет ?
Если ты будешь стучаться в таблицу перед каждым запросом и проверять LOCK она или нет , то колличество запросов вырастет в 1000 раз .
05.10.2020, 13:31
Устименко Игорь OneBox CTO писал/а:
Куприян Владислав ВалерьевичBaza.cn.ua / Integrator (FOP Kupriyan) писал/а:Устименко Игорь OneBox CTO писал/а:Свяжи то что я написал и ответишь на свой вопрос Любая транзакция в БД блокирует таблицу, и период блокировки зависит от мощности сервера, чем он мощнее тем быстрее выполнит операцию и разблокирует таблицу и шанс попасть на LOCK будет меньше. Так понятней?Да, вполнеПочему тогда действие не проверило заблокирована запись или нет ?Если ты будешь стучаться в таблицу перед каждым запросом и проверять LOCK она или нет , то колличество запросов вырастет в 1000 раз .
Я прекрасно понимаю что проверка блокировки это кусок кода
Я участвовал в разработке ПО где этому уделяли много внимания и по этому меня удивило почему в OneBox это не делает, я также понимал что это уменьшает скорость обработки и не является критичным, при том что есть логирование действий (так как это не совсем учетная системе, в учетных это более критично)
В общем я правильно понимаю что то что товар не списало, но перевело на статус на котором оно должно списать это сугубо моя проблема (либо настройки бизнес процесса или сервера) ?
05.10.2020, 16:55
Куприян Владислав Валерьевич
Baza.cn.ua / Integrator (FOP Kupriyan) писал/а:
Устименко Игорь OneBox CTO писал/а:Куприян Владислав ВалерьевичBaza.cn.ua / Integrator (FOP Kupriyan) писал/а:Устименко Игорь OneBox CTO писал/а:Свяжи то что я написал и ответишь на свой вопрос Любая транзакция в БД блокирует таблицу, и период блокировки зависит от мощности сервера, чем он мощнее тем быстрее выполнит операцию и разблокирует таблицу и шанс попасть на LOCK будет меньше. Так понятней?Да, вполнеПочему тогда действие не проверило заблокирована запись или нет ?Если ты будешь стучаться в таблицу перед каждым запросом и проверять LOCK она или нет , то колличество запросов вырастет в 1000 раз .Я прекрасно понимаю что проверка блокировки это кусок кода Я участвовал в разработке ПО где этому уделяли много внимания и по этому меня удивило почему в OneBox это не делает, я также понимал что это уменьшает скорость обработки и не является критичным, при том что есть логирование действий (так как это не совсем учетная системе, в учетных это более критично)В общем я правильно понимаю что то что товар не списало, но перевело на статус на котором оно должно списать это сугубо моя проблема (либо настройки бизнес процесса или сервера) ?
Понимай как хочешь - я возиться с тобой как с ребенком не собираюсь да и другие тоже
я еще в 1м комменте написал тебе что сделано для решения проблемы и что будет
остальное это сугубо твое любопытство которое занимает мое время
05.10.2020, 23:58
В этой задаче https://baza.cn.ua/admin/customorder/issue/23224/edit/
Не правильно отображает статус https://prnt.sc/v1m3in
Можете исправить ?
Не правильно отображает статус https://prnt.sc/v1m3in
Можете исправить ?
18.10.2020, 13:31
нет мы не занимаемся таким бесплатно
18.10.2020, 16:45
Устименко Игорь OneBox CTO писал/а:
нет мы не занимаемся таким бесплатно
Ну так это же баг то что система не правильно отображает в истории или это нормально ?
18.10.2020, 20:57
Куприян Владислав Валерьевич
Baza.cn.ua / Integrator (FOP Kupriyan) писал/а:
Устименко Игорь OneBox CTO писал/а:
нет мы не занимаемся таким бесплатно
Ну так это же баг то что система не правильно отображает в истории или это нормально ?
тебе уже дали ответ почему так
ты можешь решить данный вопрос самостоятельно - сделав повторный переход на этап
18.10.2020, 20:59
Устименко Игорь OneBox CTO писал/а:
Куприян Владислав Валерьевич
Baza.cn.ua / Integrator (FOP Kupriyan) писал/а:
Устименко Игорь OneBox CTO писал/а:
нет мы не занимаемся таким бесплатно
Ну так это же баг то что система не правильно отображает в истории или это нормально ?
тебе уже дали ответ почему так
ты можешь решить данный вопрос самостоятельно - сделав повторный переход на этап
Это "ручник" выходит что бы мне это сделать нужно отключать действия и т.д.
Плюс я не уверен что это в одном процессе такая проблема
Ладно я сделаю но мне кажется это должны были сделать вы, как последствие бага
18.10.2020, 22:23
Пожалуйста, присоединяйтесь к диалогу. Если вам есть что сказать - пожалуйста, напишите комментарий. Для входа потребуется мобильный телефон и смс-код для идентификации.
Войти и написать комментарий
Copyright © OneBox 2024
