Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
AQ propagation
|
|||
|---|---|---|---|
|
#18+
И все-таки оно заработало!!! Итак, что есть: Код: plsql 1. BANNER Oracle Database 18c Express Edition Release 18.0.0.0.0 - Production Таблица очереди - источника: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Сама очередь-источник: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. Таблица очереди-приемника: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Очередь-приемник: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. У очереди-источника определен подписчик: Код: plsql 1. 2. 3. 4. 5. И у очереди-источника задан джоб на propagation: Код: plsql 1. 2. 3. 4. Отметим здесь, что у подписчика очереди - источника имя выставлено в NULL. Зашедуленный джоб на propagation просто указывает в качестве адресата всю очередь, без конкретного подписчика. У очереди-приемника зарегистрирован один подписчик (хотя бы один должен быть, иначе джоб свалится с ошибкой): Код: plsql 1. 2. 3. 4. При отсутствии recipients в enqueue-блоке очереди-источника джоб отрабатывает без вопросов. Вариант без recipients: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. При наличии recipients с адресом, оформленным согласно документации Оракл, джоб не находит адресата сообщения и тупо висит пожизненно... Вариант с recipients с адресом, оформленным согласно документации Оракл: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. При указании же recipient способом, не описанным в документации Оракл, все происходит без запинки! Вариант с recipient способом, не описанным в документации Оракл: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. В добрый путь, форумчане! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2021, 03:55 |
|
||
|
AQ propagation
|
|||
|---|---|---|---|
|
#18+
Андрей Климов При указании же recipient способом, не описанным в документации Оракл, все происходит без запинки! Вариант с recipient способом, не описанным в документации Оракл: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. Здесь точно не потеряна двойная кавычка в конце строки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2021, 15:59 |
|
||
|
AQ propagation
|
|||
|---|---|---|---|
|
#18+
SQL*Plus, Ну да, в книжку всралась очепятка ) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2021, 18:28 |
|
||
|
AQ propagation
|
|||
|---|---|---|---|
|
#18+
Андрей Климов И все-таки оно заработало!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2021, 09:47 |
|
||
|
AQ propagation
|
|||
|---|---|---|---|
|
#18+
Андрей Климов '"STERN"."RADIO_Q":"STERN1"."RECEIVER_Q" Так не интересно, типичный отправитель не должен указывать получателя в publish-subscribe - это снижает сложность интеграционных процессов. Тем более не должен указывать маршрут доставки - в предложенном сценарии проще обойтись вообще без пропагации, подписав конечного получателя прямо на очередь отправителя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2021, 16:43 |
|
||
|
|

start [/forum/topic.php?fid=52&startmsg=40053265&tid=1880363]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
65ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 10ms |
| total: | 158ms |

| 0 / 0 |
