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

Question

У меня есть пара серверов 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-Topic".
3. Клиент отключается, оставляя гарантированную подписку.
4. Другой клиент публикует сообщения на тему "ECM-PRM-Topic".
5. Node1 выходит из строя.
6. Node2 идет вверх.
7. Другой клиент снова публикует сообщения на тему "ECM-PRM-Topic".
8. Клиент снова подключается к длительной подписке.
9. Клиент отключается
10. Узел 1 идет вверх.
11. Клиент снова подключается к длительной подписке.

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

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

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

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

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

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

Любые предложения, что не так?

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

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

Answer 1

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

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

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