JMS Inbound Protocol
- Former user (Deleted)
The JMS inbound protocol is a multi-tenant capable alternative to the JMS transport. The JMS inbound protocol implementation requires an active JMS server instance to be able to receive messages, and you need to place the client JARs for your JMS server in the ESB profile classpath.
This section provides information on using the Broker Profile of WSO2 EI or Apache ActiveMQ as the JMS server, but other implementations such as Apache Qpid and Tibco are also supported.
- To configure the JMS inbound protocol with the Broker profile, see Configuring the JMS Inbound Protocol with the Broker Profile.
- To configure the JMS inbound protocol with ActiveMQ, see Configuring the JMS Inbound Protocol with ActiveMQ.
Configuration parameters for a JMS inbound endpoint are XML fragments that represent JMS connection factories.
Following is a sample JMS inbound endpoint configuration:
<inboundEndpoint xmlns="http://ws.apache.org/ns/synapse"
name="jms" sequence="request"
onError="fault"
protocol="jms"
suspend="false">
<parameters>
<parameter name="interval">1000</parameter>
<parameter name="coordination">true</parameter>
<parameter name="transport.jms.Destination">ordersQueue</parameter>
<parameter name="transport.jms.CacheLevel">3</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactory</parameter>
<parameter name="sequential">true</parameter>
<parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
<parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>
<parameter name="transport.jms.SessionAcknowledgement">AUTO_ACKNOWLEDGE</parameter>
<parameter name="transport.jms.ConnectionFactoryType">queue</parameter>
</parameters>
</inboundEndpoint>
The parameters interval and coordination are common to all polling inbound endpoints. For descriptions of these parameters, see Common polling inbound endpoint parameters.
JMS inbound endpoint parameters
Parameter Name | Description | Required | Possible Values | Default Value |
|---|---|---|---|---|
| The JNDI initial context factory class. The class must implement the | Yes | A valid class name | - |
| The URL of the JNDI provider. | Yes | A valid URL | - |
| The JNDI name of the connection factory. | Yes | - | - |
sequential | Whether the messages need to be polled and injected sequentially or not. | Yes | true, false | true |
| The type of the connection factory. | No |
|
|
| The JNDI name of the destination. | No | - | The defaults value is the service name. |
| The JMS session acknowledgment mode. | No |
|
|
| The JMS resource cache level. | No |
To subscribe to topics, set the value of | 0 |
| The JMS connection username. | No | - | - |
| The JMS connection password. | No | - | - |
| The JMS API version. | No |
|
|
transport.jms.SubscriptionDurable | Whether the connection factory is subscription durable or not. | No | true, false | false |
transport.jms.DurableSubscriberClientID | The ClientId parameter when using durable subscriptions. | Required if the value specified as transport.jms.SubscriptionDurable is true. | - | - |
| The name of the durable subscriber. | Required if the value specified as | - | - |
| Message selector implementation. | No | - | |
| The time to wait for a JMS message during polling. Set this parameter value to a negative integer to wait indefinitely. Set it to zero to prevent waiting. | No | The number of milliseconds to wait. | 1 |
transport.jms.ContentType
| How the inbound listener should determine the content type of received messages. Priority is always given to the JMS message type. | No | A simple string value, in which case the transport listener assumes that the received messages always have the specified content type, or a set of rules. For more information, see http://axis.apache.org/axis2/java/transports/jms.html#Service_configuration. | - |
transport.jms.ContentTypeProperty | Get the content type from message property. | No | contentType | - |
transport.jms.ReplyDestination | The destination that the response generated by the back-end service is stored. | No | - | ReplyTo from the message |
| Whether messages should be published via the same connection that they were received. | No |
| false |
| If set to true, messages will be forwarded to only one of the consumers and consumers will share the messages that are published to the topic. | No |
| false |
| List of synapse server names separated by commas or spaces where this inbound endpoint should be deployed. If there is no pinned server list, the inbound endpoint configuration will be deployed in all server instances. | No | List of valid synapse server names | - |
transport.jms.ConcurrentConsumers | Number of concurrent threads to be started to consume messages when polling. | No | Any positive integer. For topics this must always be 1. | 1 |
| The retry interval to reconnect to the JMS server. | No | Retry interval in miliseconds. | - |
transport.jms.RetriesBeforeSuspension | The number of consecutive mediation failures after which polling should be suspended. | No | Specify any positive numerical value based on your requirement. Polling will be suspended when the mediation failure count reaches the specified value. | - |
transport.jms.PollingSuspensionPeriod | The period of time that polling is to be suspended when the transport.jms.RetriesBeforeSuspension parameter is set. | No | Specify a required time period in milliseconds. | 60000 |
Samples
For a sample that demonstrates how one way message bridging from JMS to HTTP can be done using the JMS inbound endpoint, see Sample 901: Inbound Endpoint JMS Protocol Sample.