public java.util.Collection<java.lang.String> getDestinationPrefixes()
public void setPreservePublishOrder(boolean preservePublishOrder)
Whether the client must receive messages in the order of publication.
By default messages sent to the "clientOutboundChannel" may
not be processed in the same order because the channel is backed by a
ThreadPoolExecutor that in turn does not guarantee processing in order.
When this flag is set to true messages within the same session
will be sent to the "clientOutboundChannel" one at a time in
order to preserve the order of publication. Enable this only if needed
since there is some performance overhead to keep messages in order.
preservePublishOrder - whether to publish in order
public boolean isPreservePublishOrder()
Whether to ensure messages are received in the order of publication.
Set the ApplicationEventPublisher that this object runs in.
Invoked after population of normal bean properties but before an init
callback like InitializingBean's afterPropertiesSet or a custom init-method.
Invoked before ApplicationContextAware's setApplicationContext.
Stop this component, typically in a synchronous fashion, such that the component is
fully stopped upon return of this method. Consider implementing SmartLifecycle
and its stop(Runnable) variant when asynchronous stop behavior is necessary.
Note that this stop notification is not guaranteed to come before destruction:
On regular shutdown, Lifecycle beans will first receive a stop notification
before the general destruction callbacks are being propagated; however, on hot
refresh during a context's lifetime or on aborted refresh attempts, a given bean's
destroy method will be called without any consideration of stop signals upfront.
Should not throw an exception if the component is not running (not started yet).
In the case of a container, this will propagate the stop signal to all components
Indicates that a Lifecycle component must stop if it is currently running.
The provided callback is used by the LifecycleProcessor to support
an ordered, and potentially concurrent, shutdown of all components having a
common shutdown order value. The callback must be executed after
the SmartLifecycle component does indeed stop.
The LifecycleProcessor will call only this variant of the
stop method; i.e. Lifecycle.stop() will not be called for
SmartLifecycle implementations unless explicitly delegated to within
the implementation of this method.
The default implementation delegates to Lifecycle.stop() and immediately
triggers the given callback in the calling thread. Note that there is no
synchronization between the two, so custom implementations may at least
want to put the same steps within their common lifecycle monitor (if any).
Whether the message broker is currently available and able to process messages.
Note that this is in addition to the isRunning() flag, which
indicates whether this message handler is running. In other words the message
handler must first be running and then the #isBrokerAvailable() flag
may still independently alternate between being on and off depending on the
concrete sub-class implementation.
Application components may implement
to receive notifications when broker becomes available and unavailable.