Single JMS server in weblogic cluster issues

An application is deployed on all the Managed Servers of a six Managed Server cluster and sends its JMS messages to a single JMS server. An external client application connects to all six Managed Servers and consumes these messages. The single JMS server is targeted to the default migratable target created in one of the Managed Servers.

A WebLogic Server Managed Server Cluster should provide a distribution of load between Managed Servers and ensure that all services are available, at all times. Unfortunately, having a single JMS server introduces a point of failure, even if the JMS service is configured to be automatically migrated to another WebLogic Server instance within the cluster. Below we will discuss some of the common issues faced in single JMS server in weblogic cluster.

-> During the migration process, a migratable resource is suspended in the current WebLogic Server instance, after which it is migrated to the target instance and after that, it is activated. When there only one JMS server, the JMS subsystem becomes completely unavailable during the time elapses while the migration is happening.

-> Having a single JMS Server also affects the load distribution, as all JMS related WebLogic Server activity and traffic is concentrated on the only WebLogic Server instance with a JMS server.

-> In order to avoid the uneven distribution of load, to ensure service persistence and to eliminate any risk of a point of failure, WebLogic Server support advises you to follow convention of having one JMS server per Weblogic Server instance, within a WebLogic Server Cluster. The JMS system module should be targeted on the Cluster but Connection Factories and Distributed Queues should use a subdeployment targeted to all the JMS servers in the cluster.

 

 

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.