이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 4. Configuration


This chapter describes the process for binding the AMQ OpenWire JMS implementation to your JMS application and setting configuration options.

JMS uses the Java Naming Directory Interface (JNDI) to register and look up API implementations and other resources. This enables you to write code to the JMS API without tying it to a particular implementation.

Configuration options are exposed as query parameters on the connection URI. Some of the options are also exposed as corresponding set and get methods on the ConnectionFactory implementation object.

For more information about configuring AMQ OpenWire JMS, see the ActiveMQ user guide.

4.1. Configuring the initial context factory

JMS applications use a JNDI InitialContext object obtained from an InitialContextFactory to look up JMS objects such as the connection factory. AMQ OpenWire JMS provides an implementation of the InitialContextFactory in the org.apache.activemq.jndi.ActiveMQInitialContextFactory class.

The InitialContextFactory implementation is discovered when the InitialContext object is instantiated:

javax.naming.Context context = new javax.naming.InitialContext();

To find an implementation, JNDI must be configured in your environment. There are two main ways of achieving this, using a jndi.properties file or using a system property.

Using a jndi.properties file

Create a file named jndi.properties and place it on the Java classpath. Add a property with the key java.naming.factory.initial.

Example: Setting the JNDI initial context factory using a jndi.properties file

java.naming.factory.initial = org.apache.activemq.jndi.ActiveMQInitialContextFactory

In Maven-based projects, the jndi.properties file is placed in the <project-dir>/src/main/resources directory.

Using a system property

Set the java.naming.factory.initial system property.

Example: Setting the JNDI initial context factory using a system property

$ java -Djava.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory ...

4.2. Configuring the connection factory

The JMS connection factory is the entry point for creating connections. It uses a connection URI that encodes your application-specific configuration settings.

To set the factory name and connection URI, create a property in the format below. You can store this configuration in a jndi.properties file or set the corresponding system property.

The JNDI property format for connection factories

connectionFactory.<factory-name> = <connection-uri>

For example, this is how you might configure a factory named app1:

Example: Setting the connection factory in a jndi.properties file

connectionFactory.app1 = tcp://example.net:61616?jms.clientID=backend

You can then use the JNDI context to look up your configured connection factory using the name app1:

ConnectionFactory factory = (ConnectionFactory) context.lookup("app1");

4.3. Connection URIs

A connection factory is configured using a connection URI in the following format:

The Connection URI format

<scheme>://<host>:<port>[?<option>=<value>[&<option>=<value>...]]

The scheme is tcp for unencrypted connections and ssl for SSL/TLS connections.

For example, the following is a connection URI that connects to host example.net at port 61616 and sets the client ID to backend:

Example: A connection URI

tcp://example.net:61616?jms.clientID=backend

Failover URIs take the following form:

The failover URI format

failover:(<connection-uri>[,<connection-uri>])[?<option>=<value>[&<option>=<value>...]]

Options prefixed with nested. are applied to each connection URI in the list.

The available connection options are described in the following sections.

4.4. JMS options

jms.username
The user name used to authenticate the connection.
jms.password
The password used to authenticate the connection.
jms.clientID
The client ID that is applied to the connection.
jms.closeTimeout
The close timeout in milliseconds. The default is 15000 (15 seconds).
jms.checkForDuplicates
If enabled, ignore duplicate messages. It is enabled by default.
jms.disableTimeStampsByDefault
If enabled, do not timestamp messages. It is disabled by default.
jms.useAsyncSend
If enabled, send messages without waiting for acknowledgment. It is disabled by default.
jms.alwaysSyncSend
If enabled, send waits for acknowledgment in all delivery modes. It is disabled by default.
jms.useCompression
If enabled, compress message bodies. It is disabled by default.
jms.useRetroactiveConsumer
If enabled, non-durable subscribers can receive messages that were published before the subscription started. It is disabled by default.

Prefetch policy options

Prefetch policy determines how many messages each MessageConsumer will fetch from the remote peer and hold in a local "prefetch" buffer.

jms.prefetchPolicy.queuePrefetch
The number of messages to prefetch for queues. The default is 1000.
jms.prefetchPolicy.queueBrowserPrefetch
The number of messages to prefetch for queue browsers. The default is 500.
jms.prefetchPolicy.topicPrefetch
The number of messages to prefetch for non-durable topics. The default is 32766.
jms.prefetchPolicy.durableTopicPrefetch
The number of messages to prefetch for durable topics. The default is 100.
jms.prefetchPolicy.all
This can be used to set all prefetch values at once.

The value of prefetch can affect the distribution of messages to multiple consumers on a queue or shared subscription. A higher value can result in larger batches sent at once to each consumer. To achieve more even round-robin distribution, use a lower value.

Redelivery policy options

Redelivery policy controls how redelivered messages are handled on the client.

jms.redeliveryPolicy.maximumRedeliveries
The number of times redelivery is attempted before the message is sent to the dead letter queue. The default is 6. -1 means no limit.
jms.redeliveryPolicy.redeliveryDelay
The time in milliseconds between redelivery attempts. This is used if initialRedeliveryDelay is 0. The default is 1000 (1 second).
jms.redeliveryPolicy.initialRedeliveryDelay
The time in milliseconds before the first redelivery attempt. The default is 1000 (1 second).
jms.redeliveryPolicy.maximumRedeliveryDelay
The maximum time in milliseconds between redelivery attempts. This is used if useExponentialBackOff is enabled. The default is 1000 (1 second). -1 means no limit.
jms.redeliveryPolicy.useExponentialBackOff
If enabled, increase redelivery delay with each subsequent attempt. It is disabled by default.
jms.redeliveryPolicy.backOffMultiplier
The multiplier for increasing the redelivery delay. The default is 5.
jms.redeliveryPolicy.useCollisionAvoidance
If enabled, adjust the redelivery delay slightly up or down to avoid collisions. It is disabled by default.
jms.redeliveryPolicy.collisionAvoidanceFactor
The multiplier for adjusting the redelivery delay. The default is 0.15.

4.5. TCP options

connectionTimeout
The connection timeout in milliseconds. The default is 30000 (30 seconds). 0 means no timeout.
ioBufferSize
The I/O buffer size in bytes. The default is 8192 (8 KiB).
useKeepAlive
If enabled, periodically send data to keep the connection alive. It is enabled by default.
soTimeout
The socket read timeout. The default is 0, meaning no timeout.
soWriteTimeout
The socket write timeout. The default is 0, meaning no timeout.
tcpNoDelay
If enabled, do not delay and buffer TCP sends. It is disabled by default.

4.6. Failover options

maxReconnectAttempts
The number of reconnect attempts allowed before reporting the connection as failed. The default is -1, meaning no limit. 0 disables reconnect.
maxReconnectDelay
The maximum time in milliseconds between the second and subsequent reconnect attempts. The default is 30000 (30 seconds).
randomize
If enabled, randomly select one of the failover endpoints. It is enabled by default.
reconnectDelayExponent
The multiplier for increasing the reconnect delay backoff. The default is 2.0.
useExponentialBackOff
If enabled, increase the reconnect delay with each subsequent attempt. It is enabled by default.

4.7. SSL/TLS options

socket.keyStore
The path to the SSL/TLS key store. A key store is required for mutual SSL/TLS authentication. If unset, the value of the javax.net.ssl.keyStore system property is used.
socket.keyStorePassword
The password for the SSL/TLS key store. If unset, the value of the javax.net.ssl.keyStorePassword system property is used.
socket.trustStore
The path to the SSL/TLS trust store. If unset, the value of the javax.net.ssl.trustStore system property is used.
socket.trustStorePassword
The password for the SSL/TLS trust store. If unset, the value of the javax.net.ssl.trustStorePassword system property is used.
socket.enabledCipherSuites
A comma-separated list of cipher suites to enable. If unset, the JVM default ciphers are used.
socket.enabledProtocols
A comma-separated list of SSL/TLS protocols to enable. If unset, the JVM default protocols are used.

4.8. Large message options

The client can enable large message support by setting a value for the property wireFormat.minLargeMessageSize. Any message larger than wireFormat.minLargeMessageSize is considered a large message.

wireFormat.minLargeMessageSize
The minimum size in bytes at which a message is treated as a large message. The default is 102400 (100 KiB).
wireFormat.compressLargeMessages

If enabled, compress large messages, as defined by wireFormat.minLargeMessageSize. It is disabled by default.

Note

If the compressed size of a large message is less than the value of wireFormat.minLargeMessageSize, the message is sent as a regular message. Therefore, it is not written to the broker’s large-message data directory.

4.9. Configuring JNDI resources

4.9.1. Configuring queue and topic names

JMS provides the option of using JNDI to look up deployment-specific queue and topic resources.

To set queue and topic names in JNDI, create properties in the following format. Either place this configuration in a jndi.properties file or define corresponding system properties.

The JNDI property format for queues and topics

queue.<queue-lookup-name> = <queue-name>
topic.<topic-lookup-name> = <topic-name>

For example, the following properties define the names jobs and notifications for two deployment-specific resources:

Example: Setting queue and topic names in a jndi.properties file

queue.jobs = app1/work-items
topic.notifications = app1/updates

You can then look up the resources by their JNDI names:

Queue queue = (Queue) context.lookup("jobs");
Topic topic = (Topic) context.lookup("notifications");

4.9.2. Setting JNDI properties programatically

As an alternative to using a jndi.properties file or system properties to configure JNDI, you can define properties programatically using the JNDI initial context API.

Example: Setting JNDI properties programatically

Hashtable<Object, Object> env = new Hashtable<>();

env.put("java.naming.factory.initial", "org.apache.activemq.jndi.ActiveMQInitialContextFactory");
env.put("connectionFactory.app1", "tcp://example.net:61616?jms.clientID=backend");
env.put("queue.jobs", "app1/work-items");
env.put("topic.notifications", "app1/updates");

InitialContext context = new InitialContext(env);

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.