Replacing Disconnect Handling

In some cases, an application does not want the AMPS client to reconnect, but instead wants to take a different action if disconnection occurs. For example, a stateless publisher that sends ephemeral data (such as telemetry or prices) may want to exit with an error if the connection is lost rather than risk falling behind and providing outdated messages. Often, in this case, a monitoring process will start another publisher if a publisher fails, and it is better for a message to be lost than to arrive late.

To cover cases where the application has unusual needs, the AMPS client library allows an application to provide custom disconnect handling.

Your application gets to specify exactly what happens when a disconnect occurs by supplying a function to client.setDisconnectHandler(), which is invoked whenever a disconnect occurs. This may be helpful for situations where a particular connection needs to do something completely different than reconnecting or failing over to another AMPS server.

Setting the disconnect handler completely replaces the disconnection and failover behavior for an HAClient and provides the only disconnection and failover behavior for a Client.

The handler runs on the thread that detects the disconnect. This may be the client receive thread (for example, if the disconnect is detected due to heartbeating) or an application thread (for example, if the disconnect is detected when sending a command to AMPS).

The example below shows the basics:

public class TestDisconnect {
    private String _uri = null;

    public TestDisconnect(String uri) throws AMPSException {
        this._uri = uri;
        Client client = new Client("TestDiscon-Client");
        ExitOnDisconnectHandler dh = new ExitOnDisconnectHandler();

        client.setDisconnectHandler(dh);
        client.connect(this._uri);

        for (Message msg : client.subscribe("order") )
        {
           // ...
        }
    }

    class ExitOnDisconnectHandler implements ClientDisconnectHandler{
        public void invoke(Client client) {
            try {
              // At this point, the client is already disconnected
              // so calling close() isn't necessary.
              System.exit(1);
            } catch(Exception e){;}
        }
    }

    class MsgPrinter implements MessageHandler
    {
        public void invoke(Message m) {
            System.out.println(m.getData());
        }
    }
}

Unexpected Messages

The AMPS Java client handles most incoming messages and takes appropriate action. Some messages are unexpected or occur only in very rare circumstances. The AMPS Java client provides a way for clients to process these messages. Rather than providing handlers for all of these unusual events, AMPS provides a single handler function for messages that can't be handled during normal processing.

Your application registers this handler by setting the lastChanceMessageHandler for the client. This handler is called when the client receives a message that can't be processed by any other handler. This is a rare event, and typically indicates an unexpected condition.

For example, if a client publishes a message that AMPS cannot parse, AMPS returns a failure acknowledgment. This is an unexpected event, so AMPS does not include an explicit handler for this event, and failure acknowledgments are received in the method registered as the lastChanceMessageHandler.

Your application is responsible for taking any corrective action needed. For example, if a message publication fails, your application can decide to republish the message, publish a compensating message, log the error, stop publication altogether, or any other action that is appropriate.