У, долго придётся описывать, а вам -- читать -- потерпим...

Есть message broker, по JMS, в частности, это Appache ActiveMQ (5.7).
В нём есть очередь (queue) и топик (topic).
Мои сообщения посылаются в очередь, затем есть специальный сервис, который каждое сообщение складывает в БД.
И, поскольку есть много клиентов, которые хотят получить набор последних сообщений, чтобы не читать всё из БД, этот сервис после записи сообщения в БД (при этом сообщению выдаётся идентификатор) записывает каждое сохранённое сообщение в топик.

Топик слушается конечным клиентом, и там идея такая:
сначала из БД запросом выбирается актуальная для него выборка,

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

Таким образом происходит обновление данных у конечного клиента.

НО есть проблемы.

Вроде бы как topic славен тем, что не гарантирует доставку, и что сообщения доставляются только тем subscribers, которые в данный момент слушают топик. Т.е. -- чуть отошёл -- всё пропустил. Это конечно если подписка на топик не durable. У меня она НЕ durable. Меня это всё устраивает, мне так и надо (см. выше принцип обновления).

Проблема в том, что на практике получается ровно наоборот, топики выглядят как durable, когда клиент отсоединяется (выключаю приложение) и подсоединяется снова (запускаю), то он начинает получать не последние сообщения, а с задержкой. Причём получает их ровно по одному, синхронно с посылкой сообщения. Я написал тестовый стенд, который посылает нумерованные сообщения по одному в 4 секунды, и ровно в момент (ну плюс минус конечно) посылки стендом нового сообщения клиент получает своё сообщение, причём оно не обязательно последнее (то, которое послал стенд).

Т.е. чётко вижу следующие аномалии:

клиент (non-durable subscriber to a non-persistant topic) получает сообщения только по одному, хотя я точно знаю, что в топик должны были быть уже посланы более новые сообщения, и не в кол-ве 1 (я вижу их в БД уже записанными, так что они должны были слаться и в топик).

клиент получает старые сообщения даже после дисконекта. Я перезапускаю приложение, оно запрашивает соощения из БД, и начинает получать по одному в 4 секунды СТАРЫЕ сообщения, которые у него уже есть, а не новые (новые оно тоже получит, но позже).

Вопросы даже как-то и не сформулировать...
Что делать ?
Может я что-то глобально не так понял ?
Мне хочется добиться именно вышеописанного поведения топиков -- чтобы сообщения сразу их него исчезали, как только поступают.
Expiration time им я не ставлю.

cdtyjvNon-persistent - означает лишь то, что сообщения не переживут рестарт брокера. Никто не говорит вам, что они не будут доставлены клиентам, которые подключились позднее.

Я это знаю. Указал для полноты картины.

cdtyjv,

Что надо сделать, чтобы сообщения по поступлению в топик посылались всем активным подписчикам,
и после этого тут же удалялись ?

В общем, был сам дурак.

Посылал сообщение в топик через транзакционную сессию, которую открывал для чтения сообщений из очереди.
Сессия была транзакционная, а .commit() я не ставил.
Как только сделал отдельную сессию, нетранзакционную (с автоACKNOLAGE) -- всё встало на свои места.
(ну или можно было бы .commit()) вставить в нужное место.