+

Search Tips   |   Advanced Search

Default messaging provider queue connection factory [Settings]

A JMS queue connection factory is used to create connections to the associated JMS provider of JMS queues, for point-to-point messaging. Use queue connection factory administrative objects to manage JMS queue connection factories for the default messaging provider.

To view this page in the console, click one of the following paths:

Use this panel to browse or change the configuration properties of the selected JMS queue connection factory for use with the default messaging JMS provider. These configuration properties control how connections are created to associated JMS queues.

By default, connections created using this JMS connection factory in the server containers (for example, from an enterprise bean) are pooled using Java EE Connector Architecture (JCA) connection pooling. We can modify the connection pool settings for this connection factory by selecting Connection pool properties link in the Additional properties section of the administrative console panel.


Configuration tab

The Configuration tab shows configuration properties for this object. These property values are preserved even if the runtime environment is stopped then restarted.


General Properties


Scope

Highest topological level at which application servers can use this resource object.

Information Value
Required No
Data type String


Provider

Specifies a JMS provider, which enables asynchronous messaging based on the Java Message Service (JMS). It provides J2EE connection factories to create connections for specific JMS queue or topic destinations. JMS provider administrative objects are used to manage JMS resources for the associated JMS provider.

Information Value
Required No
Data type String


Name

The required display name for the resource.

Information Value
Required Yes
Data type String


JNDI name

The JNDI name for the resource.

As a convention, use a JNDI name of the form jms/Name, where Name is the logical name of the resource. For more information about the use of JNDI and its syntax, see the topic JNDI support in WebSphere Application Server.

Information Value
Required Yes
Data type String


Description

An optional description for the resource.

Information Value
Required No
Data type Text area


Category

An optional category string to use when classifying or grouping the resource.

Information Value
Required No
Data type String


Bus name

The name of the service integration bus to connect to.

This is the name of the service integration bus that this connection factory is used to create connections to.

Enter the name of the local bus in situations where an application makes connection to foreign buses.

Information Value
Required Yes
Data type Custom


Target

The name of a target that identifies a group of messaging engines. Type of target using the Target type property.

Information Value
Required No
Data type String


Target type

The type of target named in the Target property.

This indicates the name of a target that is to be used to determine one or messaging engines to handle work. The type of target is indicated by the Target type property

Connections are load balanced across the available messaging engines that satisfy the selection criteria.

If want applications to be able to connect to any messaging engine in the bus, do not set this property.

For more information about using this property with other connection factory properties for workload management of connections, see the topic Administrative properties for JMS connections to a bus.

Information Value
Required No
Data type drop-down list
Range

Bus member name

The name of a bus member. This option retrieves the active messaging engines that are hosted by the named bus member (an application server or server cluster).

To specify a non-clustered bus member the Target property must be set to <Node01>.<server1>, for example Node01.server1. For a cluster bus member the Target property must be set to the cluster name.

Custom messaging engine group name

The name of a custom group of messaging engines (that form a self-declaring cluster). This option retrieves the active messaging engines that have registered with the named custom group.

Messaging engine name

The name of a messaging engine. This option retrieves the available endpoints used to reach the named messaging engine.


Target significance

This property specifies the significance of the target group.

For more information about using this property with other connection factory properties for workload management of connections, see the topic Administrative properties for JMS connections to a bus.

Information Value
Required No
Data type drop-down list
Range

Preferred

It is preferred that a messaging engine is selected from the target group. A messaging engine in the target group is selected if one is available. If a messaging engine is not available in the target group, a messaging engine outside the target group is selected if available in the same service integration bus.

Required

It is required that a messaging engine is selected from the target group. A messaging engine in the target group is selected if one is available. If a messaging engine is not available in the target group, the connection process fails.


Target inbound transport chain

The name of the inbound transport chain that the application should target when connecting to a messaging engine in a separate process to the application. If a messaging engine in another process is chosen, a connection can be made only if the messaging engine is in a server that runs the specified inbound transport chain. Refer to the information center for more information.

If the selected messaging engine is in the same server as the application, a direct in-process connection is made and this transport chain property is ignored.

The transport chains represent network protocol stacks operating within a server. The name we specify must be one of the transport chains available in the server that hosts the messaging engine, as listed on the Servers -> Server Types -> WebSphere application servers -> server -> [Server messaging] Messaging engine inbound transports panel. The following transport chains are provided, but we can define our own transport chains on that panel.

InboundBasicMessaging

This is a connection-oriented protocol that uses a standard TCP/IP connection (JFAP-TCP/IP). It includes support for two-phase transactional (remote XA) flows, so that a message producer or consumer, running on a client or server system, can participate in a global transaction managed on that client or server system. The specific use for the XA flows is to support access from an application running in one server to a messaging engine on second server, perhaps because the first server does not have a suitable messaging engine. If the remote XA flows are used, a transaction coordinator must be available local to the application.

InboundSecureMessaging

This is the InboundBasicMessaging protocol wrapped in SSL.
For more information about using this property with other connection factory properties for workload management of connections, see the topic Administrative properties for JMS connections to a bus.

Information Value
Required No
Data type String


Provider endpoints

A comma-separated list of endpoint triplets, with the syntax hostName:portNumber:chainName, used to connect to a bootstrap server. For example Merlin:7276:BootstrapBasicMessaging,Gandalf:5557:BootstrapSecureMessaging. If hostName is not specified, the default is localhost. If portNumber is not specified, the default is 7276. If chainName is not specified, the default is BootstrapBasicMessaging. Refer to the information center for more information.

You only have to modify this property if we have client applications running outside of an application server, or applications on a server in another cell, that want to use this connection factory to connect to the target service integration bus specified on the connection factory.

To use JMS destinations of the default messaging provider, an application connects to a messaging engine on the target service integration bus to which the destinations are assigned. For example, a JMS queue is assigned to a queue destination on a service integration bus.

Client applications running outside of an application server - for example, running in a client container or outside the WAS environment - cannot locate directly a suitable messaging engine to connect to in the target bus. Similarly, an application running on a server in one cell to connect to a target bus in another cell cannot locate directly a suitable messaging engine to connect to in the target bus.

In these scenarios, the clients (or servers in another bus) must complete a bootstrap process through a bootstrap server that is a member of the target bus. A bootstrap server is an application server running the SIB Service, but does not have to be running any messaging engines. The bootstrap server selects a messaging engine running in an application server that supports the required target transport chain. For the bootstrap process to be possible, configure one or more provider end points in the connection factory used by the client.

A bootstrap server uses a specific port and bootstrap transport chain. The port is the SIB_ENDPOINT_ADDRESS (or SIB_ENDPOINT_SECURE_ADDRESS if security is enabled), of the messaging engine that hosts the remote end of the link. Together with host name, these form the endpoint address of the bootstrap server.

The properties of a JMS connection factory used by an application control the selection of a suitable messaging engine and how the application connects to the selected messaging engine.

(iSeries) Note: For the IBM i platform, we must (at least) change the default host name from localhost to your.server.name.

To have an application to use a bootstrap server with a different endpoint address, specify the required endpoint address on the Provider endpoints property of the JMS connection factories that the client application uses. We can specify one or more endpoint addresses of bootstrap servers.

The endpoint addresses for bootstrap servers must be specified in every JMS connection factory used by applications outside of an application server. To avoid having to specify a long list of bootstrap servers, we can provide a few highly-available servers as dedicated bootstrap servers. Then we only have to specify a short list of bootstrap servers on each connection factory.

When configuring a connection to a non-default bootstrap server, specify the required values for the endpoint address and use colons as separators.

For example: for a server assigned non-secure port 7278, on host boothost1, that uses the default transport chain BootstrapBasicMessaging: 

boothost1:7278:BootstrapBasicMessaging
or 
boothost1:7278
and for a server assigned secure port 7289, on host boothost2, that uses the predefined transport chain BootstrapTunneledSecureMessaging: 
boothost2:7289:BootstrapTunneledSecureMessaging

The syntax for an endpoint address is as follows: 

[ [host_name] [ ":" [port_number] [ ":" chain_name] ] ]
where:

host_name

is the name of the host on which the server runs. It can be an IP address. For an IPv6 address, put square braces ([]) around host_name as shown in the example below: 
[2002:914:fc12:179:9:20:141:42]:7276:BootstrapBasicMessaging
. If a value is not specified, the default is localhost.

(iSeries) Note: For the IBM i platform, we must (at least) change the default host name from localhost to your.server.name.

port_number

where specified, is one of the following addresses of the messaging engine that hosts the remote end of the link:

  • SIB_ENDPOINT_ADDRESS if security is not enabled

  • For secure connections, SIB_ENDPOINT_SECURE_ADDRESS if security is enabled.

If port_number is not specified, the default is 7276.

To find either of these values using the administrative console, click...

        Servers -> Server Types -> WebSphere application servers -> server -> [Communications] Ports.

chain_name

is the name of a predefined bootstrap transport chain used to connect to the bootstrap server. If not specified, the default is BootstrapBasicMessaging.

The following predefined bootstrap transport chains are provided:

BootstrapBasicMessaging

This corresponds to the server transport chain InboundBasicMessaging (JFAP-TCP/IP)

BootstrapSecureMessaging

This corresponds to the server transport chain InboundSecureMessaging (JFAP-SSL-TCP/IP)

BootstrapTunneledMessaging

Before we can use this bootstrap transport chain, define a corresponding server transport chain on the bootstrap server. (See Servers -> Server Types -> WebSphere application servers -> server -> [Server messaging] Messaging engine inbound transports.) This transport chain tunnels JFAP and uses HTTP wrappers.

BootstrapTunneledSecureMessaging

Before we can use this bootstrap transport chain, define a corresponding server transport chain on the bootstrap server. (SeeServers -> Server Types -> WebSphere application servers -> server -> [Server messaging] Messaging engine inbound transports.) This transport chain tunnels JFAP and uses HTTP wrappers.

Specify host_name : chain_name instead of host_name : : chain_name (with two colons) is incorrect. It is valid to enter nothing, or to enter any of the following: "a", "a:", ":7276", "::chain", and so on. The default value applies if we do not specify a value, but we must separate the fields with ":".

To provide more than one bootstrap server, identify all the required endpoint addresses. Separate each endpoint address by a comma character. For example, to use the servers from the earlier example: 

boothost1:7278:BootstrapBasicMessaging, 
  boothost2:7289:BootstrapTunneledSecureMessaging, 
  [2002:914:fc12:179:9:20:141:42]:7276:BootstrapBasicMessaging

Information Value
Required No
Data type Text area


Connection proximity

The proximity of messaging engines that can accept connection requests, in relation to the bootstrap messaging engine.

When a client issues a client connect request, the processing attaches to the required bus according to the following logic:

For more information about using this property with other connection factory properties for workload management of connections, see the topic Administrative properties for JMS connections to a bus.

Information Value
Required No
Data type drop-down list
Range

Bus

Connections can be made to messaging engines in the same bus.

Cluster

Connections can be made to messaging engines in the same server cluster.

Host

Connections can be made to messaging engines in the same host.

Server

Connections can be made to messaging engines in the same application server.


Nonpersistent message reliability

The reliability applied to nonpersistent JMS messages sent using this connection factory.

We can change the delivery reliability option for the destination of a message sent by a JMS application as Nonpersistent. The default is Express nonpersistent but we have a range of other options, including those with persistent characteristics, with Assured persistent being the most reliable. See the topic Message reliability levels - JMS delivery mode and service integration quality of service.

Information Value
Required No
Data type drop-down list
Range

Best effort nonpersistent

Messages are discarded when a messaging engine stops or fails. Messages might also be discarded if a connection used to send them becomes unavailable or as a result of constrained system resources.

Express nonpersistent

Messages are discarded when a messaging engine stops or fails. Messages might also be discarded if a connection used to send them becomes unavailable.

Reliable nonpersistent

Messages are discarded when a messaging engine stops or fails.

Reliable persistent

Messages might be discarded when a messaging engine fails.

Assured persistent

Messages are not discarded.

As bus destination

Use the delivery option configured for the bus destination.


Persistent message reliability

The reliability applied to persistent JMS messages sent using this connection factory.

We can change the delivery reliability option for the destination of a message sent by a JMS application as Persistent. The default is Reliable persistent but we have a range of other options including those with nonpersistent characteristics, with Best effort nonpersistent being the least reliable. For more information see the topic Message reliability levels - JMS delivery mode and service integration quality of service.

If we change the delivery reliability options of a message sent by a JMS application from one of the Persistent message reliability options (Assured persistent and Reliable persistent) to one of the Nonpersistent message reliability options (Best effort nonpersistent, Express nonpersistent, and Reliable nonpersistent), you risk losing messages in certain circumstances. For example, at server restart, or when there is heavy workload.

Information Value
Required No
Data type drop-down list
Range

Best effort nonpersistent

Messages are discarded when a messaging engine stops or fails. Messages might also be discarded if a connection used to send them becomes unavailable or as a result of constrained system resources.

Express nonpersistent

Messages are discarded when a messaging engine stops or fails. Messages might also be discarded if a connection used to send them becomes unavailable.

Reliable nonpersistent

Messages are discarded when a messaging engine stops or fails.

Reliable persistent

Messages might be discarded when a messaging engine fails.

Assured persistent

Messages are not discarded.

As bus destination

Use the delivery option configured for the bus destination.


Read ahead

Read ahead is an optimization that preemptively assigns messages to consumers. This improves the time taken to satisfy consumer requests.

Messages assigned to a consumer are locked on the server and cannot be consumed by any other consumers for that destination. Messages assigned to a consumer, but not consumed before that consumer is closed, are subsequently unlocked on the server and then available for receipt by other consumers.

We can override this property for individual JMS destinations by setting the Read ahead property on the JMS destination.

Information Value
Required No
Data type drop-down list
Range

Default

The message provider preemptively assigns messages to consumers on nondurable subscriptions and unshared durable subscriptions. That is, read ahead optimization is turned on only when there can only be a single consumer.

Enabled

The messaging provider preemptively assigns messages to consumers. This improves the time taken to satisfy consumer requests.

Disabled

The messaging provider does not preemptively assign messages to consumers.


Temporary queue name prefix

The prefix used at the start of temporary queues created by applications using this connection factory.

Information Value
Required No
Data type String


Pass message payload by reference

When large object messages or bytes messages are sent, the cost in memory and processor use of serializing, deserializing, and copying the message payload can be significant. If we enable the pass message payload by reference properties on a connection factory or activation specification, you tell the default messaging provider to override the JMS 1.1 specification and potentially reduce or bypass this data copying.

CAUTION:

The parts of the JMS Specification that are bypassed by these properties are defined to ensure message data integrity. Any of our JMS applications that use these properties must strictly follow the rules described in the topic Why and when to pass the JMS message payload by reference, or you risk losing data integrity.


Applications that use this connection factory to send messages must obey the following rules:

When enabled, Object/Bytes Messages sent by a message producing application that has connected to the bus using this connection factory will not have their data copied when set and the system will only serialize the message data when absolutely necessary. Applications sending such messages must not modify the data once it has been set into the message.

Information Value
Required No
Data type Boolean


Applications that use this connection factory to receive messages must obey the following rule:

When enabled, Object Messages received by a message consuming application that has connected to this connection factory will only have their message data serialized by the system when absolutely necessary. The data obtained from these messages must be treated as readOnly by applications.

Information Value
Required No
Data type Boolean


Log missing transaction contexts

Whether or not the container logs that there is a missing transaction context when a connection is obtained.

The Java EE programming model indicates that connections should always have a transaction context. However, some applications do not correctly have a transaction context associated with them.

Select this property to log connections being created without a transaction context.

Information Value
Required No
Data type Boolean


Manage cached handles

Whether cached handles (handles held in instance variables in a bean) should be tracked by the container.

Select this option to track handle management, which can be useful for debugging purposes. However, tracking handles can significantly reduce performance if used at run time.

Information Value
Required No
Data type Boolean


Share data source with CMP

Allow sharing of connections between JMS and container-managed persistence (CMP) entity EJB beans.

This option is used as part of the task to enable container-managed persistence (CMP) entity beans to share the database connections used by the data store of a messaging engine. This has been estimated as a potential performance improvement of 15% for overall message throughput, but can only be used for entity beans connected to the application server containing the messaging engine. This option must not be enabled for a messaging engine that uses file store as its data store.

For more information about using this option, see the topic Enabling CMP entity beans and messaging engine data stores to share database connections.

Information Value
Required No
Data type Boolean


XA recovery authentication alias

The authentication alias used during XA recovery processing.

Select the alias to be used during transaction recovery processing.

This property provides a list of the JCA authentication data entry aliases that have been defined to WAS. We can select a data entry alias to be used to authenticate during XA recovery processing.

If we have enabled security for the associated service integration bus, select the alias that specifies the user ID and password used for XA recovery that is valid in the user registry for WAS. This property must be set if bus security is enabled and XA transactions are to be used.

Information Value
Required No
Data type drop-down list


Mapping-configuration alias

Mapping configuration alias for the JAAS mapping configuration used by this connection factory.

This field will be used only in the absence of a loginConfiguration on the component resource reference. The specification of a login configuration and associated properties on the component resource reference determines the container-managed authentication strategy when the res-auth value is Container.If the DefaultPrincipalMapping login configuration is specified, the associated property will be a JAAS - J2C authentication data entry alias. See related item JAAS - J2C authentication data entry to define a new alias.

Information Value
Required No
Data type drop-down list


Container-managed authentication alias

This alias specifies a user ID and password to be used to authenticate connections to the JMS provider for container-managed authentication. This setting is only used when the res-auth value is container, and the authentication alias was not set when the application was deployed.

Information Value
Required No
Data type drop-down list


Additional Properties

Connection pool properties

An optional set of connection pool settings.


Related Items

JAAS - J2C authentication data

List of user identities and passwords for Java 2 connector security to use.

Buses

A service integration bus supports applications using message-based and service-oriented architectures. A bus is a group of interconnected servers and clusters that have been added as members of the bus. Applications connect to a bus at one of the messaging engines associated with its bus members.


Related:

  • Why and when to pass the JMS message payload by reference
  • Pass message payload by reference: Potential benefits for each processing step
  • Pass message payload by reference: Usage scenarios and example code for forwarding applications
  • Pass message payload by reference: Example code for producer and consumer applications
  • JMS connection factories and service integration
  • Message reliability levels - JMS delivery mode and service integration quality of service
  • JMS queue resources and service integration
  • Configure a queue connection factory for the default messaging provider
  • JNDI support in WAS
  • Connection pool settings
  • (ZOS) Administrative properties for JMS connections to a bus
  • Administrative console buttons
  • Administrative console preference settings