[Erlang Systems]

5 Limitations

This section describes the following limitations in Jive:

5.1 Multiple Back Channels

Java Applets are not allowed to create listen sockets which can accept socket connections. To enable messages to be sent from Erlang to Java, a socket connection is therefore kept open as long as the client is running.

When the client connects to the server, it opens a socket connection from the standard server port (14000). The client then sends a message through this port that causes the server to spawn a client proxy process, with the socket as a parameter. This proxy process is what is called the self-process. It accepts messages and sends those messages through the socket to the client.

This works well if there is little message traffic from the server to the client. However, all messages from the server are sent through this single socket and performance will suffer if the amount of data increases.

To solve this problem, the client can be allowed to open more than one socket connection to the server. This will enable the self process to send messages through different sockets simultaneously, which will increase message throughput.

5.2 Proper Non-Blocking IO

When waiting for input from a socket, the thread should be suspended until some input arrives according to the Java specification. Accordingly, waiting for input only suspends a single thread, not the entire runtime system.

This works fine with Solaris 1.x/2.x, but there are bugs in several implementations, including Netscape for Windows 95 and Netscape for Apple Macintosh. These implementations suspend the entire Java runtime system instead.

Temporary versions of non-blocking socket reads have been implemented as a work-around to this problem. The thread is suspended for a fixed amount of time if there is not enough input available, and checks are performed until there is enough input from the socket.

while (input.available() == 0) {
  try {
    Thread.sleep(100);
  } catch (InterruptedException e) {}
}
return input.read();

The delay is set to 100 ms, but it could be shorter. If the delay is too long it will slow down the message passing notably. Setting the value too short will use too much processing power.

This should be changed as soon as these bugs are fixed.


Copyright © 1991-98 Ericsson Telecom AB