JBoss 5 cluster come problema durevole del server JMS

Question

Ho un paio di JBoss 5.1 server cluster insieme per agire come un server JMS fault-tolerant.

li ho configurato per utilizzare MySQL datastore (con l'impostazione di clustering abilitato a mysql-persistenza-service.xml), ho creato un tema mbean in destinazioni-service.xml definendo:

   <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>

Il mio cliente (! J2SE) si connette a questo server JMS utilizzando:

            // 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");

Quando si verifica la seguente sequenza di eventi:

1. Nodo 1 è alto, Nodo2 è giù.
2. client si connette al JMS e crea un sottoscrittore durevole sul tema "ECM-PRM-topic".
3. client si disconnette che lasciano la sottoscrizione durevole.
4. Qualche altro client pubblica messaggi sul tema "ECM-PRM-topic".
5. Node1 va giù.
6. Node2 sale.
7. Qualche altro client pubblica messaggi sul tema "ECM-PRM-topic" di nuovo.
8. client si collega di nuovo alla sottoscrizione durevole.
9. client si disconnette
10. Nodo 1 va in su.
11. client si collega di nuovo alla sottoscrizione durevole.

I messaggi pubblicati nel passaggio 4 vengono memorizzati nel database, e sono in attesa (posso vederli in MySQL) per il client di riconnettersi. (Va bene)

Il nodo avviata nella fase 6 non sa di eventuali sottoscrizioni durevoli su questo argomento. (Perché ??)

I messaggi pubblicati nel passo 7 scompaiono immediatamente. (Dal momento che non c'è è noto durevole né i client connessi)

Quando client si connette al punto 8 si crea un nuovo resistente e messaggi vengono consegnati ad essa (tuttavia ci sono ancora messaggi in MySQL).

Al punto 10 il cliente riceve tutti i messaggi dalla resistente escludendo i messaggi dalla fase 7 strega si perdono completamente.

Mi piacerebbe avere la certezza al 100% che non i messaggi possono essere persi. Tutti i messaggi devono essere conservati sul durevole e nel database MySQL fino a quando non sono consumati dal cliente.

Qualche suggerimento cosa c'è di sbagliato?

C'è un modo per configurare una sottoscrizione durevole in JBoss in file XML (prima di qualsiasi client crea un DurableSubscriber)?

Il codice client completo che uso è qui

Answer 1

Abbiamo scoperto che non è possibile per JBoss per gestire correttamente tali situazioni.

Il fatto della creazione "sottoscrizione durevole" viene trasmesso a tutti i nodi. Se uno dei nodi è giù non sarà consapevole della sottoscrizione durevole creata sull'altro. Che si traduce in perdita di dati in situazione sopra descritta.

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