Administer the embedded JMS server

In WebSphere Application Server, each application server can include an embedded Java Message Service (JMS) server. The embedded JMS server starts when you start your application server. If you are using WebSphere Application Server Network Deployment, see Administer JMS servers in Network Deployment. The embedded JMS server is not part of a Network Deployment instance.

The embedded JMS server is not enabled for the default application server instance. However, when you create a new application server instance, the embedded JMS server is enabled for the instance. If you do not want to use the embedded JMS server, specify the -noembeddedjms parameter when you run the crtwasinst script. For more information, see The crtwasinst script.

Notes:

• To use the embedded JMS provider, install WebSphere MQ for iSeries and WebSphere MQ classes for Java and JMS. If you did not install these products with WebSphere Application Server, see Install WebSphere MQ for iSeries in the Application development topic for installation instructions.
• In a WebSphere Application Server instance, the JMS server starts when you start the application server.

For information about administering embedded JMS, see these sections:

• Determine if embedded JMS is enabled for your instance
• Enable and disable embedded JMS
• Use embedded JMS with your applications
• Modify JMS servers
• Coexistence restriction between Version 5.0.x and Version 5.1

Determine if embedded JMS is enabled for your application server

To determine if the embedded JMS server is enabled for your instance, run the dspwasinst script. If embedded JMS is enabled for the server, the output includes this line:

   Embedded JMS is enabled for this server.

If embedded JMS is not enabled, the output includes this line:

   Embedded JMS is not enabled for this server.

For more information about using the dspwasinst script, see Display instance properties.

Enable and disable embedded JMS

Use the chgwassvr script to enable or disable the embedded JMS server for an instance. In this example, the embedded JMS server is enabled for the default application server in the default instance:

chgwassvr -server server1 -embeddedjms yes

For more information about the chgwassvr script, see The chgwassvr script.

Use embedded JMS with your applications

To use the embedded JMS server with your applications, configure JMS resources such as queue connection factories, queues, topic connection factories, and topics. For more information, see Administer JMS resources.

Modify JMS servers

To modify a JMS server, follow these steps:

1. Start the administrative console.
2. In the topology tree, expand Servers and click Application Servers.
3. On the Application Servers page, click Server Components.
4. On the Server Component page, click JMS Server.
5. Make your changes. For information on the properties that you can configure, see these help topics:
   • JMS server settings
   • Administration service settings
   • Java Management Extensions connector settings
   • Extension MBean Provider settings
   • Repository service settings
   • Diagnostic trace service settings
   • IBM service log settings
   • Process definition settings
   • Java virtual machine settings
   • Process execution settings
   • Process logs settings
   • Monitor policy settings
   • End point settings

6. Click OK.
7. Save the configuration.

Coexistence restriction between Version 5.0.x and Version 5.1

If an instance in WebSphere Application Server Version 5.1 has the same name as an instance in Version 5.0, and embedded JMS is enabled for both application servers, you cannot run the servers concurrently. For example, you might enable embedded JMS for the default application servers in Version 5.0 and Version 5.1, and then attempt to run them at the same time. In this case, both servers attempt to use the same MQ queue manager, and lock conflicts result. Use any of these options to avoid this problem:

• Do not attempt to run both servers at the same time.

• Use instances that have different names.

• Migrate your Version 5.0 instance to Version 5.1, and do not use the Version 5.0 instance.

• If you want to use the same name for both instances and run both instances at the same time, recreate the Version 5.1 instance with a different node name.
  1. Run the dltwasinst script to delete the Version 5.1 instance. For more information, see The dltwasinst script.
  2. Run the crtwasinst script to recreate the instance. When you run the script, include the -node parameter to specify a new node name. For more information, see The crtwasinst script.