|
|
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
Сделал очередь, зарегистрировал подписчика и plsql метод, который автоматически вызывается при добавлении сообщения в очередь. Все хорошо. Теперь есть задача временно прекратить разбор сообщений на какое-то время и потом его продолжить. Как это сделать? Если остановить dequeue очереди через Код: plsql 1. 2. 3. , то как потом сделать, чтобы сообщения, которые накопились в очереди, разобрались подписчиком? Новые сообщения разбираются, а те, что уже есть, так и лежат в очереди. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2016, 16:34:40 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
rybinglebСделал очередь, зарегистрировал подписчика и plsql метод, который автоматически вызывается при добавлении сообщения в очередь. Все хорошо. Теперь есть задача временно прекратить разбор сообщений на какое-то время и потом его продолжить. Как это сделать? Если остановить dequeue очереди через Код: plsql 1. 2. 3. , то как потом сделать, чтобы сообщения, которые накопились в очереди, разобрались подписчиком? Новые сообщения разбираются, а те, что уже есть, так и лежат в очереди. Не знаю какая у вас версия , я на 9-й проходил когда распухает q-table начинаются дикие тормоза на HWM и тд итп . Все заканчивается остановкой всех кто работатет с очередью ( нарушением SLA ) и ее пересозданием в самый неподходящий момент бизнес процесса. Вобщем выпилили эту фичу из бизнес процессов и возвращаться желания нет. Если очередь имеет свойство накаплшиваться , рекомендую более углубленно протестировать производительность в разных режимах накопления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2016, 21:27:00 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
>, то как потом сделать, чтобы сообщения, которые накопились в очереди, разобрались подписчиком? Новые сообщения разбираются, а те, что уже есть, так и лежат в очереди. Можете приложить тесткейз (полные скрипты для репродуцирования) текст plsql notification,если он конфиденциален, можно не публиковать. При всем, попробуйте предоставить сценарий, которой худо-бедно можно будет повторить в базе данных не имеющей отношения к Вашей application specific. Поясню цель: при наличии тесткейза понимание сути данной проблемы инженерами со стороны и ее последующее решение значительно ускорится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2016, 01:37:18 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
rybingleb... , то как потом сделать, чтобы сообщения, которые накопились в очереди, разобрались подписчиком? Новые сообщения разбираются, а те, что уже есть, так и лежат в очереди. Нотификация - доп. фишка, для основного режима на клиентской стороне д.б. прямое вычитывание... Вычитать и вчитать обратно - не помогло? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2016, 05:07:15 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
rybinglebсделать, чтобы сообщения, которые накопились в очереди, разобрались подписчиком?вызывать в цикле подписанную процедуру обработки, пока есть сообщения. Для поддержки временной приостановки удобнее повесить джоб(ы) и в них заложить реакцию на stop dequeue или, если кроме них никто не читает, просто останавливать джобы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2016, 09:36:58 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
de'Queuerybinglebсделать, чтобы сообщения, которые накопились в очереди, разобрались подписчиком?вызывать в цикле подписанную процедуру обработки, пока есть сообщения. Для поддержки временной приостановки удобнее повесить джоб(ы) и в них заложить реакцию на stop dequeue или, если кроме них никто не читает, просто останавливать джобы. Вот как раз хотелось уйти от джобов. Сейчас так и сделано - есть очередь, есть джоб, который постоянно запускает процедуру, которая делает dequeue. Мне это казалось немного костыльным. авторМожете приложить тесткейз (полные скрипты для репродуцирования) текст plsql notification,если он конфиденциален, можно не публиковать. При всем, попробуйте предоставить сценарий, которой худо-бедно можно будет повторить в базе данных не имеющей отношения к Вашей application specific. Поясню цель: при наличии тесткейза понимание сути данной проблемы инженерами со стороны и ее последующее решение значительно ускорится. Код: 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. 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. Все работает нормально, очередь разгребается, по-моему, в пять потоков, сообщения переносятся в таблицу message_table. К примеру, у меня таким образом будут рассылаться СМС. Допустим, я нашел ошибку в процедуре XXTEST_CALLBACK и хочу временно остановить разбор очереди, но при этом не останавливать добавление сообщений в очередь. Делаю Код: plsql 1. 2. 3. Смотрю Код: plsql 1. 2. Все ок, ENQUEUE_ENABLED = YES, DEQUEUE_ENABLED = NO. Очередь перестает разбираться, процедура XXTEST_CALLBACK пишет ошибки "ORA-25226: dequeue failed, queue INFONEXT.XXTEST_QUEUE is not enabled for dequeue". Все как я и хотел. Потом, допустим, я исправил ошибку в процедуре XXTEST_CALLBACK. И хочу продолжить разбор очереди. Делаю Код: plsql 1. 2. 3. В результате сообщения, которые были в очереди после остановки, так там и остаются. Вот как теперь сделать, чтобы процедура XXTEST_CALLBACK продолжила их разбирать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2016, 09:58:22 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
В данном случае, наверное, нужно остановить enque, дождаться пока все сообщения разберуться агентом, и после этого останавливать dequeue, если нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2016, 11:56:46 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
Я бы сделал перед остановкой очереди сначала unregister: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. потом остановил очередь, сделал изменения в процедуре, потом запустил очередь, потом снова sys.dbms_aq.register. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2016, 13:31:49 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
Попробуйте такВ данном случае, наверное, нужно остановить enque, дождаться пока все сообщения разберуться агентом, и после этого останавливать dequeue, если нужно. Если остановить enque, то все процессы, которые добавляют в очередь, будут получать ошибки. А хотелось бы, что они они добавляли в очередь, как обычно, но прекратился именно разбор. авторЯ бы сделал перед остановкой очереди сначала unregister: Попробовал так сделать. Но проблема та же - потом, когда делаю start_queue и register, уже существующие в очереди сообщения не разбираются, только новые, которые появляются в очереди после register. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2016, 14:41:31 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
ИМХО, callback возникает при попадании сообщения в очередь. При остановке коллбэки не генерируются(или игнорируются процедурой обработки) При старте - генерируются коллбэки при помещении в очередь, но те сообщения что в очереди уже вчера сгенерировали коллбэки Т е нужно это сообщения выбрать и опять поместить в очередь(сгенерируется коллбэк) Либо выбрать и обработать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2016, 14:56:09 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
У меня Ваш тесткейз не получился, возможно из-за порядка вызовов, возможно из-за того что пришлось править процедуру callback (у меня нет таких пакетов). Проверьте есть ли сообщения тут SYS.AQ_SRVNTFN_TABLE_<N> ? Сюда попадают сообщения сразу после enqueue в Вашу очередь, при наличии зарегистрированного callback. Если подписчик не зарегистрирован, то сообщения сюда не кладутся при enqueue и никакого оповещения по таким messages в Вашей очереди не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2016, 16:50:57 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
landyИМХО, callback возникает при попадании сообщения в очередь. При остановке коллбэки не генерируются(или игнорируются процедурой обработки) При старте - генерируются коллбэки при помещении в очередь, но те сообщения что в очереди уже вчера сгенерировали коллбэки Т е нужно это сообщения выбрать и опять поместить в очередь(сгенерируется коллбэк) Либо выбрать и обработать Скорее всего. Жаль, то есть получается, что в дополнение к процедуре callback, надо будет писать что-то, что будет разбирать сообщения в случае остановки очереди. авторПроверьте есть ли сообщения тут SYS.AQ_SRVNTFN_TABLE_<N> ? Сюда попадают сообщения сразу после enqueue в Вашу очередь, при наличии зарегистрированного callback. Если подписчик не зарегистрирован, то сообщения сюда не кладутся при enqueue и никакого оповещения по таким messages в Вашей очереди не будет. Есть строки в SYS.AQ_SRVNTFN_TABLE. При enqueue как раз все срабатывает как надо. Вопрос был про обработку сообщения из очереди, после остановки dequeue. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2016, 17:32:27 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
rybinglebесть джоб, который постоянно запускает процедуру, которая делает dequeue. Мне это казалось немного костыльным. Если вам кажется костыльным периодический поллинг очереди... Можно воспользоваться DBMS_ALERT, например, что-бы работать по событиям. В процедуру enqueue_msg добавляете отправку ALERT-а (DBMS_ALERT.SIGNAL). Джоб, занимающийся разборкой очереди делаете постоянно выполняющимся. Если делать совсем красиво, то примерно так: При старте джоба разбирается все, что есть в очереди, после чего вход в цикл и "засыпание" на ожидании ALERT-а (DBMS_ALERT.WAITONE); С ALERT-ом передавать параметр-команду - сигнализирующую о назначении ALERT-а, команд будет четыре: Проверить очередь на наличие сообщений - проверка выполняется во вложенном цикле из которого выходим по событию отсутствия сообщений в очереди; Перейти в состояние "MAINTENANCE" - обрабатываются только команды завершения работы и возврата в нормальный режим обработки, разбор очереди не выполняется; Перейти в состояние нормальной обработки; Завершить работу джоба; При таком раскладе можно как приостанавливать разбор очереди, переходя в режим "MAINTENANCE", так и просто останавливать джоб - ALERT-ы не переполняются, поскольку каждый новый ALERT переписывает предшествующий. Подписка при этом становится ненужной. PS: Вместо передачи параметра с ALERT-ом можно объявить необходимое их количество, но на мое сугубое HO - использование DBMS_ALERT.WAITONE предпочтительнее DBMS_ALERT.WAITANY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2016, 19:57:08 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
Еще одно предложение: сделать две очереди. В одну помещать сообщения, а из другой вычитывать агентом. Между ними, настроить propagation, и "разруливать" на этом уровне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 08:36:29 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
rybingleb, К какому решение в итоге пришли? У меня сейчас аналогичная дилемма с dequeue ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2016, 09:04:14 |
|
||
|
AQ и подписчики
|
|||
|---|---|---|---|
|
#18+
В подписчик добавить цикл Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2016, 15:45:16 |
|
||
|
|

start [/forum/topic.php?fid=52&fpage=215&tid=1888030]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
35ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
2ms |
| others: | 199ms |
| total: | 326ms |

| 0 / 0 |
