Troubleshooting two common JMS exceptions

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:

• The domains and all participating resources must have unique names. That is, you cannot have a JDBC data source, a server, or a domain with the same name as an object in another domain or the domain itself.

 

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.

 

Mots clés Technorati : jms,jta,transaction,wls 8.1,wls 10,BEA-110495,BEA-114089,JMSException,Security Interoperability,cross-domain security