[ https://issues.jboss.org/browse/JBMESSAGING-1890?page=com.atlassian.jira.... ] Justin Bertram reassigned JBMESSAGING-1890: ------------------------------------------- Assignee: Yong Hao Gao -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBMESSAGING-1890?page=com.atlassian.jira.... ] Yong Hao Gao commented on JBMESSAGING-1890: ------------------------------------------- Hi Justin, I think the simple solution is to add a flag that controls whether or not to failover the transactions. Howard -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBMESSAGING-1890?page=com.atlassian.jira.... ] Yong Hao Gao commented on JBMESSAGING-1890: ------------------------------------------- If we use Clustered Connection Factory, we will have internal knowledge of the live nodes at client side. Whenever the cluster topology changes (node dies or joins) the client side will get updated. I think we can use that information to implement a 'single' recovery module so the user only need to configure one recovery provider for the whole cluster. Howard -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBMESSAGING-1890?page=com.atlassian.jira.... ] Justin Bertram commented on JBMESSAGING-1890: --------------------------------------------- Can you give org.jboss.jms.server.recovery.MessagingXAResourceRecovery2 a more descriptive name? I'm thinking something like org.jboss.jms.server.recovery.ClusteredMessagingXAResourceRecovery. What do you think? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBMESSAGING-1890?page=com.atlassian.jira.... ] Yong Hao Gao commented on JBMESSAGING-1890: ------------------------------------------- working branch: https://svn.jboss.org/repos/messaging/branches/JBMESSAGING_1890 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBMESSAGING-1890?page=com.atlassian.jira.... ] Justin Bertram commented on JBMESSAGING-1890: --------------------------------------------- Why not use a configuration like this: <mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.messaging:service=JMSProviderLoader,name=JMSProviderRemote"> <attribute name="ProviderName">ClusteredRecoveryJMSProvider</attribute> <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute> <attribute name="FactoryRef">java:/ClusteredXAConnectionFactory</attribute> <attribute name="QueueFactoryRef">java:/ClusteredXAConnectionFactory</attribute> <attribute name="TopicFactoryRef">java:/ClusteredXAConnectionFactory</attribute> <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=${jboss.bind.address}:1099 </attribute> </mbean> Since the local ClusteredXAConnectionFactory is part of cluster its stub should have all the necessary information to contact all the other nodes in the cluster, right? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBMESSAGING-1890?page=com.atlassian.jira.... ] Yong Hao Gao commented on JBMESSAGING-1890: ------------------------------------------- anyway the jms provider can be configured independently. It doesn't affect the implementation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBMESSAGING-1890?page=com.atlassian.jira.... ] Yong Hao Gao resolved JBMESSAGING-1890. --------------------------------------- Resolution: Done -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBMESSAGING-1890?page=com.atlassian.jira.... ] Yong Hao Gao commented on JBMESSAGING-1890: ------------------------------------------- Doc added: 8.1. New XA Recovery Configuration for a Cluster To be able to correctly recover the transactions across a cluster, one way is to configure a MessagingX- AReseourceRecovery for each node as mentioned above. However this method is burdensome with a large cluster. Whenever a node is added to/removed from the cluster, each XA recovery configuration file will have to be up- dated. This version of JBoss Messaging provides a new way to do so. It introduces a new recovery module called ClusteredMessagingXAResourceRecovery. With this new module, XA recovery configuration for a cluster is as easy as that for a single node. Here's an example: <properties depends="arjuna" name="jta"> <!-- Support subtransactions in the JTA layer? Default is NO. --> <property name="com.arjuna.ats.jta.supportSubtransactions" value="NO"/> <property name="com.arjuna.ats.jta.jtaTMImplementation" value="com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple"/> <property name="com.arjuna.ats.jta.jtaUTImplementation" value="com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple"/> <!-- *** Add this line to enable recovery for JMS resources using DefaultJMSProvider *** --> <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" value="org.jboss.jms.server.recovery.ClusteredMessagingXAResourceRecovery;java:/DefaultJMSProv </properties> Using the new configuration, it needs only one line for the whole cluster's XA recovery. On each scan, it will return the XAResource for each node in the cluster. If a node is removed from or added to the cluster, it can get automat- ically update so there is no need to change this configuration. Note ClusteredMessagingXAResourceRecovery works only with JBoss Messaging and requires the JMS pro- vider to provide a 'clustered connection factory' for its "FactoryRef" attribute. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira