[jboss-user] [JBoss Messaging] - Re: JMS Bridge Question
mclu
do-not-reply at jboss.com
Tue Sep 4 05:48:45 EDT 2007
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 at 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>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080781#4080781
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080781
More information about the jboss-user
mailing list