This section describes known Java message queue issues and associated solutions.
Failures to reconnect in timing-dependent scenarios can be caused by several problems.
You can work around these problems by:
Restarting the brokers involved
Restarting the Application Server instances involved
If you configure JMS to be REMOTE, Enterprise Server fails to start if the MQ broker is not started.
Set the following JVM option as follows: com.sun.enterprise.jms.CONNECT_MQ_LAZILY=true. After setting this JVM option, you can start Communications Server if the MQ broker is not started. However, it is recommended that you start MQ before starting the server.
After creating a domain with a cluster profile on a Linux system, you may encounter a java.lang.OutOfMemoryError: Java heap space error, and the server instance may fail to restart because the MQ broker does not start. The system never recovers after this condition. The problem is a misconfigured /etc/hosts file; specifically, the server host name is pointing to the loopback address 127.0.0.1.
By design, an MQ broker cluster cannot start with the network device configured to point to the loopback address. This is not a bug. The solution is to make sure that the /etc/hosts file for the Communications Server host does not point to 127.0.0.1.
During Application Server startup, the server checks the Message Queue version. If the Message Queue version is incorrect, then the server upgrades using the imqjmsra.jar. This upgrade JAR and its classes will not be available to the server until the next restart of Application Server. This situation only occurs if Message Queue is upgraded alone, or if Application Server is patched alone. A side effect of this situation is that sometimes Application Server does not start.
Both Message Queue and Application Server need to be maintained at the same patch level, or restart the Application Server.