EJB и Hot Sparing - PullRequest
Новая
       3

EJB и Hot Sparing

0 голосов
/ 07 ноября 2011

Я пытаюсь реализовать метод горячей замены для доступности, я имею в виду следующее:

  1. Клиент отправляет 3 одинаковых запроса, по одному на каждый сервер (у нас есть 3, фактически виртуальные машины)
  2. Каждый сервер получает запрос и обрабатывает его
  3. Когда сервер завершает работу, он проверяет связь с другими серверами, если они закончили.
  4. Если он финиширует первым, он ответит, а остальные не будут.

Так что у меня проблемы с выполнением 3 одновременных запросов. Это то, что я обычно делал бы для вызова удаленного интерфейса из сервлета 

class Servlet_JSP_or_Something extends HttpServlet
{
     doGet(HttpReq...)
     {
          @EJB
          RemoteInterfaceEJB ejbclass;
          ejbclass.doSomething()
     }
}

Но, теперь, я думаю, мне придется сделать что-то вроде этого 

class Servlet_JSP_or_Something extends HttpServlet
{
     doGet(HttpReq...)
     {
          @EJB(name="Server1")
          RemoteInterfaceEJB ejbclass;
          ejbclass.doSomething()

          @EJB(name="server2")
          RemoteInterfaceEJB ejbclass;
          ejbclass.doSomething()

          @EJB(name="server3")
          RemoteInterfaceEJB ejbclass;
          ejbclass.doSomething()
     }
}

Но я не так уверен, если это сработает. Я даже не знаю, достаточно ли @EJB (name = "...") или как задать имя для каждого отдельного ejb, работающего на разных жизненных машинах.

Так что вопрос такой: ¿Как я могу одновременно вызывать 3 одинаковых EJB-компонента из одного и того же сервлета / jsp, поскольку эти EJB-компоненты работают на разных машинах?

1 Ответ

1 голос
/ 07 ноября 2011

Вставьте запрос в очередь, попросите 3 машины прослушать очередь и дождаться результата. Если во время обработки произойдет сбой любого из них, запрос вернется в очередь и будет обработан одним из двух других. Наличие 3 систем, работающих одновременно по одному и тому же запросу, и «скачки» для достижения успеха звучат просто дико, чревато опасностью и сумасшествием.

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

Итак, я бы пошел с очередью JMS.

Addenda:

Очередь управляется кластером, затем EJB могут быть развернуты в своем собственном кластере (или просто независимые работники, они даже не должны быть EJB, они могут быть чем угодно). Все EJB подписаны на одну и ту же очередь. Каждый компонент принимает сообщение из очереди и запускается вместе с ним. Получение сообщения является транзакционным. Если по какой-либо причине происходит сбой EJB, сообщение снова становится доступным в очереди, готовое для другого EJB, чтобы принять его.

И JMS-очередь, и EJB-серверы являются избыточными, поэтому ни одна из них не является единственной точкой отказа.

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

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

Ничто из этого не решает все проблемы, возникающие при резервировании одного стека с точки зрения совместного использования состояний, условий состязания, соответствия сеанса и т. Д. И т. Д.

Для этого не существует "простой" аннотации. Использование готовой кластеризации, специфичной для вашего контейнера, возможно, настолько близко, насколько вы собираетесь.

...