Handling timeouts and identifying connectivity issues
Handling timeouts is one of those tasks that people generally leave to the last moment. In an ideal world, we'd never need them. Now a days, a typical application will have remote calls to other systems via Web services (e.g. SOAP or RESTful), RMI, etc, hence timeout handling is critical. Badly behaved clients may go offline and leaving server threads locked, or overloaded servers may stall, causing a network client to block indefinitely for input. You could also have intermittent issues due to proxy server or load balancer timeouts or connection leaks. For these reasons, it is necessary to detect and handle network timeouts.
Your application might not be coded with appropriate connection retries or appropriate time out values. You could simulate connectivity issues by creating SSH tunnels to the actual destination server. For example, your application may have connectivity to a Vignette ServerB running on port 9111. To simulate connectivity issues, you may create a local SSH tunnel to a UNIX ServerA, which connects to Vignette application running on ServerB:9111. Once you log on to ServerA via PutTTY (i.e. a UNIX client on Windows) as shown below, a tunnel will be opened to ServerB:9111. Any calls to localhost:4000 will be forwarded to ServerB:9111 via ServerA. In your application, you could use the localhost:4000 instead of using ServerB:9111 to connect to the Vignette application. This will enable you to simulate the scenario of ServerB being down by just destroying the tunnel, and not the actual server, which might be used by others. By destroying the tunnel, you could improve your application code to graciously handle connectivity issues.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
