Threads

The HTTP Bundle takes all threads for managing client requests from the Thread Pool Manager Service. Each client request is processed in a separate thread except in cases of persistent connections. If the HTTP Service has already occupied a number of threads, which are waiting for the Request Timeout expiration, client disconnection or activity, it may hang down. This may happen because the default maximum capacity of the Thread Pool Manager service is 30 threads which may term insufficient. Such situations may occur if clients have too long timeouts for persistent connections. One of the following approaches (or a combination of them) may solve this problem:

1. Decreasing the HTTP Service request timeout so that inactive clients will be disconnected soon.
2. Increasing the thread capacity of the Thread Pool Manager service. If you own scanty resources, this approach is not advisory.
3. Setting the Persistent Connection flag to false.

Ports

In a Linux environment, the ports with numbers under 1024 are system ports reserved for system services. Only a root user has the rights to use these ports. This is why, if you are not a root user, you will have either to set a port over 1024 as a primary port or use the secondary port for HTTP connection.

Encoding

Different virtual machines prefer different IDs for character encoding. If the HTTP Server cannot generate correct responses and reports an error, that the current VM does not support the encoding defined by the mbs.http.encoding property, then the value of mbs.http.encoding should be changed. Contact the documentation of the virtual machine to get the identifier of the ISO 8859_1 character encoding. It may be ISO8859_1, 8859_1, 8859-1, etc. Another way to get the ID is to inspect the archive of the virtual machine's base class library, whenever it is available, for sun.io.ByteToChar<ID>.class.