Кластер JBoss 5 как долговременная проблема JMS-сервера - PullRequest
Новая
       79

Кластер JBoss 5 как долговременная проблема JMS-сервера

3 голосов
/ 22 декабря 2009

У меня есть пара серверов JBoss 5.1, сгруппированных вместе, чтобы действовать как отказоустойчивый сервер JMS.

Я настроил их для использования хранилища данных MySQL (с включенной настройкой кластеризации в mysql-persistence-service.xml), я создал тему mbean в dest destination-service.xml, определив: 

   <mbean code="org.jboss.jms.server.destination.TopicService" name="jboss.messaging.destination:service=Topic,name=ECM-PRM-Topic" xmbean-dd="xmdesc/Topic-xmbean.xml">
    <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
    <depends>jboss.messaging:service=PostOffice</depends>
    <attribute name="Clustered">true</attribute>
    <attribute name="SecurityConfig">
            <security>
                    <role name="ecm-role" write="true" />
                    <role name="prm-role" read="true" create="true" />
            </security>
    </attribute>

Мой клиент (J2SE!) Подключается к этим серверам JMS с помощью: 

            // Step 1. Create an initial context to perform the JNDI lookup.
        initialContext = new InitialContext(p);
        // Step 3. Perform a lookup on the Connection Factory
        ConnectionFactory cf = (ConnectionFactory)initialContext.lookup("/ClusteredConnectionFactory");
        // Step 2. Perfom a lookup on the queue
        Destination target = (Destination)initialContext.lookup("/topic/ECM-PRM-Topic");

Когда происходит следующая последовательность событий:

  1. Node1 работает, Node2 не работает.
  2. Клиент подключается к JMS и создает постоянного абонента на тему «Тема ECM-PRM».
  3. Клиент отключается, оставляя гарантированную подписку.
  4. Какой-то другой клиент публикует сообщения на тему «ECM-PRM-Topic».
  5. Узел1 отключается.
  6. Узел 2 идет вверх.
  7. Другой клиент снова публикует сообщения на тему «Тема ECM-PRM».
  8. Клиент снова подключается к долгосрочной подписке.
  9. Клиент отключается
  10. Узел 1 идет вверх.
  11. Клиент снова подключается к долгосрочной подписке.

Сообщения, опубликованные на шаге 4, хранятся в базе данных и ожидают (я вижу их в MySQL), чтобы клиент восстановил соединение. (все в порядке)

Узел, запущенный на шаге 6, не знает ни одной длительной подписки на эту тему. (Почему ??)

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

Когда клиент подключается на шаге 8, он создает новый длительный срок использования, и на него не доставляются никакие сообщения (однако в MySQL все еще есть сообщения).

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

Я бы хотел на 100% быть уверенным, что никакие сообщения не могут быть потеряны. Все сообщения должны храниться в надежной базе данных и в базе данных MySQL до тех пор, пока они не будут использованы клиентом.

Есть предложения, что не так?

Есть ли способ настроить долговременную подписку в JBoss в файлах XML (до того, как какой-либо клиент создаст DurableSubscriber)?

Полный код клиента, который я использую: ЗДЕСЬ

1 Ответ

1 голос
/ 23 декабря 2009

Мы обнаружили, что JBoss не может правильно обрабатывать такие ситуации.

Факт создания «длительной подписки» транслируется на все узлы. Если один из узлов не работает, он не будет знать о долговременной подписке, созданной на другом. Это приводит к потере данных в ситуации, описанной выше.

http://community.jboss.org/message/517448#517448

...