|
|
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Misha TyurinSELECT pgq.next_batch('routeserver', 'routeserver') SELECT pgq.next_batch('routeserver', 'routeserver') SELECT * FROM pgq.get_batch_events(185641) WHERE pgq_ext.is_event_done('routeserver', 185641, ev_id) = false ORDER BY ev_id SELECT pgq.finish_batch(185641) SELECT pgq.next_batch('routeserver', 'routeserver') SELECT pgq.next_batch('routeserver', 'routeserver') вот это тоже у вас какой-то интересный пример. это реальный лог? где обработка то событий? или вы её вы просто не привели? батч айди вернулся, а события уже все были отработаны? Это реальный лог. Я уже не в первый раз пишу, что обработка это отсылка http запросов на удаленный сервер. Происходит она между Код: sql 1. и Код: sql 1. Естественно что в логи постгреса не пишется ничего связанного с http. set_event_done() тут не используется, тк в этом батче был только один евент. В случае когда в одном батче много евентов, используется set_event_done() ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 16:37 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Кактуз, > set_event_done() тут не используется, тк в этом батче был только один евент чет как-то сложно всё у вас. ждем логи... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 17:41 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
КактузС недавних пор возникла ситуация, когда pgq создает дублирующие батчи. Имеются ввиду батчи с разными batch_id, но содержащие идентичные ивенты. Консумер читает батч и процессит ивенты поодному, вызывая pgq_ext.set_event_done() после обработки каждого ивента( и конечно проверяет is_even_done перед обработкой). После обработки всех ивентов батча, консумер выполняет finish_batch() и берет следующий. Когда возникает проблема, консумер обрабатывает все ивенты батча 1, делает finish_batch(), finish_batch говорит "WARNING: finish_batch: batch 1 not found", после этого консумер берет батч 2, который содержит все ивенты, уже обработанные в батче 1( тот же event_id, тот же пейлоад) Сталкивался ли кто то с такой ситуацией? кактус, вы исходник-то читали? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. -- откуда мораль, вам просто нечего тут апдейтить ( в pgq.subscription нет батча where sub_batch = x_batch_id;). Почему это проиходит -- вопрос к вам, а не к pgq. я например в вашем псевдокоде вижу, что вы берете pgq.get_next_batch() а там, битым словом, (через pgq.next_batch_info<<--pgq.next_batch_custom) -- тащится именно pgq.subscription.sub_batch Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. -- откуда ровно 2 3 версии -- 1. где-то в середине между {=pgq.get_next_batch()} и {pgq.finish_batch()} вы прибиваете (дропаете, или апдейтите ему id) этот sub_batch = x_batch_id; в pgq.subscripton-е. [маловероятно, но вчитайтесь в process()] 2. вы читаете незакоммиченный next_batch в одной транзакции (так и незакомиченной|или rollback-нутой), а финишируете - в другой (где тот-же батч не виден в subscription). [наиболее вероятно, но вы божитесь, что это не так] 3. вы, в прикладухе (см. ваш код), теряете значние x_batch_id, и передаете в финиш то, чего там нет и не было на момент get_. т.ч. посмотрите на ВАШ код внимательнее -- кто-то пришибает вам батч [или портит его id] между get и finish. есть фантазия 4. -- вы берете батч в одной базульке, а пытаетесь финишировать в другой, но у вас якобы нет второй бд как-то так. ах, да, -- версия 5.: у вас множественные обработчики очереди. И один из них успевает отработать батч (а pgq успевает от него избавиться в subscription) -- и только тут второй обработчик той же очереди подходит к финишу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 10:36 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
интересуюсь-- откуда ровно 2 3 версии -- 1. где-то в середине между {=pgq.get_next_batch()} и {pgq.finish_batch()} вы прибиваете (дропаете, или апдейтите ему id) этот sub_batch = x_batch_id; в pgq.subscripton-е. [маловероятно, но вчитайтесь в process()] 2. вы читаете незакоммиченный next_batch в одной транзакции (так и незакомиченной|или rollback-нутой), а финишируете - в другой (где тот-же батч не виден в subscription). [наиболее вероятно, но вы божитесь, что это не так] 3. вы, в прикладухе (см. ваш код), теряете значние x_batch_id, и передаете в финиш то, чего там нет и не было на момент get_. т.ч. посмотрите на ВАШ код внимательнее -- кто-то пришибает вам батч [или портит его id] между get и finish. есть фантазия 4. -- вы берете батч в одной базульке, а пытаетесь финишировать в другой, но у вас якобы нет второй бд как-то так. ах, да, -- версия 5.: у вас множественные обработчики очереди. И один из них успевает отработать батч (а pgq успевает от него избавиться в subscription) -- и только тут второй обработчик той же очереди подходит к финишу Исходники я читал. Ваши версии очевидны, они выше уже обсуждались и были проверены. Приложение-консумер точно не портит pgq.subscripton, мы уже копаем в сторону других клиентов базы(мне эта версия кажется наиболее вероятной) ну и идем в сторону "записать гору SQL логов с продакшна". Когда это получится, надеюсь что-то будет видно. Сообщу о результатах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 16:03 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
КактузПриложение-консумер точно не портит pgq.subscripton<>.этого мало. у вас есть защита от запуска 2-х (и более) экземляров консумера ? //"они оба не портят", но второй экземпляр будет именно так ругаться -- если до него первый отфиниширует,и батч будет почикан из pgq.subscription ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 16:28 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Кактуз, Зачем гору логов ?? Сделайте логи только на сессии работы с pgq ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 18:29 |
|
||
|
|

start [/forum/topic.php?fid=53&gotonew=1&tid=1998202]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
192ms |
get topic data: |
12ms |
get first new msg: |
7ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 513ms |

| 0 / 0 |
