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 Trying 127.0.0.1... 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.
If the Core was installed on Solaris, then the Message Queue broker’s log is: /var/imq/instances/psw-broker/log/log.txt
If the Core was installed on Linux, then the broker’s log is: /var/opt/sun/mq/instances/isw-broker/log/log.txt
If the Core was installed on Windows, then the broker’s log is: installation_root\isw-machine_name\imq\var\instances\isw-broker\log\log.txt
If the telnet command fails, then either the broker is not running or the wrong port was specified. Check the port number in the broker’s log. The broker’s port is specified in the following line
[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.
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:
Verify that all imq.user_repository.ldap properties in /var/imq/instances/isw-broker/props/config.properties have the correct values. If any of these is incorrect, stop the Message Queue broker, correct and save the file, and restart the broker. The directory server host name must be resolvable from the broker’s machine.
Verify that the imq.user_repository.ldap.password property in /etc/imq/passfile is correct.
In some cases, the broker cannot search for entries if the root suffix contains spaces.
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:
Increase the broker’s memory limit to 1 or 2 GB, as explained in Sun Java System Directory Server Enterprise Edition 6.0 Release Notes.
During an idsync resync operation, keep the log level set to INFO. Changing the log level to FINE or higher increases the load at the broker as more log messages are sent to the central logger.
Run idsync resync for a single Synchronization User List at a time.
Verify that the broker has a backlog of undelivered messages by examining its persistent message store in the appropriate directory.
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.
The message backlog is probably only log files related to an idsync resync operation and you can safely remove them.
Stop the Message Queue broker as described in Starting and Stopping Services
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.
Restart the Message Queue broker.
Follow the instructions in this section to ensure the broker does not run out of memory again.