This section provides a description of the operation of the TCP server. The TCP server is responsible for accepting .NET Remoting requests over TCP/IP.
The TCP server is part of the J-Integra® for .NET runtime. When operating as a TCP server, J-Integra® for .NET is usually started with a command such as:
java -classpath $USER_INSTALL_DIR$\lib\janet.jar;. com.intrinsyc.janet.Main
Once J-Integra® for .NET is started, a TCP server instance is created for each unique port number configured for local objects using the TCP/IP protocol (local objects with a URI starting with "tcp://"). For example, if four local objects are configured with these URIs:
then two TCP server instances are started: one to listen on port 5555 and one to listen on port 5556.
Each TCP server instance listens on its assigned port. As connection requests are made to that port, the server immediately accepts and stores the requests in its "request queue". These accepted, queued connection requests are removed from the queue by a pool of worker threads.
If the request queue ever becomes full (exceeds its configured maximum size), new connection requests will be discarded, resulting in client failures.
Each TCP server instance manages a pool of "worker" threads for servicing .NET Remoting requests. Requests are taken from the request queue and assigned to available worker threads. Each worker thread services its assigned request to completion before becoming available again. For example, a thread with a newly assigned request might read a request for a method call, invoke the method, and write back the response.
The thread pool can "grow" in response to usage, up to the configured thread pool maximum size. That is, new worker threads will be added to the pool when there is a shortage of available worker threads.
The thread pool can also "shrink", down to the configured thread pool minimum size. Surplus worker threads - threads that are not servicing requests - will be stopped and removed from the pool. Note however that threads are never stopped as soon as they become available: the TCP server waits for the configured "idle interval" to make sure that a surplus thread remains idle before stopping it and removing it from the pool.
All of the configuration parameters related to the TCP server are stored in the J-Integra® for .NET configuration file (janet.xml) and can be modified with Janetor. See the Janetor page for a description of each parameter.
The default configuration parameters for the TCP server are appropriate for many situations. However, many load testing and production scenarios will benefit from modifications.
Here are some tips:
Don't use too many threads. As a general rule, restrict threads to two or three times the number of CPUs in the server. If method calls on your server objects result in a lot of idle time, a larger factor will be warranted. But don't get carried away: Each thread will consume memory and may compete with other threads for other resources, reducing throughput.
If some client connections are being refused under high load, enable J-Integra® for .NET's error logging, and check the log file. If an error such as "request queue full" is reported, try increasing the maximum request queue configuration parameter. If no errors are reported, try increasing the TCP backlog parameter.
Do not make the thread pool's idle interval too short. If it is, and usage is sporadic, the TCP server will waste resources starting and stopping worker threads all the time. A value of at least 15 seconds is recommended.
|
© 2007 Intrinsyc Software International, Inc. All rights reserved. Legal |