7 Replies Latest reply on Jan 9, 2010 3:38 PM by mskorupka

    Problem with bridge reconnecting to remote queue.

      Hi,

       

      I know that's my fifth thread here about JBoss, but currently I'm (with my friend, to be exact) working on my first fight project using this server and there is much to learn. We really check all the wikis, googles and documentations before asking here. So let's get back to the problem...

       

      We have a problem with bridge passing messages from JBoss 5.1 (producer) to clustered remote JBoss 5.1 (one node works at the moment of described test). We have a cluster working and then producer starts. Bridge connects to clustered queue. Then cluster dies, so bridge becomes disconnected. It tries to connect 10 times, but after that it says that limit of reconnect attempts was exceeded and doesn't try any more. Even when cluster's node gets up, there's no more attempts.

       

      We started to look for configuration file that sets this limit. File for bridge seemed to be the place we've been looking for, but it has "-1" in "MaxRetries" attribute (see below). When we use the same configuration without cluster as the receiver, we don't see that behaviour after 10 attempts. Do you have any clue about possible cause of this? We searched for occurences of ">10<" string in all files for used server's configuration, we changed those one by one, but nothing has changed with what is described here.

       

       

      DETAILS OF CONFIGURATION:

      We create that bridge by creating ecmprm-bridge-service.xml in SERVER_PATH/deploy/default-producer/deploy/messaging:

       

      <?xml version="1.0" encoding="UTF-8"?>
      <server>
          <mbean code="org.jboss.jms.server.bridge.BridgeService"
                name="jboss.messaging:service=Bridge,name=ECM-PRM-Bridge"
                xmbean-dd="xmdesc/Bridge-xmbean.xml">
               
            <!-- The JMS provider loader that is used to lookup the source destination -->  
            <depends optional-attribute-name="SourceProviderLoader">
                jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>
           
            <!-- The JMS provider loader that is used to lookup the target destination -->
            <depends optional-attribute-name="TargetProviderLoader">
                jboss.messaging:service=JMSProviderLoader,name=RemoteJMSProvider</depends>   
           
            <!-- The JNDI lookup for the source destination -->
            <attribute name="SourceDestinationLookup">/queue/ECM-PRM-BridgedQueue</attribute>
           
            <!-- The JNDI lookup for the target destination -->
            <attribute name="TargetDestinationLookup">/queue/ECM-PRM-Queue</attribute>
           
            <!-- The username to use for the source connection       -->
            <attribute name="SourceUsername">ecm-user</attribute>
           
            <!-- The password to use for the source connection      -->
            <attribute name="SourcePassword">ecm-user</attribute>

       

            <!-- The username to use for the target connection      -->
            <attribute name="TargetUsername">ecm-user</attribute>
           
            <!-- The password to use for the target connection      -->
            <attribute name="TargetPassword">ecm-user</attribute>
           
            <!-- Optional: The Quality Of Service mode to use, one of:
                 QOS_AT_MOST_ONCE = 0;
                 QOS_DUPLICATES_OK = 1;
                 QOS_ONCE_AND_ONLY_ONCE = 2; -->
            <attribute name="QualityOfServiceMode">1</attribute>
           
            <!-- JMS selector to use for consuming messages from the source
            <attribute name="Selector">specify jms selector here</attribute>
            -->
           
            <!-- The maximum number of messages to consume from the source
                before sending to the target -->
            <attribute name="MaxBatchSize">5</attribute>    
           
            <!-- The maximum time to wait (in ms) before sending a batch to the target
                even if MaxBatchSize is not exceeded.
                 -1 means wait forever -->  
            <attribute name="MaxBatchTime">-1</attribute>
           
            <!-- If consuming from a durable subscription this is the subscription name
            <attribute name="SubName">mysub</attribute>
            -->
           
            <!-- If consuming from a durable subscription this is the client ID to use
            <attribute name="ClientID">myClientID</attribute>
            -->
           
            <!-- The number of ms to wait between connection retrues in the event connections
                to source or target fail -->
            <attribute name="FailureRetryInterval">5000</attribute>     
           
            <!-- The maximum number of connection retries to make in case of failure,
                before giving up -1 means try forever-->
            <attribute name="MaxRetries">-1</attribute>

       

            <!-- If true then the message id of the message before bridging will be added
                as a header to the message so it is available to the receiver. Can then be
                sent as correlation id to correlate in a distributed request-response -->
            <attribute name="AddMessageIDInHeader">false</attribute>
           
          </mbean>
      </server>

       

      RemoteJMSProvider is defined in jms-ds.xml:

       

        <!-- Remote JMS provider -->
        <mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.messaging:service=JMSProviderLoader,name=RemoteJMSProvider">
          <attribute name="ProviderName">RemoteJMSProvider</attribute>
          <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
          <!-- The connection factory -->
          <attribute name="FactoryRef">/ClusteredXAConnectionFactory</attribute>
          <!-- The queue connection factory -->
          <attribute name="QueueFactoryRef">/ClusteredXAConnectionFactory</attribute>
          <!-- The topic factory -->
          <attribute name="TopicFactoryRef">/ClusteredXAConnectionFactory</attribute>
          <!-- Connect to JNDI on the host "the-remote-host-name" port 1099-->
          <attribute name="Properties">
            java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
            java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
            java.naming.provider.url=jnp://192.168.107.51:1099,192.168.107.68:1099
          </attribute>
        </mbean>

        • 1. Re: Problem with bridge reconnecting to remote queue.
          gaohoward

          From the case you described, I think this is probably because the max failover attempts has been reached.

           

          What did the bridge behave when you send more messages after this has happened?

           

          Howard

          • 2. Re: Problem with bridge reconnecting to remote queue.

            Hi once again,

             

            You might be right, because after those 10 tries, this message appears:

             

            2010-01-04 10:31:38,560 ERROR [org.jboss.jms.client.FailoverCommandCenter] (Thread-29) Failover failed
            javax.jms.JMSException: Maximum number of failover attempts exceeded. Cannot find a server to failover onto.

             

            And about your question, producer keeps sending those messages after cluster dies. When I restart that producer (restart ear in admin-console), bridge doesn't try to send messages from local queue.

             

            I forgot to add that producer uses newest EJB3 plugin (JBoss EJB3 Plugin 1.0.19) and that producer is EJB3 JBoss @Service that uses timer for sending messages with 1 second interval.

             

            Each one of those 10 attempts is with following exception:

             

            2010-01-04 13:30:01,421 WARN  [org.jboss.jms.client.container.ClusteringAspect] (Thread-30) Exception captured on createConnection... hopping to a new connection factory on server (1)
            org.jboss.jms.exception.MessagingNetworkFailureException

             

            Another thing is that there's weird output at producer's side when it starts:

             

            2010-01-04 10:28:03,326 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper] (main) supportsFailover attribute is true on connection factory: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory but post office is non clustered. So connection factory will *not* support failover
            2010-01-04 10:28:03,326 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper] (main) supportsLoadBalancing attribute is true on connection factory: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory but post office is non clustered. So connection factory will *not* support load balancing

             

            I don't know if this is relevant to my problem.

            • 3. Re: Problem with bridge reconnecting to remote queue.
              gaohoward

              No, the warnings on producer side is not relevant. The bridge is connecting to the clustered server. However you can look up at the cluster server logs for similar warnings. I guess your cluster is not correctly set up. If two node form a cluster, if one node is down, the connection will be failed over to the other node. In your case the failover failed, it means either both of the two nodes are shutdown at the same time or the cluster is not correctly set up.

              • 4. Re: Problem with bridge reconnecting to remote queue.

                Thanks for this, I can't test it right now, but I'll do this in couple hours. In the meantime, I'll try to describe something just to be sure if everything is correct during the tests.

                 

                I want to form a two-node cluster, but I'm starting with just one node. At this moment I start my producer that connects to that one node. Is this OK? I know that failover should happen when there were two nodes and one of them was stopped. I know that there's little posssibility of two nodes not working at the same time, but there's a chance and I don't want to restart producer when this happens.

                • 5. Re: Problem with bridge reconnecting to remote queue.

                  I'll also try to post more details about configuration of cluster.This won't be short.

                   


                  We use We use MySQL 5.1.41 for persistence, so we've changed hsqldb-ds.xml and hsqldb-persistence-service.xml files with those from docs directory. MySQL works on 192.168.107.51:3306. We've changed PostOffice to be in Clustered mode and to have FailoverOnNodeLeave to true. We've also added two users and two roles for them (ecm-user with ecm-role that will be used for writing to clustered queue and prm-user with prm-role to be used for reading from clustered queue).

                   


                  hsqldb-ds.xm:

                   

                  <datasources>
                    <local-tx-datasource>
                      <jndi-name>DefaultDS</jndi-name>
                      <connection-url>jdbc:mysql://192.168.107.51:3306/cluster</connection-url>
                      <driver-class>com.mysql.jdbc.Driver</driver-class>
                      <user-name>cluster</user-name>
                      <password>cluster</password>
                      <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
                      <!-- should only be used on drivers after 3.22.1 with "ping" support
                      <valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker</valid-connection-checker-class-name>
                      -->
                      <!-- sql to call when connection is created
                      <new-connection-sql>some arbitrary sql</new-connection-sql>
                        -->
                      <!-- sql to call on an existing pooled connection when it is obtained from pool - MySQLValidConnectionChecker is preferred for newer drivers
                      <check-valid-connection-sql>some arbitrary sql</check-valid-connection-sql>
                        -->

                   

                      <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
                      <metadata>
                         <type-mapping>mySQL</type-mapping>
                      </metadata>
                    </local-tx-datasource>
                  </datasources>

                   

                  hsqldb-persistence-service.xml:

                   


                  <server>

                   


                     <!-- Persistence Manager MBean configuration
                         ======================================== -->

                   


                     <mbean code="org.jboss.messaging.core.jmx.JDBCPersistenceManagerService"
                        name="jboss.messaging:service=PersistenceManager"
                        xmbean-dd="xmdesc/JDBCPersistenceManager-xmbean.xml">

                   


                        <depends>jboss.jca:service=DataSourceBinding,name=DefaultDS</depends>

                   


                        <depends optional-attribute-name="TransactionManager">jboss:service=TransactionManager</depends>

                   


                        <!-- The datasource to use for the persistence manager -->

                   


                        <attribute name="DataSource">java:/DefaultDS</attribute>

                   


                        <!-- If true will attempt to create tables and indexes on every start-up -->

                   


                        <attribute name="CreateTablesOnStartup">true</attribute>

                   


                        <!-- If true then we will automatically detect and reject duplicate messages sent during failover -->

                   


                        <attribute name="DetectDuplicates">true</attribute>

                   


                        <!-- The size of the id cache to use when detecting duplicate messages -->

                   


                        <attribute name="IDCacheSize">500</attribute>

                   


                        <attribute name="SqlProperties"><![CDATA[
                     CREATE_DUAL=CREATE TABLE JBM_DUAL (DUMMY INTEGER, PRIMARY KEY (DUMMY)) ENGINE = INNODB
                     CREATE_MESSAGE_REFERENCE=CREATE TABLE JBM_MSG_REF (MESSAGE_ID BIGINT, CHANNEL_ID BIGINT, TRANSACTION_ID BIGINT, STATE CHAR(1), ORD BIGINT, PAGE_ORD BIGINT, DELIVERY_COUNT INTEGER, SCHED_DELIVERY BIGINT, PRIMARY KEY(MESSAGE_ID, CHANNEL_ID)) ENGINE = INNODB
                     CREATE_IDX_MESSAGE_REF_TX=CREATE INDEX JBM_MSG_REF_TX ON JBM_MSG_REF (TRANSACTION_ID, STATE)
                     CREATE_MESSAGE=CREATE TABLE JBM_MSG (MESSAGE_ID BIGINT, RELIABLE CHAR(1), EXPIRATION BIGINT, TIMESTAMP BIGINT, PRIORITY TINYINT, TYPE TINYINT, HEADERS MEDIUMBLOB, PAYLOAD LONGBLOB, PRIMARY KEY (MESSAGE_ID)) ENGINE = INNODB
                     CREATE_TRANSACTION=CREATE TABLE JBM_TX (NODE_ID INTEGER, TRANSACTION_ID BIGINT, BRANCH_QUAL VARBINARY(254), FORMAT_ID INTEGER, GLOBAL_TXID VARBINARY(254), PRIMARY KEY (TRANSACTION_ID)) ENGINE = INNODB
                     CREATE_COUNTER=CREATE TABLE JBM_COUNTER (NAME VARCHAR(255), NEXT_ID BIGINT, PRIMARY KEY(NAME)) ENGINE = INNODB
                     CREATE_ID_CACHE=CREATE TABLE JBM_ID_CACHE (NODE_ID INTEGER, CNTR INTEGER, JBM_ID VARCHAR(255), PRIMARY KEY(NODE_ID, CNTR)) ENGINE = INNODB
                     INSERT_DUAL=INSERT INTO JBM_DUAL VALUES (1)
                     CHECK_DUAL=SELECT 1 FROM JBM_DUAL
                     INSERT_MESSAGE_REF=INSERT INTO JBM_MSG_REF (CHANNEL_ID, MESSAGE_ID, TRANSACTION_ID, STATE, ORD, PAGE_ORD, DELIVERY_COUNT, SCHED_DELIVERY) VALUES (?, ?, ?, ?, ?, ?, ?, ?)
                     DELETE_MESSAGE_REF=DELETE FROM JBM_MSG_REF WHERE MESSAGE_ID=? AND CHANNEL_ID=? AND STATE='C'
                     UPDATE_MESSAGE_REF=UPDATE JBM_MSG_REF SET TRANSACTION_ID=?, STATE='-' WHERE MESSAGE_ID=? AND CHANNEL_ID=? AND STATE='C'
                     UPDATE_PAGE_ORDER=UPDATE JBM_MSG_REF SET PAGE_ORD = ? WHERE MESSAGE_ID=? AND CHANNEL_ID=?
                     COMMIT_MESSAGE_REF1=UPDATE JBM_MSG_REF SET STATE='C', TRANSACTION_ID = NULL WHERE TRANSACTION_ID=? AND STATE='+'
                     COMMIT_MESSAGE_REF2=DELETE FROM JBM_MSG_REF WHERE TRANSACTION_ID=? AND STATE='-'
                     ROLLBACK_MESSAGE_REF1=DELETE FROM JBM_MSG_REF WHERE TRANSACTION_ID=? AND STATE='+'
                     ROLLBACK_MESSAGE_REF2=UPDATE JBM_MSG_REF SET STATE='C', TRANSACTION_ID = NULL WHERE TRANSACTION_ID=? AND STATE='-'
                     LOAD_PAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, PAGE_ORD, SCHED_DELIVERY FROM JBM_MSG_REF WHERE CHANNEL_ID = ? AND PAGE_ORD BETWEEN ? AND ? ORDER BY PAGE_ORD
                     LOAD_UNPAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? AND PAGE_ORD IS NULL ORDER BY ORD
                     LOAD_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? ORDER BY ORD
                     UPDATE_REFS_NOT_PAGED=UPDATE JBM_MSG_REF SET PAGE_ORD = NULL WHERE PAGE_ORD BETWEEN ? AND ? AND CHANNEL_ID=?
                     SELECT_MIN_MAX_PAGE_ORD=SELECT MIN(PAGE_ORD), MAX(PAGE_ORD) FROM JBM_MSG_REF WHERE CHANNEL_ID = ?
                     UPDATE_DELIVERY_COUNT=UPDATE JBM_MSG_REF SET DELIVERY_COUNT = ? WHERE MESSAGE_ID = ? AND CHANNEL_ID = ?
                     UPDATE_CHANNEL_ID=UPDATE JBM_MSG_REF SET CHANNEL_ID = ? WHERE CHANNEL_ID = ?
                     MOVE_REFERENCE=UPDATE JBM_MSG_REF SET CHANNEL_ID = ? WHERE MESSAGE_ID = ? AND CHANNEL_ID = ?
                     LOAD_MESSAGES=SELECT MESSAGE_ID, RELIABLE, EXPIRATION, TIMESTAMP, PRIORITY, HEADERS, PAYLOAD, TYPE FROM JBM_MSG
                     INSERT_MESSAGE=INSERT INTO JBM_MSG (MESSAGE_ID, RELIABLE, EXPIRATION, TIMESTAMP, PRIORITY, TYPE, HEADERS, PAYLOAD) VALUES (?, ?, ?, ?, ?, ?, ?, ?)
                     INSERT_MESSAGE_CONDITIONAL=INSERT INTO JBM_MSG (MESSAGE_ID, RELIABLE, EXPIRATION, TIMESTAMP, PRIORITY, TYPE) SELECT ?, ?, ?, ?, ?, ? FROM JBM_DUAL WHERE NOT EXISTS (SELECT MESSAGE_ID FROM JBM_MSG WHERE MESSAGE_ID = ?)
                     UPDATE_MESSAGE_4CONDITIONAL=UPDATE JBM_MSG SET HEADERS=?, PAYLOAD=? WHERE MESSAGE_ID=?
                     INSERT_MESSAGE_CONDITIONAL_FULL=INSERT INTO JBM_MSG (MESSAGE_ID, RELIABLE, EXPIRATION, TIMESTAMP, PRIORITY, TYPE, HEADERS, PAYLOAD) SELECT ?, ?, ?, ?, ?, ?, ?, ? FROM JBM_DUAL WHERE NOT EXISTS (SELECT MESSAGE_ID FROM JBM_MSG WHERE MESSAGE_ID = ?)
                     MESSAGE_ID_COLUMN=MESSAGE_ID
                     DELETE_MESSAGE=DELETE FROM JBM_MSG WHERE MESSAGE_ID = ? AND NOT EXISTS (SELECT JBM_MSG_REF.MESSAGE_ID FROM JBM_MSG_REF WHERE JBM_MSG_REF.MESSAGE_ID = ?)
                     INSERT_TRANSACTION=INSERT INTO JBM_TX (NODE_ID, TRANSACTION_ID, BRANCH_QUAL, FORMAT_ID, GLOBAL_TXID) VALUES(?, ?, ?, ?, ?)
                     DELETE_TRANSACTION=DELETE FROM JBM_TX WHERE NODE_ID = ? AND TRANSACTION_ID = ?
                     SELECT_PREPARED_TRANSACTIONS=SELECT TRANSACTION_ID, BRANCH_QUAL, FORMAT_ID, GLOBAL_TXID FROM JBM_TX WHERE NODE_ID = ?
                     SELECT_MESSAGE_ID_FOR_REF=SELECT MESSAGE_ID, CHANNEL_ID FROM JBM_MSG_REF WHERE TRANSACTION_ID = ? AND STATE = '+' ORDER BY ORD
                     SELECT_MESSAGE_ID_FOR_ACK=SELECT MESSAGE_ID, CHANNEL_ID FROM JBM_MSG_REF WHERE TRANSACTION_ID = ? AND STATE = '-' ORDER BY ORD
                     UPDATE_COUNTER=UPDATE JBM_COUNTER SET NEXT_ID = ? WHERE NAME=?
                     SELECT_COUNTER=SELECT NEXT_ID FROM JBM_COUNTER WHERE NAME=? FOR UPDATE
                     INSERT_COUNTER=INSERT INTO JBM_COUNTER (NAME, NEXT_ID) VALUES (?, ?)
                     SELECT_ALL_CHANNELS=SELECT DISTINCT(CHANNEL_ID) FROM JBM_MSG_REF
                     UPDATE_TX=UPDATE JBM_TX SET NODE_ID=? WHERE NODE_ID=?
                     UPDATE_ID_IN_CACHE=UPDATE JBM_ID_CACHE SET JBM_ID = ? WHERE NODE_ID = ? AND CNTR = ?
                     INSERT_ID_IN_CACHE=INSERT INTO JBM_ID_CACHE (NODE_ID, CNTR, JBM_ID) VALUES (?, ?, ?)
                     LOAD_ID_CACHE=SELECT CNTR, JBM_ID FROM JBM_ID_CACHE WHERE NODE_ID = ?
                        ]]></attribute>

                   


                        <!-- The maximum number of parameters to include in a prepared statement -->

                   


                        <attribute name="MaxParams">500</attribute>

                   


                     </mbean>

                   


                     <!-- Messaging Post Office MBean configuration
                          ========================================= -->

                   


                     <mbean code="org.jboss.messaging.core.jmx.MessagingPostOfficeService"
                        name="jboss.messaging:service=PostOffice"
                        xmbean-dd="xmdesc/MessagingPostOffice-xmbean.xml">

                   


                        <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>

                   


                        <depends>jboss.jca:service=DataSourceBinding,name=DefaultDS</depends>

                   


                        <depends optional-attribute-name="TransactionManager">jboss:service=TransactionManager</depends>

                   


                        <!-- The name of the post office -->

                   


                        <attribute name="PostOfficeName">JMS post office</attribute>

                   


                        <!-- The datasource used by the post office to access it's binding information -->

                   


                        <attribute name="DataSource">java:/DefaultDS</attribute>

                   


                        <!-- If true will attempt to create tables and indexes on every start-up -->

                   


                        <attribute name="CreateTablesOnStartup">true</attribute>

                   


                        <attribute name="SqlProperties"><![CDATA[
                  CREATE_POSTOFFICE_TABLE=CREATE TABLE JBM_POSTOFFICE (POSTOFFICE_NAME VARCHAR(255), NODE_ID INTEGER, QUEUE_NAME VARCHAR(255), COND VARCHAR(1023), SELECTOR VARCHAR(1023), CHANNEL_ID BIGINT, CLUSTERED CHAR(1), ALL_NODES CHAR(1), PRIMARY KEY(POSTOFFICE_NAME, NODE_ID, QUEUE_NAME)) ENGINE = INNODB
                  INSERT_BINDING=INSERT INTO JBM_POSTOFFICE (POSTOFFICE_NAME, NODE_ID, QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, CLUSTERED, ALL_NODES) VALUES (?, ?, ?, ?, ?, ?, ?, ?)
                  DELETE_BINDING=DELETE FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME=? AND NODE_ID=? AND QUEUE_NAME=?
                  LOAD_BINDINGS=SELECT QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, CLUSTERED, ALL_NODES FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME=? AND NODE_ID=?
                        ]]></attribute>

                   


                        <!-- This post office is non clustered. If you want a clustered post office then set to true -->
                      
                        <attribute name="Clustered">true</attribute>

                   


                        <!-- All the remaining properties only have to be specified if the post office is clustered.
                             You can safely comment them out if your post office is non clustered -->

                   


                        <!-- The JGroups group name that the post office will use -->

                   


                        <attribute name="GroupName">${jboss.messaging.groupname:MessagingPostOffice}</attribute>

                   


                        <!-- Max time to wait for state to arrive when the post office joins the cluster -->

                   


                        <attribute name="StateTimeout">30000</attribute>

                   


                        <!-- Max time to wait for a synchronous call to node members using the MessageDispatcher -->

                   


                        <attribute name="CastTimeout">30000</attribute>
                      
                        <!-- Set this to true if you want failover of connections to occur when a node is shut down -->
                      
                        <attribute name="FailoverOnNodeLeave">true</attribute>

                   


                        <depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends>
                        <attribute name="ControlChannelName">jbm-control</attribute>
                        <attribute name="DataChannelName">jbm-data</attribute>
                        <attribute name="ChannelPartitionName">${jboss.partition.name:DefaultPartition}-JMS</attribute>
                     </mbean>

                   


                     <!-- Messaging JMS User Manager MBean config
                          ======================================= -->

                   


                     <mbean code="org.jboss.jms.server.plugin.JDBCJMSUserManagerService"
                        name="jboss.messaging:service=JMSUserManager"
                        xmbean-dd="xmdesc/JMSUserManager-xmbean.xml">
                        <depends>jboss.jca:service=DataSourceBinding,name=DefaultDS</depends>
                        <depends optional-attribute-name="TransactionManager">jboss:service=TransactionManager</depends>
                        <attribute name="DataSource">java:/DefaultDS</attribute>
                        <attribute name="CreateTablesOnStartup">true</attribute>
                        <attribute name="SqlProperties"><![CDATA[
                  CREATE_USER_TABLE=CREATE TABLE JBM_USER (USER_ID VARCHAR(32) NOT NULL, PASSWD VARCHAR(32) NOT NULL, CLIENTID VARCHAR(128), PRIMARY KEY(USER_ID)) ENGINE = INNODB
                  CREATE_ROLE_TABLE=CREATE TABLE JBM_ROLE (ROLE_ID VARCHAR(32) NOT NULL, USER_ID VARCHAR(32) NOT NULL, PRIMARY KEY(USER_ID, ROLE_ID)) ENGINE = INNODB
                  SELECT_PRECONF_CLIENTID=SELECT CLIENTID FROM JBM_USER WHERE USER_ID=?
                  POPULATE.TABLES.1  = INSERT INTO JBM_USER (USER_ID, PASSWD) VALUES ('guest', 'guest')
                  POPULATE.TABLES.2  = INSERT INTO JBM_USER (USER_ID, PASSWD) VALUES ('j2ee', 'j2ee')
                  POPULATE.TABLES.3  = INSERT INTO JBM_USER (USER_ID, PASSWD, CLIENTID) VALUES ('john', 'needle', 'DurableSubscriberExample')
                  POPULATE.TABLES.4  = INSERT INTO JBM_USER (USER_ID, PASSWD) VALUES ('nobody', 'nobody')
                  POPULATE.TABLES.5  = INSERT INTO JBM_USER (USER_ID, PASSWD) VALUES ('dynsub', 'dynsub')
                  POPULATE.TABLES.6  = INSERT INTO JBM_ROLE (ROLE_ID, USER_ID) VALUES ('guest','guest')
                  POPULATE.TABLES.7  = INSERT INTO JBM_ROLE (ROLE_ID, USER_ID) VALUES ('j2ee','guest')
                  POPULATE.TABLES.8  = INSERT INTO JBM_ROLE (ROLE_ID, USER_ID) VALUES ('john','guest')
                  POPULATE.TABLES.9  = INSERT INTO JBM_ROLE (ROLE_ID, USER_ID) VALUES ('subscriber','john')
                  POPULATE.TABLES.10 = INSERT INTO JBM_ROLE (ROLE_ID, USER_ID) VALUES ('publisher','john')
                  POPULATE.TABLES.11 = INSERT INTO JBM_ROLE (ROLE_ID, USER_ID) VALUES ('publisher','dynsub')
                  POPULATE.TABLES.12 = INSERT INTO JBM_ROLE (ROLE_ID, USER_ID) VALUES ('durpublisher','john')
                  POPULATE.TABLES.13 = INSERT INTO JBM_ROLE (ROLE_ID, USER_ID) VALUES ('durpublisher','dynsub')
                  POPULATE.TABLES.14 = INSERT INTO JBM_ROLE (ROLE_ID, USER_ID) VALUES ('noacc','nobody')
                  POPULATE.TABLES.15 = INSERT INTO JBM_USER (USER_ID, PASSWD) VALUES ('prm-user', 'prm-user')
                  POPULATE.TABLES.16 = INSERT INTO JBM_USER (USER_ID, PASSWD) VALUES ('ecm-user', 'ecm-user')
                  POPULATE.TABLES.17 = INSERT INTO JBM_ROLE (ROLE_ID, USER_ID) VALUES ('prm-role','prm-user')
                  POPULATE.TABLES.18 = INSERT INTO JBM_ROLE (ROLE_ID, USER_ID) VALUES ('ecm-role','ecm-user')

                   


                        ]]></attribute>
                     </mbean>

                   


                  </server>

                   


                  We've also changed secondaryBindPort inremoting-bisocket-service.xml because we want our cluster to work behind a firewall.

                   


                  <!-- Use these parameters to specify values for binding and connecting control connections to
                       work with your firewall/NAT configuration -->
                  <attribute name="secondaryBindPort">4458</attribute>
                  <!--                       
                  <attribute name="secondaryConnectPort">4459</attribute>
                  -->

                   


                  We also want to have a clustered queue, so destinations-service.xml now has this part:

                   


                  <!-- Clustered queue for Reverse Invoke mechanism between ECM and PRM. -->
                    <mbean code="org.jboss.jms.server.destination.QueueService" name="jboss.messaging.destination:service=Queue,name=ECM-PRM-Queue" xmbean-dd="xmdesc/Queue-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" />
                        </security>
                      </attribute>
                    </mbean>

                   

                  One thing came to my mind - is there any option that can be changed to set max failover attempts made by producer?

                  • 6. Re: Problem with bridge reconnecting to remote queue.
                    • 7. Re: Problem with bridge reconnecting to remote queue.

                      Now I'm pretty sure that this case is about misconfiguration or that JBoss isn't for us. First case sounds more probable. I upgraded JBoss Messaging to 1.4.6 and JBoss Remoting to 2.5.2SP1 (2.5.2 is needed by JBM 1.4.6, but I think SP1 fits better because it's newer and fixes many bugs). Above mentioned problem still exists.

                       

                      Probably there's something I don't know about how JBoss works. For me, failover happens when node dies. Then the second node gets all the traffic in case of 2 nodes working simultaneusly. But what happens if second node dies also? Obviously the cluster can't get any messages in that case, but I thought that bridge will keep trying to reconnect. At least I think that this should be in configuration somewhere. There should be a way to set that it should keep trying forever.