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 [EMAIL PROTECTED]
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
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
