The reliable messaging feature improves the quality of
message delivery between clients and destinations on the LiveCycle
Data Services server.
Reliable messaging provides the following benefits above what
is provided with standard messaging:
Benefit
|
Description
|
|---|
No message loss
|
No messages are lost when transient network
failures occur if the AdvancedChannelSet object's immediate reliable
reconnect attempt succeeds.
If this single attempt fails the
reliable sequence is closed and the client proceed to regular channel
failover and channel set hunting.
|
Ordered message delivery
|
Reliable messaging ensures the delivery
of correctly ordered messages when using AMF or HTTP channels/endpoints
that use more than one TCP socket concurrently to send or receive
messages. Message order is ensured even if the intended order differs
from the order in which the messages are received from the network.
When
you use RTMP channels/endpoints, messages are delivered in the correct
order whether you use reliable messaging.
|
No duplicate message processing
|
There is no duplicate processing of messages
even when messages for reliable destination are automatically sent
following a disconnect and reconnect.
|
Reconnection to server following unexpected
connection loss
|
For deployments where network connections
are forced to close periodically, reliable messaging allows the
client to seamlessly reconnect to the same server. The client resumes exactly
where it left off, as long as the server has not crashed, or exited.
A
single reliable reconnection is attempted immediately following
connection loss. This reconnection attempt allows the reliable connection
to survive due to an idle timeout or when firewalls, proxies, or
other network components force a TCP connection to close periodically.
If this single attempt fails, the reliable sequence is closed and
the client proceeds to regular channel failover and channel set
hunting. The feature currently does not support repeated reliable
reconnect attempts.
|
Note: To use reliable messaging, you enable advanced
messaging support.
To enable reliable messaging, you set the reliable property
to true in the network properties section of the
destination definition, as the following example shows:
...
<destination id="trade-settlement">
<properties>
<network>
<reliable>true</reliable>
</network>
</properties>
</destination>
...
By default, if a channel was successfully connected before experiencing
a fault or disconnection, it attempts a pinned reconnection to the
same endpoint URL once. If this immediate reconnection attempt fails,
the channel falls back to its previous failover strategy and attempts
to fail over to other server nodes in the cluster or fall back to
alternate channel protocols. To support IP mobility use cases, the
AdvancedChannelSet object provides the following property that you can
assign in ActionScript code to extend the time duration for reliable
reconnect attempts to continue. One such use case is undocking a
laptop and waiting several seconds for its wireless modem to start
up and acquire network connectivity and a new IP address.
advancedChannelSet.reliableReconnectDuration = 60000; // In milliseconds.
The default value is 0. The default behavior
is to try a single, immediate reliable reconnection. By assigning
a value larger than 0, you give the AdvancedChannelSet
more time to attempt to reconnect reliably more than once.
You can also set this value statically in the services-config.xml
file within the flex-client section, as the following
example shows:
...
<flex-client>
<reliable-reconnect-duration-millis>60000</reliable-reconnect-duration-millis>
<!-- Idle timeout for FlexClient state at the server, including reliable messaging sequences.
In order to support reliable reconnects consistently across all supported channels and
endpoints, this value must be defined and greater than 0.
Note: Any active sessions/connections keep idle FlexClient instances alive. This timeout
only applies to instances that have no currently active associated sessions/connections.
-->
<timeout-minutes>1</timeout-minutes>
</flex-client>
...
Note: If you do not define an explicit FlexClient timeoutand at
least one RTMP endpoint is registered with the message broker, the
server uses a default timeout of 5 seconds for FlexClient timeout.
This allows reliable messaging over RTMP to work with no configuration
other than setting destinations as reliable. If you want to use
a longer reliable reconnect interval, use the optional timeout-minutes and reliable-reconnect-duration-millis elements
within the flex-client section of services-config.xml
file.
Standard behavior without reliable messaging
RTMP
channels use a single TCP connection and never deliver messages
to the server out of order whether you enable reliable messaging.
However, standard AMF channels do not guarantee in-order delivery
of sent messages. Server-to-client AMF messages are rolled up into
a batch and sent as binary body content in an HTTP POST when Flash
Player is able to issue a request. Within a batch, AMF messages
are guaranteed to be delivered for processing on the server in order. However,
there is a slim chance that clients on slow networks could put themselves
into a conflict state unintentionally due to separate HTTP requests that
contain individual batches of AMF messages arriving at the server
out of order. Nothing in Flash Player or in standard AMF channels
prevents sending more than one HTTP request containing a batch of
AMF messages at a time. Standard HTTP channels use a unique URLLoader
for each message sent, but they serialize the flow of sent messages
and only send a subsequent message after an ack (acknowledgement)
or fault for the previous message is received. These channels lack
the efficiency introduced by the batching behavior of the AMF channels,
but they do guarantee in-order message delivery during regular operation.
RTMP channels
use a single TCP connection and never receive messages from the server
out of order whether you enable reliable messaging. However, standard AMF
and HTTP channels sometimes issue concurrent HTTP requests over multiple
TCP connections. Polling or streaming, which simulates a duplex connection
by overlapping of concurrent HTTP requests more of the time sometimes
exacerbates this situation. Standard AMF and HTTP channels provide no
guarantee for delivery order across reply messages and pushed messages because
data arrives at the client over separate connections concurrently.
Received
messages are either replies (acknowledgements/results/faults) for
sent messages or they are pushed messages generated by other clients,
backend processes, or the server directly. All reliable messages
traveling from the server to the client's AdvancedChannelSet object
belong to a common sequence. As messages are received, the AdvancedChannelSet
object uses a reliable receive buffer to re-order them if necessary,
and any in-order messages are removed from the buffer and dispatched
to application code. Reply messages are dispatched to the acknowledgment
or fault handler of the component that sent the correlated request
message. Pushed messages are dispatched to any listeners that have
registered for MessageEvents.
Regardless of the runtime message
ordering behavior for the various standard channels discussed here,
none of these channels can seamlessly survive a transient network
disconnect event on its own. By enabling reliable messaging, the
channel and server endpoint enforce a guarantee of in-order, once-and-only-once
message delivery between the client and server that survives any
transient disconnect followed by a successful reconnect to the same
server.
Important: There is a trade-off between quickly detecting
that clients have disconnected versus supporting long reliable reconnect
durations. For applications where timely server detection of clients
disconnecting is important, leave the reliable reconnect duration
at its default setting or use a short duration value based on the requirements
of your application. For applications where you want to favor reliable reconnections,
you can tune this value higher.
