Well, rather than wait for a JBOSS that supports this, or workaround suggestions from the Chief Scientist, we had to solve this problem *today*, and here is what we came up with that works:
JBOSS JMS Failover The TDX is designed to use JBOSS JMS services when deployed under JBOSS. We configure this JMS service to use the TDX database for it?s state and persistence management. The TDX deployment declares a JNDI DataSource definition named ?jdbc/EpokDB? for the primary database TDX looks for and uses upon startup. This same JNDI DataSource name is referenced in the JBOSS JMS configuration found in these three files: /usr/local/jboss/server/EpokTDX/conf/login-config.xml /usr/local/jboss/server/EpokTDX/server/deploy-hasingleton/jms/mysql-jdbc2-service.xml /usr/local/jboss/server/EpokTDX/server/deploy-hasingleton/jms/mysql-jdbc-state-service.xml This configuration above represents the State Manager and Persistence Manager of the JMS service, along with Security Domain Manager of the JBOSS message queuing. When the TDX uses the JMS services, tables are created and maintained on the TDX primary database. So what happens when the primary database goes down? The TDX provides functionality to failover activity to a designated slave database defined with JNDI DataSource named ?jdbc/EpokDBFailover?. But how do you get JBOSS JMS services to failover? Currently, JBOSS 4.0.1 does not offer any failover capability for it?s JMS services. There are upcoming feature requests, but no existing functionality. Here is the solution we have implemented in our TDX to coordinate JBOSS JMS failover: TDX JMS client detects JBOSS JMS service failures and initiates failover processing for JBOSS JMS services. This procedure is to: 1. Shutdown all existing JMS Queue Listeners 2. Get handles to follow JMX Services: a. jboss.mq:service=StateManager b. jboss.mq:service=PersistenceManager c. jboss.security:service=XMLLoginConfig 3. We issue a ?stop? to all three services. 4. We change the ?ConnectionManager? attribute in the State and Persistence Managers to now use the JNDI DataSource named ?jdbc/EpokDBFailover? 5. We call out to a shell script that changes ?jdbc/EpokDB? to ?jdbc/EpokDBFailover? in the three .xml configuration files listed above. 6. We issue a ?start? to the three JMX services, essentially restarting them with new configuration parameters. 7. TDX JMS client re-resolves JMS ConnectionManager and Queue, and reestablishes new JMS Queue Listeners on them. That completes the JBOSS JMS Failover processing. The JBOSS JMS services are now interacting with the database defined by the JNDI DataSource named ?jdbc/EpokDBFailover?. Note in Step 5 above that we modify JBOSS .xml configuration files. You will see that we first make a backup of each file with a ?.orig? file extension into the same directory. When you restore your failed master database (which results in the JNDI DataSource named ?jdbc/EpokDB? again being the primary database), you will need to follow the regular steps outlined for restoring to a Master plus moving the ?.orig? versions of these three JBOSS configuration files back to their original names (hence enabling ?jdbc/EpokDB? as again the JNDI DataSource to use for JBOSS JMS services). IMPORTANT: The above functionality is based on the use of Epok?s decribed procedure and configuration for setting up Slave databases for database replication. What is key here is on our testing, the JMS tables created by JBOSS are replicated to the Slave just like are the regular TDX tables. Feel free to contact me if you have questions on this. [EMAIL PROTECTED] View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3870076#3870076 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3870076 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
