mh_app_lostserver dmh_group connection_handle
The mh_app_lostclient and mh_app_lostserver commands are procedures that you may choose to define in your application in order to handle notification from the DMH message system that the connection to a client or server has become lost.
The mh_app_lostserver command is called in an application that has been a client of a DMH server such as the Hume Datahub , when the connection to the server is lost. The dmh_group argument is the hostname:port identification of the DMH server. This value is the same as the return value from mbx init when the server connection was first established. The connection_handle argument is the underlying connection handle used by the DMH message system. Most applications have one connection to one DMH server and do not need to use these arguments. The mh_app_lostserver command is only executed if it already exists in the interpreter; it is not loaded on demand. In this procedure, your application can perform actions such as inform the user, try to re-connect to the server at timed intervals, save important data to the file system, exit gracefully, etc. To connect to a different server, or to reconnect, use mbx init just like the first time. As an example, if you include the following procedure in your application, your application will notify the user and exit if the DMH server exits.
proc mh_app_lostserver {group h} {
# exit after 30 seconds
after 30000 exit
tk_dialog .popup "System Shutdown" "The system is being shutdown. \
This application is exiting. Contact the System Administrator to find out \
when you may restart." error 0 "Exit Now"
exit
}
The mh_app_lostclient procedure is executed in a DMH server when the server becomes aware of a lost client. You can use this notification mechanism to perform clean-up logic such as closing any data subscriptions the client might have opened. The procedure mh_app_lostclient is called with two arguments, the connection handle that was used to communicate with the client and a boolean value called the superseded flag. When the superseded flag is 1, it indicates that detection of the lost client happened when a new client connection began to use one of the same mailboxes that the lost client was using. In this case you should be extra careful in your cleanup logic so that you do not disrupt conditions that the new client needs. The connection handle is usable as a subscript for the ::dmh namespace array mh_waitboxes, to determine which mailboxes the client was reading from. For most applications, this is sufficient identification for the cleanup code. Use the inspect application on a running DMH server to develop a better understanding of the mh_waitboxes array.