...
- Non-blocking operations
- Request-reply operations
- Callbacks
- Local and global (XA) transacted one-way messaging with transparent resource enlistment and recovery
...
- idle.limit
- transaction.timout
- receive.timeout
- max.messages
- recovery.interval
- max.receivers
- min.receivers
...
When used with ActiveMQ, the JMS binding extension is configured by default to be a provider of binding.sca. This means components can be wired without configuring transports or physical endpoint information – basically as if they were components locally wired. The JMS binding extension will manage queue setup and connections transparently.
Connection factories can be configured for use with binding.sca in systemConfig.xml in the following way:
<config>
<jms>
<connection.factories>
<connection.factory name="xaFactory"
broker.url="vm://broker" type="xa"/>
<connection.factory name="nonXaFactory"
broker.url="vm://broker" type="local"/>
</connection.factories>
<binding.sca xa.factory="xaFactory"
factory= "nonXaFactory"/>
</jms>
</config> Binding a channel to JMS is similar to binding a reference or service. The main difference is that by default, Topics instead of Queues are used for messaging:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<channel name="TestDurableChannel" requires="f3:durable">
<binding.jms>
<destination jndiName="TestDurableChannelTopic"/>
</binding.jms>
</channel>
|
Binding a channel is typically done when there is a need to observe events originating from outside the SCA domain or there is a need to send events to an external consumer.
Durable Subscriptions
Durable JMS topic subscriptions can be enabled using the durable intent on a channel:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<channel name="DurableChannel" requires="f3:durable">
<binding.jms>
<destination jndiName="DurableChannelTopic"/>
</binding.jms>
</channel>
|
| Info | ||
|---|---|---|
| ||
When a channel is bound to a JMS Topic, there is the possibility the events sent to the channel will be dropped and not received by consumers. To understand why this happens it is necessary to describe how consumers are attached to the JMS channel binding. Fabric3 implements a message container that performs a looping blocking receive with a timeout. This is necessary to support transactional dequeue (the receive is performed within a transaction) and also to avoid tying up kernel threads indefinitely. If a timeout occurs, the container will loop and perform another receive. If a message is received, it will be processed and the container will loop and perform a new receive. This creates the possibility of a window where no consumers are connected to the Topic. When this occurs, a JMS provider is free to drop messages. At high message rates, the possibility of dropping messages increases as the message container will frequently be processing messages and not receiving. To avoid dropped messages, the channel should be configured as durable. This will result in a JMS durable topic subscription being used. However, using durable subscriptions comes at a significant cost both in terms of performance and memory requirements as messages must be held in a topic until they have been delivered to all active subscriptions. |