utm и платежи

[Gezm0]

Думаю, ни для кого не секрет, что есть у utm'а такая замечательная особенность - дупить платежи, которые сваливаются в т.ч. от модуля платёжных систем. Проблема проявляется при достаточно загруженном сервере БД и по мнению нашего админа не зависит от версии модуля платёжных систем т.к. дупы производят и при использовании самописных костылей, которые работают не через модуль платёжных систем. Так что же происходит? Используются транзакции и по мнению нашего админа происходит следующее.. Приходит запрос на платёж, который помещается в очередь и происходит проверка наличия платежа в базе. Если всё нормально платёж проводится и записывается в базу, из очереди удаляется. Если БД занята, то платёж висит в очереди и ждёт своей очереди, а в это время приходит ещё один такой же платёж, который видит что в базе не проведён и тоже помещается в очередь. Потом, конечно, БД освобождается и все платежи, которые висят в очереди, записываются в БД. Я лично наблюдал до 5 одинаковых платежей. Обычно 2-3. Повторюсь, что это лишь предположение, поскольку API биллинга закрыто и не представляется возможным выяснить что же происходит на самом деле и как с этим бороться. Если проблема действительно в этом, очевидно, можно было бы добавить дополнительную проверку и помещать платёж в очередь не только при отсутствии в его в БД, но и при отсутствии такого же платежа в очереди.

[Chris]

Ни разу не было... Даешь лог проведения двойного платежа!

[Gezm0]

Ни разу не было... Даешь лог проведения двойного платежа!

Что подразумевается под "логом проведения двойного платежа"? В отчёте по платежам это выглядит примерно так:
4597 account Thu Aug 27 17:48:37 GMT+04:00 2009 50.0 Электронная платежная система (101) payment_system (-12) txn_id=одинаковые_номера Thu Aug 27 17:48:28 GMT+04:00 2009
4597 account Thu Aug 27 17:48:37 GMT+04:00 2009 50.0 Электронная платежная система (101) payment_system (-12) txn_id=одинаковые_номера Thu Aug 27 17:48:28 GMT+04:00 2009

[Chris]

Да нафиг мне отчеты по платежам, мне бы в debug.log это

[Gezm0]

Да нафиг мне отчеты по платежам, мне бы в debug.log это

Хо-хо. Там пролетает 100мб текста за 70-80 секунд. При всём желании выловить это не представляется возможным. Логлевел поменьше подкрутим перед рестартом, может получится что-нибудь поймать. Мы пока только наблюдаем последствия, без явных причин.

[Gezm0]

Да нафиг мне отчеты по платежам, мне бы в debug.log это

Вот вам дуп. В данном случае через самописный модуль с занесением через utm5_payment_tool. Как получится выловить дуп через модуль osmp, скину.

?Debug : Sep 01 10:06:05 DBCtx: <140252160> SQL query: INSERT INTO payment_trans
actions(account_id,payment_incurrency,currency_id,currency_rate,payment_absolute
,actual_date,payment_enter_date,method,who_receive,comments_for_user,comments_fo
r_admins,payment_ext_number,burn_time,hash,charge_id ) VALUES('5808','1000','810
','1','1000','1251785109','1251785164','101','-12','Recieved from SPRINTNET 1000
','Recieved from SPRINTNET 1000','SN6208709090187324','0','','418734317')


?Debug : Sep 01 10:06:05 DBCtx: <140252160> SQL query: INSERT INTO payment_trans
actions(account_id,payment_incurrency,currency_id,currency_rate,payment_absolute
,actual_date,payment_enter_date,method,who_receive,comments_for_user,comments_fo
r_admins,payment_ext_number,burn_time,hash,charge_id ) VALUES('5808','1000','810
','1','1000','1251785141','1251785165','101','-12','Recieved from SPRINTNET 1000
','Recieved from SPRINTNET 1000','SN6208709090187324','0','','418734318')

[Lex]

Вот вам дуп. В данном случае через самописный модуль с занесением через utm5_payment_tool. Как получится выловить дуп через модуль osmp, скину.

?Debug : Sep 01 10:06:05 DBCtx: <140252160> SQL query: INSERT INTO payment_trans
actions(account_id,payment_incurrency,currency_id,currency_rate,payment_absolute
,actual_date,payment_enter_date,method,who_receive,comments_for_user,comments_fo
r_admins,payment_ext_number,burn_time,hash,charge_id ) VALUES('5808','1000','810
','1','1000','1251785109','1251785164','101','-12','Recieved from SPRINTNET 1000
','Recieved from SPRINTNET 1000','SN6208709090187324','0','','418734317')


?Debug : Sep 01 10:06:05 DBCtx: <140252160> SQL query: INSERT INTO payment_trans
actions(account_id,payment_incurrency,currency_id,currency_rate,payment_absolute
,actual_date,payment_enter_date,method,who_receive,comments_for_user,comments_fo
r_admins,payment_ext_number,burn_time,hash,charge_id ) VALUES('5808','1000','810
','1','1000','1251785141','1251785165','101','-12','Recieved from SPRINTNET 1000
','Recieved from SPRINTNET 1000','SN6208709090187324','0','','418734318')

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

[Gezm0]

Вот вам дуп. В данном случае через самописный модуль с занесением через utm5_payment_tool. Как получится выловить дуп через модуль osmp, скину.

?Debug : Sep 01 10:06:05 DBCtx: <140252160> SQL query: INSERT INTO payment_trans
actions(account_id,payment_incurrency,currency_id,currency_rate,payment_absolute
,actual_date,payment_enter_date,method,who_receive,comments_for_user,comments_fo
r_admins,payment_ext_number,burn_time,hash,charge_id ) VALUES('5808','1000','810
','1','1000','1251785109','1251785164','101','-12','Recieved from SPRINTNET 1000
','Recieved from SPRINTNET 1000','SN6208709090187324','0','','418734317')


?Debug : Sep 01 10:06:05 DBCtx: <140252160> SQL query: INSERT INTO payment_trans
actions(account_id,payment_incurrency,currency_id,currency_rate,payment_absolute
,actual_date,payment_enter_date,method,who_receive,comments_for_user,comments_fo
r_admins,payment_ext_number,burn_time,hash,charge_id ) VALUES('5808','1000','810
','1','1000','1251785141','1251785165','101','-12','Recieved from SPRINTNET 1000
','Recieved from SPRINTNET 1000','SN6208709090187324','0','','418734318')

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

Всё по порядку. Сначала новый трейс по поводу утечки памяти в 007-релиз.

[Gezm0]

Насчёт дампа базы не очень понял.

[Lex]

Насчёт дампа базы не очень понял.

Может потребоваться в процессе диагностики. Особенно если используются платежные системы.

[gravis]

Я натыкался на именно такую проблему хоть и не пользуюсь нетаповскими модулями приема платежей. Принцип действия в любом случае одинаковый =) Пока DB перегружена или таблица тупо залочена, модуль не может реально проверить был ли проведен платеж или небыл, вот и фигачит их с такой скоростью с какой приходят запросы от сервера платежной системы! а т.к. база "висит", то сервер не получает подтверждения о проведении платежа и посылает его еще раз и еще раз...

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

1. модуль взаимодействия с сервером платежной системы (обычно это CGI скрипт/программа), принимает платеж, выполняет необходимые проверки, и помещает его в независимый стек (реализовать можно как угодно, например как mail spool dir или SQL таблицы). маркером уникальности платежа в этом случае легко полужит номер транзакции в платежной системе (payment_ext_number) при этом серверу платежной системы сообщается что платеж проведен (если прошли все необходимые проверки). если проверки не прошли (база перегружена например) то ничего страшного, сервер стукнется к нам еще... но в любом случае в стеке у нас будет только 1 запись о каждом реальном платеже

2. модуль проведения платежей берет очередной платеж из стека и проводит его. после успешного проведения платежа, запись удаляется из стека и проводится следующий платеж. можно запускать "по крону" хоть каждую минуту

данная схема работает уже более года без нареканий, ни одного дупа выловлено небыло

[Lex]

Я натыкался на именно такую проблему хоть и не пользуюсь нетаповскими модулями приема платежей. Принцип действия в любом случае одинаковый =) Пока DB перегружена или таблица тупо залочена, модуль не может реально проверить был ли проведен платеж или небыл, вот и фигачит их с такой скоростью с какой приходят запросы от сервера платежной системы! а т.к. база "висит", то сервер не получает подтверждения о проведении платежа и посылает его еще раз и еще раз...

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

1. модуль взаимодействия с сервером платежной системы (обычно это CGI скрипт/программа), принимает платеж, выполняет необходимые проверки, и помещает его в независимый стек (реализовать можно как угодно, например как mail spool dir или SQL таблицы). маркером уникальности платежа в этом случае легко полужит номер транзакции в платежной системе (payment_ext_number) при этом серверу платежной системы сообщается что платеж проведен (если прошли все необходимые проверки). если проверки не прошли (база перегружена например) то ничего страшного, сервер стукнется к нам еще... но в любом случае в стеке у нас будет только 1 запись о каждом реальном платеже

2. модуль проведения платежей берет очередной платеж из стека и проводит его. после успешного проведения платежа, запись удаляется из стека и проводится следующий платеж. можно запускать "по крону" хоть каждую минуту

данная схема работает уже более года без нареканий, ни одного дупа выловлено небыло

О каком модуле в данном случае идет речь? Об утилите utm5_payment_tool?

[Gezm0]

Насчёт дампа базы не очень понял.

Может потребоваться в процессе диагностики. Особенно если используются платежные системы.

К сожалению дамп базы и обороты по 51 счету предоставить не могу. По понятным причинам.

[Gezm0]

Я натыкался на именно такую проблему хоть и не пользуюсь нетаповскими модулями приема платежей. Принцип действия в любом случае одинаковый =) Пока DB перегружена или таблица тупо залочена, модуль не может реально проверить был ли проведен платеж или небыл, вот и фигачит их с такой скоростью с какой приходят запросы от сервера платежной системы! а т.к. база "висит", то сервер не получает подтверждения о проведении платежа и посылает его еще раз и еще раз...

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

1. модуль взаимодействия с сервером платежной системы (обычно это CGI скрипт/программа), принимает платеж, выполняет необходимые проверки, и помещает его в независимый стек (реализовать можно как угодно, например как mail spool dir или SQL таблицы). маркером уникальности платежа в этом случае легко полужит номер транзакции в платежной системе (payment_ext_number) при этом серверу платежной системы сообщается что платеж проведен (если прошли все необходимые проверки). если проверки не прошли (база перегружена например) то ничего страшного, сервер стукнется к нам еще... но в любом случае в стеке у нас будет только 1 запись о каждом реальном платеже

2. модуль проведения платежей берет очередной платеж из стека и проводит его. после успешного проведения платежа, запись удаляется из стека и проводится следующий платеж. можно запускать "по крону" хоть каждую минуту

данная схема работает уже более года без нареканий, ни одного дупа выловлено небыло

Спасибо. Мы примерно над таким костылём сейчас и работаем т.к. поняли что с разработчиками каши не сваришь.

[Lex]

Насчёт дампа базы не очень понял.

Может потребоваться в процессе диагностики. Особенно если используются платежные системы.

К сожалению дамп базы и обороты по 51 счету предоставить не могу. По понятным причинам.

Интересно по каким? Нам ваша финансовая информация не нужна. Соглашение о конфиденциальности подписывается легко - нужно просто обратиться в отдел продаж.
Без дампа базы проблему диагностировать бессмысленно. На стендах, насколько я знаю, даже под нагрузкой платежи не двоятся. Один запрос - один платеж.
И вообще, ругать разработчиков за то что проблемы не решаются и при этом не предоставлять полную информацию по проблеме как минимум странно.