Catching the exceptions raised by a network disconnection and reconnecting is left up to the application designer.

Correcting a Lost Network Connection from a StreamBase Client

A StreamBase Client can connect to a StreamBase Server to enqueue (send tuples) or dequeue (receive tuples). For both, the network connection is established when the Client object is created (e.g. client = new StreamBaseClient(uri)).

See the "Reconnecting" client examples in the StreamBase Client Samples available in the install directory:
<streambase>\sample\client\java-src\com\streambase\sample\clients

DEQUEUE CLIENTS

To dequeue, the client subscribes to a specific stream and blocks on the call Client.Dequeue(Timeout) until a DequeueResult packet (containing zero or more tuples) is received or when the timeout expires. After processing the data, the client application returns to call Dequeue() again.

If a network fault occurs disconnecting a dequeue client, a DequeueResult is returned with a CLOSED status and likely also a NetworkException or StreamBaseException. The disconnect will be reported quickly because a live subscription will exercise the connection frequently.

The server by default also sends heartbeat messages to subscribers, which assists in early reporting of disconnects.

ENQUEUE CLIENTS

To enqueue, the client does NOT subscribe, but simply calls Client.Enqueue(Stream, Tuple) at will.

If a network fault disconnects an enqueue client, that client may not raise an error on the first message sent after the disconnect, but only on the second. The first message is sent into a network layer that thinks it is connected and shifts the connection state from open to closed. Since the sb:// wire protocol does not guarantee delivery (for speed and low latency), there is no mechanism to report this back to the client. The second message is sent into a network layer which knows it is closed, and this raises an exception back to the client object.

By default, enqueue-only clients do not receive heartbeats. Turn on heartbeating explicitly with Client.EnableHeartbeating(). If an enqueue-only client has heartbeating enabled, then it will detect when those heartbeats stop and raise an exception.

RESPONSE TO EXCEPTIONS

In all cases, when the DequeueResult is not GOOD or TIMEOUT, or (for both enqueue and dequeue clients) an exception is raised, call Client.Close() and discard that client object. To reconnect, create a new client object.

In the case where a dequeue-client gets a DequeueResult of TIMEOUT, the application should loop back to call Client.Dequeue() again. This is not an error state and the client remains connected.

NETWORK PROXIES AND LOAD BALANCERS

When there is a smart network device between the client and the server, in some cases a connection which is exercised infrequently is torn down in order to free resources. If this is reported to the client and server correctly (a TCP RST packet with Window Size = 0), then the next attempt to exercise the connection fails immediately. If this is not reported correctly but is closed "silently" then it will take two attempts to exercise the connection to raise an error. A heartbeat timeout may raise an exception to the application sooner.

In all cases, to keep a connection alive, send messages periodically using that client object. In the case of a dequeue client, this is handled by the regular request for more data and the regular heartbeat from the server. In the case of an enqueue client, the heartbeat will keep the connection from the server open, but may let the reverse connection from the client to the server lapse. To protect the connection from the client to the server, enqueue a message at regular intervals, regardless of whether or not data needs to be sent. The "keep alive" periodic message needs to be sent to a valid input stream (but the server need not act on it).