Page Comparison

...

• max.receivers - Sets the maximum number of receivers to create
• min.receivers - Sets the minimum number of receivers to retain
• idle.limit - Sets the number of times a receiver can be marked idle during its execution window before it is removed from the work scheduler. Note if the maximum number of receivers is set to one, the single receiver will not be removed. Likewise, if a minimum number of receivers is set, idle receivers will not be removed if that threshold is reached.
• receive.timeout - Set the time in milliseconds the message receive operation should block for.
• max.messages - Sets the maximum number of messages to process by a receiver during its execution window. The default is unlimited, which results in the receiver processing messages until shutdown. Setting the number lower increases the ability of the work scheduler to adjust scheduling at the expense of thread context switches as receivers may be scheduled on different threads.
• recovery.interval - Sets the time in milliseconds to wait while making repeated recovery attempts.

Pausing on Startup

Starting with Fabric3 1.9.5, JMS listeners can be configured to pause (i.e. not receive messages) when the runtime is booted. The listeners can then be started using an HTTP POST operation via the REST Management API. To configure listeners to pause on startup, use the jms/@pause.on.start attribute in systemConfig.xml:

<config>  
    <jms pause.on.start="true"/>
    <!-- ... -->
</config>

The Fabric3 Admin CLI can then be used to start the listeners. Alternatively, a script can issue an HTTP POST operation. Note that if the POST is made against the zone cluster address, Fabric3 will replicate the management change to all runtimes in the zone (cluster). The following is an example CLI session that starts all listeners:

f zone2                     //Goes ("follows" the link) to zone2 where the listeners are deployed. Substitute the appropriate zone name.
p zone/runtime/transports/resume jms     // Puts the value "jms" to the zone/runtime/transports/resume resource. Since this is a zone address, the changes will be replicated throughout the cluster

Alternatively, a script could POST the "jms" value serialized in the JSON format to http://<zone leader>/management/zone/runtime/transports/resume. Listeners on individual runtime instances can be started by using the direct runtime address as opposed to the zone address, e.g.:

p runtime/transports/resume jms