First, let's confirm: your error MQRC_HANDLE_NOT_AVAILABLE (2017) is definitely caused by your application exhausting the maximum number of MQ handles allowed per process. Looking at your code, the root issue is unclosed MessageProducer instances—each time you call session.createProducer(), you're creating a new handle that never gets released, and over time this hits the queue manager's handle limit.

Let's address your two questions first, then fix the code:

1. Where to check the MAXHANDS (max handle) count #

Since your MQ infrastructure is managed by a dedicated team, you'll need to ask them to retrieve this configuration. Here's what they can do:

• Use the MQ command-line tool runmqsc against your queue manager, and run the command:

  DISPLAY QMGR MAXHANDS
  

  The output will show the current maximum number of handles allowed per process (this is the MAXHANDS queue manager attribute).
• Alternatively, they can use the IBM MQ Explorer GUI: navigate to your queue manager, open its properties, and look for the "Maximum Handles" (MAXHANDS) field under the "General" or "Tuning" section.

2. How to confirm the exact threshold that triggers the issue #

• The MAXHANDS value from the above step is the hard threshold—once your application's open handle count reaches this number, MQ will reject new handle requests with the 2017 error.
• To verify this when the error occurs, ask your MQ team to check the queue manager's error logs:
  • On Unix/Linux: logs are typically in /var/mqm/errors/
  • On Windows: logs are in C:\Program Files\IBM\MQ\errors
    The log entry corresponding to your error will explicitly state that the process has exceeded the MAXHANDS limit.
• They can also use the amqsrua MQ utility to monitor real-time handle usage for your application process, or set up MQ monitoring (like IBM MQ Console or Prometheus+Grafana) to track handle growth over time and confirm when it hits the threshold.

Critical Code Fix: Stop Handle Leaks #

Your current code creates a new MessageProducer every time a message is processed but never closes it. Each producer holds an MQ handle, which builds up until you hit the limit. The fix is to use try-with-resources (since MessageProducer implements AutoCloseable) to automatically close the producer after use:

public class MessageHandlerImplRCC implements SessionAwareMessageListener {
    @Override
    public void onMessage(Message message, Session session) {
        try (TextMessage imbMqReplyMessage = session.createTextMessage();
             MessageProducer messageProducerIBM = session.createProducer(message.getJMSReplyTo())) {
            
            imbMqReplyMessage.setJMSMessageID(message.getJMSMessageID());
            imbMqReplyMessage.setJMSCorrelationID(message.getJMSMessageID());
            imbMqReplyMessage.setText(dlmToDemiMappedString);
            
            messageProducerIBM.send(imbMqReplyMessage);
            message.acknowledge();
        } catch (JMSException e) {
            // Add proper error handling here: log the exception, implement retries, etc.
            // Avoid just printing the stack trace in production!
            e.printStackTrace();
        }
    }
}

This ensures that every MessageProducer (and TextMessage) is closed immediately after use, releasing the associated MQ handle. With this fix, you won't hit the MAXHANDS limit anymore, and you won't need to restart the container as a workaround.

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