11 Replies Latest reply on Sep 6, 2007 3:31 AM by mclu

    JMS Bridge Question

    viniciuscarvalho

      Hello there! I'm configuring a jms-bridge here. Both sides have identical configuration:

      *JBoss AS 4.2.0.GA
      *JBoss Messaging 1.4.0CR1


      On the producer side I have a queue named CMSOutboundQueue (the source)
      and on the receiver side (CMSInboundQueue). Here's my configuration:

      My remote Loader (jms-ds.xml)

      <mbean code="org.jboss.jms.jndi.JMSProviderLoader"
       name="jboss.messaging:service=JMSProviderLoader,name=CSMJMSProvider">
       <attribute name="ProviderName">CSMJMSProvider</attribute>
       <attribute name="ProviderAdapterClass">
       org.jboss.jms.jndi.JNDIProviderAdapter
       </attribute>
      
       <attribute name="FactoryRef">java:/XAConnectionFactory</attribute>
      
       <attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute>
      
       <attribute name="TopicFactoryRef">java:/XAConnectionFactory</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=192.168.0.22:1099
       </attribute>
      
       </mbean>
      


      my bridge-service
      <?xml version="1.0" encoding="UTF-8"?>
      
      <!--
       Example deployment descriptor for a message bridge
      
       $Id: messaging-secure-socket-service.xml 2737 2007-05-29 17:56:49Z timfox $
       -->
      
      <server>
      
      
       <mbean code="org.jboss.jms.server.bridge.BridgeService"
       name="jboss.messaging:service=Bridge,name=TestBridge"
       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=CSMJMSProvider</depends>
      
       <!-- The JNDI lookup for the source destination -->
       <attribute name="SourceDestinationLookup">/queue/CSMOutboundQueue</attribute>
      
       <!-- The JNDI lookup for the target destination -->
       <attribute name="TargetDestinationLookup">/queue/CSMInboundQueue</attribute>
      
       <!-- The username to use for the source connection
       <attribute name="SourceUsername">bob</attribute>
       -->
      
       <!-- The password to use for the source connection
       <attribute name="SourcePassword">cheesecake</attribute>
       -->
      
       <!-- The username to use for the target connection
       <attribute name="TargetUsername">mary</attribute>
       -->
      
       <!-- The password to use for the target connection
       <attribute name="TargetPassword">hotdog</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">0</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>
      


      I guess I can skip the destinations config files since they are working ok ;)

      So I have a sessionbean sending the message to my source queue, but I get this error:

      2007-08-10 16:08:49,033 ERROR [org.jboss.messaging.util.ExceptionUtil] SessionEndpoint[m3-1nky175f-1-6fmx175f-1me2v4-110j3] send [n3-dnky175f-1-6fmx175f-1me2v4-110j3]
      javax.jms.JMSException: Failed to route Reference[48640]:RELIABLE to CSMInboundQueue
       at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:709)
       at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:343)
       at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:80)
       at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
       at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:152)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:597)
       at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
       at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
       at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
       at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
       at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
       at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:85)
       at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:165)
       at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
       at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
       at org.jboss.remoting.Client.invoke(Client.java:1550)
       at org.jboss.remoting.Client.invoke(Client.java:530)
       at org.jboss.remoting.Client.invoke(Client.java:518)
       at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:186)
       at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:157)
       at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$send$aop(ClientSessionDelegate.java:447)
       at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
       at org.jboss.jms.client.container.SessionAspect.handleSend(SessionAspect.java:631)
       at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect28.invoke(SessionAspect28.java)
       at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
       at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:91)
       at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
       at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
       at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
       at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
       at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
       at org.jboss.jms.client.delegate.ClientSessionDelegate.send(ClientSessionDelegate.java)
       at org.jboss.jms.client.container.ProducerAspect.handleSend(ProducerAspect.java:243)
       at org.jboss.aop.advice.org.jboss.jms.client.container.ProducerAspect46.invoke(ProducerAspect46.java)
       at org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java)
       at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
       at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
       at org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java)
       at org.jboss.jms.client.delegate.ClientProducerDelegate.send(ClientProducerDelegate.java)
       at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:164)
       at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:207)
       at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:145)
       at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:136)
       at org.jboss.jms.server.bridge.Bridge.sendBatch(Bridge.java:1197)
       at org.jboss.jms.server.bridge.Bridge.access$1700(Bridge.java:63)
       at org.jboss.jms.server.bridge.Bridge$SourceListener.onMessage(Bridge.java:1537)
       at org.jboss.jms.client.container.ClientConsumer.callOnMessage(ClientConsumer.java:157)
       at org.jboss.jms.client.container.ClientConsumer$ListenerRunner.run(ClientConsumer.java:941)
       at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89)
       at java.lang.Thread.run(Thread.java:619)
      


      What did I do wrong :) ?

      Best Regards

        • 1. Re: JMS Bridge Question
          viniciuscarvalho

          I've enabled TRACE level for log, and just before the error I get:

          2007-08-13 15:39:59,519 TRACE [org.jboss.jms.server.endpoint.ServerConnectionEndpoint] ConnectionEndpoint[q-5a18bb5f-1-a4h7bb5f-b090ze-110j3] processing transaction TX(15360):ACTIVE
          2007-08-13 15:39:59,519 TRACE [org.jboss.jms.server.endpoint.ServerConnectionEndpoint] ConnectionEndpoint[q-5a18bb5f-1-a4h7bb5f-b090ze-110j3] sending JBossMessage[61441]:PERSISTENT in TX(15360):ACTIVE
          2007-08-13 15:39:59,519 TRACE [org.jboss.messaging.core.impl.message.SimpleMessageStore] MemoryStore[7775961] generated Reference[61441]:RELIABLE for JBossMessage[61441]:PERSISTENT
          2007-08-13 15:39:59,519 TRACE [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] org.jboss.messaging.core.impl.postoffice.MessagingPostOffice@7aed3a routing Reference[61441]:RELIABLE with condition 'queue.CSMInboundQueue' transactionally in TX(15360):ACTIVE from cluster false
          2007-08-13 15:39:59,521 ERROR [org.jboss.messaging.util.ExceptionUtil] ConnectionEndpoint[q-5a18bb5f-1-a4h7bb5f-b090ze-110j3] sendTransaction [41-d529bb5f-1-a4h7bb5f-b090ze-110j3]
          


          I still do not have a database behind remoteserver (its running with hsqldb defaultds) I'll give this the last try.

          If I can get it running I post it here.

          Regards

          • 2. Re: JMS Bridge Question
            timfox

            There is an issue with having a remote provider for the bridge source - this has been mentioned several times in this forum.

            It will be fixed for CR2 once I find enough time to investigate.

            • 3. Re: JMS Bridge Question
              viniciuscarvalho

              Hello Tim. you mean both source and target loaders? I've seen many references on the topic, I searched quit a lot before annoying you guys :P. I'm using a target as the remote destination, so it's not implemented yet?
              If you don't mind, is there a date for the CR2?

              Best regards

              • 4. Re: JMS Bridge Question
                timfox

                In your remote jms provider, you are using the local JNDI namespace (java:) to do your lookup:

                <mbean code="org.jboss.jms.jndi.JMSProviderLoader"
                 name="jboss.messaging:service=JMSProviderLoader,name=CSMJMSProvider">
                 <attribute name="ProviderName">CSMJMSProvider</attribute>
                 <attribute name="ProviderAdapterClass">
                 org.jboss.jms.jndi.JNDIProviderAdapter
                 </attribute>
                
                 <attribute name="FactoryRef">java:/XAConnectionFactory</attribute>
                
                 <attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute>
                
                 <attribute name="TopicFactoryRef">java:/XAConnectionFactory</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=192.168.0.22:1099
                 </attribute>
                
                 </mbean>
                


                In JNDI, "java:" means "in the same VM", for a remote jms provider you don't want to do the lookup in the same VM.



                • 5. Re: JMS Bridge Question
                  mclu

                  Hi Tim!

                  I think I have the same issue.
                  I am using 2 instances of jboss 4.2.1GA with messaging 1.3

                  The source is a remote server (on my local machine).

                  <mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.messaging:service=JMSProviderLoaderRemote,name=RemoteJMSProvider_A">
                  <attribute name="ProviderName">RemoteJMSProvider_A</attribute>
                  <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
                   <!-- The combined connection factory -->
                   <attribute name="FactoryRef">XAConnectionFactory</attribute>
                   <!-- The queue connection factory -->
                   <attribute name="QueueFactoryRef">XAConnectionFactory</attribute>
                   <!-- The topic factory -->
                   <attribute name="TopicFactoryRef">XAConnectionFactory</attribute>
                   <attribute name="Properties">
                   java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
                   java.naming.factory.url.pkgs=org.jnp.interfaces
                   java.naming.provider.url=localhost:2099
                   </attribute>
                  </mbean>
                  


                  As you can see I am not using "java:" but the error is the same.
                  My error only occurs if I am using "QOS_ONCE_AND_ONLY_ONCE". Settings to 1 works.

                  On the source I get:
                  14:04:59,328 ERROR [ExceptionUtil] ConnectionEndpoint[76] sendTransaction [a42z4q-jbavvr-f5z5x8i7-1-f5z7mkao-3l]
                  javax.jms.JMSException: Failed to route Reference[8]:RELIABLE to incomingSyncRequests
                   at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:694)
                   at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoint.java:786)
                   at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:456)
                   at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
                   at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
                   at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
                   at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
                   at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.sendTransaction(ConnectionAdvised.java)
                   at org.jboss.jms.wireformat.ConnectionSendTransactionRequest.serverInvoke(ConnectionSendTransactionRequest.java:82)
                   at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:141)
                   at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
                   at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
                   at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
                   at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)
                  


                  On my destination (where bridging is installed) I get:
                  14:04:59,328 WARN [Bridge] Failed to send + acknowledge batch, closing JMS objects
                  javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't commit because the transaction is in aborted state
                   at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commit(TransactionImple.java:253)
                   at org.jboss.jms.server.bridge.Bridge.sendBatch(Bridge.java:1221)
                   at org.jboss.jms.server.bridge.Bridge.access$1600(Bridge.java:59)
                   at org.jboss.jms.server.bridge.Bridge$BatchTimeChecker.run(Bridge.java:1336)
                   at java.lang.Thread.run(Thread.java:619)
                  14:04:59,359 ERROR [ClosedInterceptor] ClosedInterceptor.ClientSessionDelegate[77]: method getXAResource() did not go through, the interceptor is CLOSED
                  14:04:59,359 WARN [Bridge] Will retry after a pause of 50000 ms
                  


                  Any Ideas?
                  If there is already a known problem... Is there a Jira Bug filed?
                  THX a lot!

                  • 6. Re: JMS Bridge Question
                    clebert.suconic

                    Can you try again with the CR2 release?

                    If this is still happening I will try to replicate thi here.

                    • 7. Re: JMS Bridge Question
                      mclu

                      I did...
                      I updated source and destination to 1.4 CR2.

                      Now this error is gone but there is a new one. Maybe only a different log?

                      Anyway... here is the log:

                      11:21:22,640 ERROR [ResourceManager] org.jboss.jms.exception.MessagingXAException: A security exception happend!
                      org.jboss.jms.exception.MessagingXAException: A security exception happend!
                       at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:641)
                       at org.jboss.jms.tx.ResourceManager.commit(ResourceManager.java:370)
                       at org.jboss.jms.tx.MessagingXAResource.commit(MessagingXAResource.java:238)
                       at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:636)
                       at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2619)
                       at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1779)
                       at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:88)
                       at com.arjuna.ats.arjuna.AtomicAction.end(AtomicAction.java:216)
                       at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commit(TransactionImple.java:238)
                       at org.jboss.jms.server.bridge.Bridge.sendBatch(Bridge.java:1238)
                       at org.jboss.jms.server.bridge.Bridge.access$1700(Bridge.java:62)
                       at org.jboss.jms.server.bridge.Bridge$BatchTimeChecker.run(Bridge.java:1489)
                       at java.lang.Thread.run(Thread.java:619)
                      Caused by: javax.jms.JMSSecurityException: User: null is not authorized to write to destination incomingSyncRequests
                       at org.jboss.jms.server.container.SecurityAspect.check(SecurityAspect.java:312)
                       at org.jboss.jms.server.container.SecurityAspect.handleSendTransaction(SecurityAspect.java:190)
                       at sun.reflect.GeneratedMethodAccessor150.invoke(Unknown Source)
                       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                       at java.lang.reflect.Method.invoke(Method.java:597)
                       at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
                       at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
                       at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
                       at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
                       at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.sendTransaction(ConnectionAdvised.java)
                       at org.jboss.jms.wireformat.ConnectionSendTransactionRequest.serverInvoke(ConnectionSendTransactionRequest.java:82)
                       at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:144)
                       at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
                       at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
                       at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
                       at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)
                       at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
                       at org.jboss.remoting.Client.invoke(Client.java:1550)
                       at org.jboss.remoting.Client.invoke(Client.java:530)
                       at org.jboss.remoting.Client.invoke(Client.java:518)
                       at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:186)
                       at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:157)
                       at org.jboss.jms.client.delegate.ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(ClientConnectionDelegate.java:221)
                       at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
                       at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:91)
                       at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
                       at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
                       at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
                       at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
                       at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
                       at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.java)
                       at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:637)
                       ... 12 more
                      11:21:22,656 WARN [Bridge] Failed to send + acknowledge batch, closing JMS objects
                      javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't commit because the transaction is in aborted state
                       at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commit(TransactionImple.java:253)
                       at org.jboss.jms.server.bridge.Bridge.sendBatch(Bridge.java:1238)
                       at org.jboss.jms.server.bridge.Bridge.access$1700(Bridge.java:62)
                       at org.jboss.jms.server.bridge.Bridge$BatchTimeChecker.run(Bridge.java:1489)
                       at java.lang.Thread.run(Thread.java:619)
                      


                      If I configure the source name and password in my bridge config the name "null" is replaced by "guest"... but still it does not work.

                      In my source log I can see:
                      2007-09-04 11:22:13,734 DEBUG [org.jboss.jms.server.security.SecurityMetadataStore] No SecurityMetadadata was available for incomingSyncRequests, using default security config

                      I wonder why the destination queue was asked here so I debugged at the Source side into the SecurityMetadataStore.getSecurityMetadata() method. I can see that while a message needs to be bridged this method is called with the source queue but also with the incomingSyncRequests which is not deployed on the source because this is the destination.

                      The SecurityMetadataStore.getSecurityMetadata() is never called on the destination side!?!

                      Suggestions:
                      - Is there a problem if I have both servers (source and destination) currently on one machine (localhost)?!?
                      - While starting up I also receive this JTA Bridge warning.
                      my tm is an instance of com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@163b85

                      Any Ideas?

                      this is my bridge config:
                      the remote loader was posted already below
                      <mbean code="org.jboss.jms.server.bridge.BridgeService"
                       name="jboss.messaging:service=Bridge,name=IncommingBridge_A"
                       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=JMSProviderLoaderRemote,name=RemoteJMSProvider_A</depends>
                      
                       <!-- The JMS provider loader that is used to lookup the target destination -->
                       <depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>
                      
                       <!-- Added to be sure that the destination-queue is loaded first-->
                       <depends>jboss.messaging.destination:service=Queue,name=incomingSyncRequests</depends>
                      
                       <!-- The JNDI lookup for the source destination -->
                       <attribute name="SourceDestinationLookup">/queue/local_incomingSyncRequests</attribute>
                      
                       <!-- The JNDI lookup for the target destination -->
                       <attribute name="TargetDestinationLookup">/queue/incomingSyncRequests</attribute>
                      
                       <!-- The username to use for the source connection
                       <attribute name="SourceUsername">bob</attribute>
                       -->
                      
                       <!-- The password to use for the source connection
                       <attribute name="SourcePassword">cheesecake</attribute>
                       -->
                      
                       <!-- The username to use for the target connection
                       <attribute name="TargetUsername">mary</attribute>
                       -->
                      
                       <!-- The password to use for the target connection
                       <attribute name="TargetPassword">hotdog</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">2</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">1000</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">50000</attribute>
                      
                       <!-- The maximum number of connection retries to make in case of failure, before giving up
                       -1 means try forever-->
                       <attribute name="MaxRetries">2</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>
                      


                      • 8. Re: JMS Bridge Question
                        mclu

                        I solved my security issues by alter my securitydomain java:/jaas/messaging.
                        Now on both sides the role guest has all rights. I added user and password for the bridges target and source and again....

                        The error previously noted is back again.

                        To answer your question:
                        I tried CR2 and it still gives me the same error! :-(

                        • 9. Re: JMS Bridge Question
                          fheldt

                          I tested the JBossMessaging Bridge (with 1.4.0.CR2) successfully here. I think you made a mistake on the configuration of the remote queue. Here's my remoteserver-jms-ds.xml

                          <?xml version="1.0" encoding="UTF-8"?>
                          <server>
                           <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>
                           <attribute name="FactoryRef">/XAConnectionFactory</attribute>
                           <attribute name="QueueFactoryRef">/XAConnectionFactory</attribute>
                           <attribute name="TopicFactoryRef">/XAConnectionFactory</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=remoteservername:1099
                           </attribute>
                           </mbean>
                          </server>
                          


                          First check that it's /XAConnectionFactory not XAConnectionFactory.

                          Second, you have to give the address of the remote jndi under java.naming.provider.url, e.g. 192.168.xxx.xxx or server.domain.org

                          I hope this helps...


                          • 10. Re: JMS Bridge Question
                            clebert.suconic

                            mclu,

                            If you read the thread back, what fheldt said is the same thing that Tim Fox said back on this thread.

                            • 11. Re: JMS Bridge Question
                              mclu

                              Hmmm.

                              Strange things happen.
                              I followed the 2 Hints and added the / and changed the provider from localhost to my local fixed IP address... ( yes, both servers are currently on one machine (for development)).

                              And surprise... It works...
                              So I am happy again!

                              The interesting part is while finding out if the ip or the / or both must be set I can NOT reproduce it. With all settings it works now.....

                              Anyway... thx for reading and support