I've been working with a particular architecture lately.
It's composed of an application server (WebLogic Server 10), hosting webservices, an ESB (ALSB 2.5) and an EAI / BPM (WLI 8.1 SP5).
The point we are going to focus on is the JMS communication between WLI 8.1 SP5 & WLS 10.
WLI is hosting a JMS server and WLS 10, is hosting a foreign JMS Server, representing the WLI JMS Server.
First exception
From time to time, we happened to have this exception showing up in the logs :
<23 oct. 2009 21 h 50 CEST> <Error> <JTA> <BEA-114089> <User [<anonymous>] is not authorized to invoke ackPrepare on a Coordinator.>
<23 oct. 2009 21 h 54 CEST> <Error> <JTA> <BEA-110495> <User [<anonymous>] is not authorized to invoke AckRollback on a Coordinator.>
These particular errors were happening when WLS was sending a JMS message towards WLI
(which was pending since the transaction wasn't commited nor rollbacked yet) and then tried to commit the transaction.
Then we saw the first message (BEA-114089). WLS, seeing that it couldn't commit, tried to rollback but it still wasn't allowed to do such a thing.
If we take a look at the official documentation :
BEA-114089
Error: User [principal] is not authorized to invoke ackPrepare on a Coordinator.
Description
The user with identity [principal] should not be attempting to directly invoke internal methods on the Coordinator object. This might subvert transactional integrity.
Permission was denied, and the attempt was ignored.
Cause
This might be a symptom of a potential security attack, or alternately, a problem with the "system" security identity of the server.
Action
Verify that the client software is not directly invoking an internal WebLogic system object.
And
BEA-110495
Error: User [principal] is not authorized to invoke AckRollback on a Coordinator.
Description
The user with identity [principal] should not be attempting to directly invoke internal methods on the Coordinator object. This might subvert transactional integrity.
Permission was denied, and the attempt was ignored.
Cause
This might be a symptom of a potential security attack, or alternately, a problem with the "system" security identity of the server.
Action
Verify that client software is not directly invoking an internal WebLogic system object.
We see that at some point, these explanations are not very useful.
I then made a sandbox to reproduce this problem.
I played with cross-domain security and security interoperability mode.
Before playing with these two options, I strongly recommend you to read this official documentation :
- http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jms/trans.html#wp1039006
- http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jta/trxcon.html#interop
Finally, I came to the conclusion that these errors only happened when I had cross-domain security enabled (with identical credentials on both domains)
and that the security interoperabilty mode was set to "Performance" on WLS 10. (by default, this is the mode defined on WLS 8.1).
In spite of the fact that official documentation says "Every participating server must set the Security Interoperability Mode
parameter to the same value",
in my case, it worked with Performance on WLS 8.1 (WLI) and Compatibility on WLS 10 ...
Second Exception
During my tests I also encountered an annoying error :
<WSEE:13>
Error invoking fr.edf.test.transaction.SampleWebService (POJO): weblogic.jms.common.JMSException<ComponentHandler.handleRequest:115>
<WSEE:13>weblogic.jms.common.JMSException: Connection not found<ComponentHandler.handleRequest:115>
weblogic.jms.common.JMSException: Connection not found
at weblogic.jms.dispatcher.DispatcherAdapter.convertToJMSExceptionAndThrow(DispatcherAdapter.java:110)
at weblogic.jms.dispatcher.DispatcherAdapter.dispatchSync(DispatcherAdapter.java:45)
at weblogic.jms.client.JMSConnection.setupJMSSession(JMSConnection.java:499)
at weblogic.jms.client.JMSConnection.createSessionInternal(JMSConnection.java:467)
at weblogic.jms.client.JMSConnection.createQueueSession(JMSConnection.java:432)
I had to google some time to figure out that this error came from the fact that both my admin servers were named "admin".
Seen in the official doc :
Please note the following limitations for inter-domain transactions:
Well, that's it for now. I'm sure there are lots of potential other errors, but I hope that, at least, these two explanations may help some fellows out.