Как убедиться, что текстовое сообщение было отправлено через JMS?
Я написал программу отправки текстовых сообщений через JMS с C ++ следующим.
tibems_status status = TIBEMS_OK;
status = tibemsMsgProducer_SendToDestination(
m_tProducer,
m_tDestination,
m_tMsg );
Предположим, статус == 0, это означает, что только функция сработала успешно. Это не значит, что мое текстовое сообщение было успешно отправлено
Как я могу убедиться, что мое сообщение было успешно отправлено? Должен ли я получить идентификатор или подтверждение от очереди JMS?
Решение
Это зависит от Режим доставки сообщений.
Когда PERSISTENT сообщение отправлено, tibemsMsgProducer_SendToDestination вызов будет ожидать ответа от сервера EMS с подтверждением.
Когда NON_PERSISTENT сообщение отправлено, tibemsMsgProducer_SendToDestination вызов может или не может ждать подтверждения в зависимости от того, включена ли авторизация и npsend_check_mode установка. См. EMS документы (ссылка выше) для конкретных деталей.
Наконец, когда RELIABLE_DELIVERY сообщение отправлено, tibemsMsgProducer_SendToDestination Вызов не ожидает подтверждения и завершится неудачей, только если соединение с сервером EMS потеряно.
Однако даже в ситуациях, когда отправляется подтверждение, это только подтверждение того, что сервер EMS получил сообщение. Это не подтверждает, что сообщение было получено и обработано получателем сообщения. Сообщения мониторинга EMS может использоваться для определения, было ли сообщение подтверждено потребителем.
Темы мониторинга сообщений находятся в форме $sys.monitor.<D>.<E>.<destination>, где <D> Матчи Q|q|T|t, <E> Матчи s|r|a|p|\* а также <destination> это название пункта назначения. Например, для отслеживания подтверждения сообщения для очереди с именем betermanваша программа подпишется на $sys.monitor.q.a.beterman (или же $sys.monitor.Q.a.beterman если вы хотите копию сообщения, которое было подтверждено).
сообщения мониторинга содержат много свойств, в том числе msg_id, source_name а также target_name, Вы можете использовать эту информацию, чтобы сопоставить ее с отправленным вами сообщением.
В противном случае более простой вариант — использовать tibemsMsgRequestor вместо tibemsMsgProducer, tibemsMsgRequestor_Request отправит сообщение и будет ждать ответа от получателя. В этом случае вам лучше всего использовать RELIABLE_DELIVERY а также NO_ACKNOWLEDGE удалить все сообщения подтверждения и подтверждения между производителем и сервером EMS и сервером EMS и потребителем.
Тем не менее, если вы идете вниз tibemsMsgRequestor затем вы можете также рассмотреть возможность использования вместо этого HTTP-запроса с балансировщиком нагрузки вместо сервера EMS. Архитектурно нет большой разницы между этими двумя вариантами (EMS использует постоянные соединения TCP, HTTP нет)
Producer -> EMS Server -> ConsumerA
-> ConsumerB
Client -> Load Balancer -> ServerA
-> ServerB
Но с HTTP у вас есть четкая семантика для каждого из методов. ПОЛУЧИТЬ безопасный (не изменяет состояние), PUT и DELETE идемпотент (несколько одинаковых запросов должны иметь тот же эффект, что и один запрос), а POST не идемпотентен (он вызывает изменение состояния сервера при каждом выполнении) и т. д. четко определенные коды состояния. Если вы используете tibemsMsgRequestor вам нужно создать индивидуальную семантику и статус ответа, что потребует дополнительных усилий для создания, поддержки и обучения других разработчиков в вашей команде.
Кроме того, гораздо проще найти разработчиков с навыками HTTP, чем с навыками EMS, и гораздо проще найти информацию HTTP о том, что EMS, поэтому tibemsMsgRequestor Эта опция усложнит подбор персонала и усложнит решение проблем.
Из-за этого HTTP является лучшим вариантом IMO, для запроса-ответа или для случаев, когда вы хотите убедиться, что отправленное сообщение было успешно обработано.
Другие решения
Других решений пока нет …