Не проще ли протухшие сообщения игнорировать (обрабатывать) на стороне получателя, чем откладывать всторону, а потом разбираться с ними отдельно.

andrey_anonymousmcureenabНе проще ли протухшие сообщения игнорировать (обрабатывать) на стороне получателя
А с чего они "протухли"-то? Не с того ли, что получатель не смог их вовремя обработать?
Тогда логичный вопрос: а откуда уверенность , что получатель сможет обработать тухлятину?

А в чём проблема то? Получатель тянет сообщение, оно по сроку тухлое, получатель отправляет это сообщение ф топку.
Другое дело, что получатель вообще не читает сообщения...

Афтору следует подумать, а не сигнализирует ли образование тухляка о какой либо проблеме? Если так, то следует завести процесс-монитор, который будет читать очередь исключений и сигналить о проблеме. Надо заметить, что исключения могут возникать не только по таймауту но и по количеству попыток обработать сообщение.

andrey_anonymousmgAВ смысле не нарушит ли это какую-то целостность очереди ?
Это называется "SQL Approach" и, если не ошибаюсь , является документированным способом работы с очередью AQ - давно доку не перечитывал :)

Наверное всётаки ошибаешься. Не видал я такой шняги. Хотя делать SQL запросы к представлениям над таблицей очереди можно и иногда полезно.

Вот нагугул такое письмо.
Delete-from-a-queue-table

PS. Как то раз удаляли криво созданную (через импорт) непомерно распухшую очередь. Скрипт надолго завис на операции dequeue. Вероятно, оракл таким образом чистил удаляемую очередь или подписчика. Проблему решили очисткой таблицы очереди посредством truncate table. После удаления таблицу и очереди создали заново. О каких либо проблемах с этой очередью я больше не слышал.

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

Ok. Встречал такое, когда подписчик слишком долго лежал и не читал сообщения, чистка очереди заняла столько времени, что сервис был убит по таймауту.

Решение видится в том, чтобы во время простоя какой то другой сервис читал сообщения из шатной очереди или из очереди исключений (при использовании механизма протухания). Чисто технически проще читать очередь исключений, чем координировать процессы, читающие из одного подписчика.

Так чтобы получатель тратил заметное время на dequeue наблюдал только при использовании callback процедуры на очереди. Там запуск процесса в котором выполнялась callback процедура занимал много времени.

PS. Интересно, если при создании подписчика в rule указать что то типа "sysdate - 1 < msg_timestamp". Не будут ли такие сообщения удалены автоматически в процессе dequeue или даже асинхронно?

mgA
Всё же подводя итоги, получается что чистить таблицу очереди допустимо хоть и не совсем документировано, правильно?


Я бы сказал, совсем недокументировано, на свой страх и риск.

Только вот не совсем понятно, зачем тебе очередь, если сообщения протухают в таком диком колличестве. ИМХО, тут что то типа сигналов (см. DBMS_ALERT) нужно делать.

mgA,

DBMS_ALERT коммиты не делает, но сериализует доступ к алерту.

На форуме пробегали всякие поделки направленные на улучшение DBMS_ALERT.

Наконец, почему бы просто не вставлять записи-сигналы в обычную таблицу. Получатель будет периодически просто вызывать delete, и если 0 < sql%rowcount, значит сигнал получен.

mgA,

ну кто то ляпнул не подумав. Всяко бывает. Вы лучше доку читайте.

Тебе вообще важно чтобы сообщения по порядку приходили? Или важен только факт соощения?

mgAАлерты - звучит заманчиво, на днях протестирую что это и с чем их едят.

Не обольщаяйся. Хорошее дело алертом не назовут.