A long-term aim in pervasive computing is to have zero configuration, whereby you can plug devices into a network and things "just work." Jini goes a long way toward making this possible at the service level, but the current implementation relies heavily on a functioning network layer: misconfiguration of the network can cause a great deal of problems in Jini.

The following is a typical network configuration error:

java.rmi.ConnectException: connection refused or timed out to 
               BasicObjectEndpoint[88133900-39f9-466a-880b-de8ce6653a63,
                                   TcpEndpoint[0.0.0.0:1831]]; nested exception is:
        java.net.ConnectException: Connection refused

This error can occur by using the new configuration mechanism, where a service is exported by Jeri as follows:

    exporter = new BasicJeriExporter(TcpServerEndpoint.getInstance(0),
                                     new BasicILFactory());

"Exporting a service" means finding the local host, getting its host name and IP address and listening on any available port. I lost several days' work over this, as the hostname on one machine was incorrectly set, and the Java network layer (by InetAddress.getLocalHost()) was unable to determine the IP address of localhost and returned "0.0.0.0"—and nothing could connect to that address!

The solution was to correctly set the hostname on that machine; then services could be found and run on that machine. Alternatively, TcpServerEndpoint.getInstance(0) could be replaced by TcpServerEndpoint.getInstance("my_ip_address", 0) (for a suitable "my_ip_address", of course!) in the configuration files for the services in that machine.