Рекомендации по архитектуре по управлению вызовами UDP - PullRequest
0 голосов
/ 30 декабря 2010

Я хотел бы получить совет по этому вопросу: я использую Jbos 5.1.0, EJB3.0

У меня есть система, которая отправляет запросы через UDP на удаленные модемы, и я предполагаю дождатьсяответ от целевого модема.удаленные модемы поддерживают только UDP-вызовы, поэтому я создаю асинхронный механизм.(также, потому что я хочу запросить X модемы параллельно)

это то, что я пытаюсь сделать:

все вызовы извлекаются из базы данных, затем каждый вызов будет добавлен как сообщение в JMSQUE.скажем, я установлю X MDB'S в этой очереди, чтобы я мог работать асинхронно.теперь каждый MDB будет отправлять UDP-запрос на IP-адрес (удаленный модем), который будет проанализирован из сообщения очереди.

, поэтому в основном каждый MDB, который принимает сообщение, отправляет запрос udp на удаленный модем и[b] жду [/ b] ответа от этого модема.

[u] теперь вот БАГ: [/ u]

может произойти сценарий, в котором MDB получит ответ, но не от правильного модема (который он запросил в первую очередь),

этот плохой сценарий вызывает две неправильные вещи:

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

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

Этомеханизм, может быть, вы могли бы сказать мне, если есть какой-либо дизайн pattren, или любое другое эффективное решение для этой проблемы?

Спасибо,

луч.

1 Ответ

1 голос
/ 31 декабря 2010

Трудно определить точное решение, не зная подробностей, но я буду предполагать, что когда ответ получен от модема (правильного или нет), можно определить, с какого именно модема поступил запрос.

Если это так, я бы отделил обработчик запроса от обработчика ответа:

  • RequestMDB получает сообщение из [существующей] очереди, отправляет запрос и возвращает.
  • Новый компонент (назовите его ResponseHandler) обрабатывает все входящие ответы от модемов. Отправитель ответа идентифицируется (идентификатор модема?) И упаковывает ответ в сообщение JMS, которое отправляется в очередь ответов JMS.
  • Новый MDB (ResponseMDB) прослушивает очередь ответов JMS и обрабатывает ответ, для которого теперь известен идентификатор модема.

Короче говоря, разделяя проблемы, вы устраняете необходимость обработки MDB обработки ответов, чтобы иметь возможность обрабатывать ответы только от определенного модема и теперь может обрабатывать любой ответ, который находится в очереди ResponseHandler.

ResponseHandler (прослушивание ответов от модемов) должен быть многопоточным сервисом. Вы можете реализовать это как JBoss ServiceMBean с некоторой поддержкой ThreadPool. Для этого потребуется ссылка на JMS QueueConnectionFactory и очередь ответов JMS.

Чтобы обработать тайм-ауты запросов, я предлагаю вам создать запланированное задание, по одному для каждого модема, названное в честь идентификатора модема. Когда запрос отправлен, задание планируется выполнить после задержки периода ожидания. Когда ResponseHandler получает ответ, ResponseHandler ставит его в очередь и затем отменяет именованную задачу. Если период ожидания истек без отмены, запланированная задача выполняется и ставит в очередь другой запрос (перепланирует задачу тайм-аута).

Полагаю, легче сказать, чем сделать, но надеюсь, это поможет.

// Николай

...