Spring Java客户端连接远程WebSphere MQ报2035错误求助

Hey there, let's break down why your Spring Java client is hitting that MQJE001: 2035 error while MQJExplorer connects just fine. That 2035 code translates to Not Authorized, so the issue boils down to authentication or permission differences between the two clients. Here's how to troubleshoot step by step:

1. Check Channel Authentication Rules & MCAUSER Settings #

MQJExplorer might be bypassing or using a different user ID than your Spring client, often due to channel-level overrides.

• Run this MQSC command on your MQ server to inspect the channel's auth configuration:

  DISPLAY CHANNEL(<your-channel-name>) MCAUSER CHLAUTH
  

  • If MCAUSER is set, that's the user ID MQ will use regardless of what the client sends. If MQJExplorer works but Spring doesn't, double-check if this MCAUSER has the right permissions, or if your Spring client is being blocked by CHLAUTH rules.
• List all channel authentication records to see if your client's user ID is being denied:

  DISPLAY CHLAUTH(*)
  

  Look for rules that filter by client IP, user ID, or connection type—these might be targeting your Spring client but not MQJExplorer.

2. Verify the User ID Your Spring Client is Sending #

Unlike MQJExplorer (which typically uses the OS user running the tool), your Spring client might be sending a different user ID:

• Check your Spring configuration: if you're using MQQueueConnectionFactory or JmsConnectionFactory, did you explicitly set a userID? If not, MQ will use the user associated with your JVM process.
• Enable MQ client logging to confirm the user ID in transit: add this JVM argument when running your Spring app:

  -Dcom.ibm.mq.commonservices.logName=mqclient.log
  

  Open the log file and search for lines mentioning "UserID"—this will show exactly what user is being sent to the MQ server.

3. Validate MQ-level Permissions for the User #

Even if the channel allows the user, they need explicit permissions to interact with the queue manager, queues, or topics:

• Use this MQSC command to check if the user has access to the queue manager:

  DISPLAY AUTHREC PROFILE(<your-queue-manager>) PRINCIPAL(<client-user-id>) OBJTYPE(QMGR)
  

• For specific queues you're trying to access, run:

  DISPLAY AUTHREC PROFILE(<your-queue-name>) PRINCIPAL(<client-user-id>) OBJTYPE(QUEUE)
  

  Look for AUTHLIST entries—you'll need at least CONNECT for the queue manager, and PUT/GET for queues depending on your use case.

4. Rule Out Client-side Configuration Differences #

Double-check for subtle config gaps between MQJExplorer and your Spring client:

• Are you using SSL/TLS in Spring but not in MQJExplorer? If so, ensure your keystores/truststores are correctly configured, and that the MQ channel allows SSL connections.
• Triple-check all connection parameters: host, port, channel name, queue manager name. Even a tiny typo could lead to unexpected auth failures (though MQJExplorer works, so this is less likely—but worth confirming).

5. Dig Into MQ Server Logs for Specific Details #

The client-side 2035 error is generic—your MQ server logs will tell you exactly what went wrong:

• On Unix/Linux, logs are usually in /var/mqm/qmgrs/<queue-manager-name>/errors/
• On Windows, check C:\Program Files\IBM\MQ\qmgrs\<queue-manager-name>\errors
• Look for messages starting with AMQ9776 (user not authorized for queue manager) or AMQ9777 (user not authorized for queue). These logs will specify the rejected user ID and the resource they tried to access.

Quick Summary #

Since MQJExplorer connects successfully, your core connection details (host, port, channel, queue manager) are valid. The problem is almost certainly a difference in the user ID being sent, or missing permissions for that user in MQ's auth rules. Start with verifying the user ID from your Spring client, then cross-check with channel auth rules and server logs—those will point you to the exact fix.

内容的提问来源于stack exchange，提问作者amarzeet