Sun Java System Directory Server Enterprise Edition 6.0 Installation Guide

Troubleshooting Message Queue

Verify that the Sun Java System Message Queue broker is running. Issuing a telnet command to the machine and port where the Message Queue broker is running will return a list of the active Message Queue services:

# telnet localhost 7676
Connected to localhost.
Escape character is \q^]\q.
101 psw-broker 3.0.1
cluster tcp CLUSTER 32914
admin tcp ADMIN 32912
portmapper tcp PORTMAPPER 7676
ssljms tls NORMAL 32913
jms tcp NORMAL 32911
Connection closed by foreign host.

If the “ssljms tcp NORMAL” service is not listed in the output, then examine the Message Queue logs for potential problems.

[13/Mar/2003:18:17:09 CST] [B1004]:
'Starting the portmapper service using tcp
[ 7676, 50 ]
with min threads 1 and max threads of 1'

If the broker is not running, then it can be started on Solaris and on Linux by running /etc/init.d/imq start and on Windows by starting the iMQ Broker Windows service.

If you are installing Message Queue on Solaris 8, and you will be running mquinstall to install all of the packages, be sure to set IMQ_JAVAHOME before running mqinstall to ensure the software picks the correct version of Java.

If you have not yet installed Core, you do not have to set IMQ_JAVAHOME because the Identity Synchronization for Windows installation program tells the Message Queue broker which JVM to use.

Troubleshooting Broker Configuration Directory Communication

The Message Queue broker authenticates clients against the Directory Server that stores the Identity Synchronization for Windows configuration. If the broker cannot connect to this Directory Server, no clients will be able to connect to the Message Queue, and the broker log will mention some javax.naming exception, such as “ javax.naming.CommunicationException” or “javax.naming.NameNotFoundException ”.

If a javax.naming exception occurs, do the following:

Troubleshooting Broker Memory Settings

During normal operation, the Message Queue broker consumes a modest amount of memory. However, during idsync resync operations, the broker’s memory requirements increase. If the broker reaches its memory limit, undelivered messages will accumulate, the idsync resync operation will slow down dramatically (or stop completely), and Identity Synchronization for Windows might be unresponsive afterwards.

When the broker enters a low-memory state, the following messages will appear in its log:

[03/Nov/2003:14:07:51 CST] [B1089]:
In low memory condition,
Broker is attempting to f
ree up resources [03/Nov/2003:14:07:51 CST] [B1088]:
Entering Memory State [B0024]:
RED  from previous state [B0023]:
ORANGE - current memory is 1829876K,
90% of total memory

To avoid this situation:

ProcedureTo Recover from Out of Memory Problems by the Broker

  1. Verify that the broker has a backlog of undelivered messages by examining its persistent message store in the appropriate directory.

    • On Solaris: /var/imq/instances/psw-broker/filestore/message/

    • On Linux: /var/opt/sun/mq/instances/isw-broker/filestore/message/

    • On Windows: installation_root\isw- machine_name\imq\var\instances\isw-broker\filestore\message\

  2. Each file in this directory contains a single undelivered message. If there are more than 10000 files in this directory, then the broker has a backlog of messages. Otherwise, there is another problem with the broker.

  3. The message backlog is probably only log files related to an idsync resync operation and you can safely remove them.

  4. Stop the Message Queue broker as described in Starting and Stopping Services

  5. Remove all files in the persistent message store. The easiest way to remove these files is by recursively removing the message/ directory and then re-creating it.

  6. Restart the Message Queue broker.

    Follow the instructions in this section to ensure the broker does not run out of memory again.