Server node threads perform server node request processing. (Each application running in JADE is executed on its own thread and each thread effectively runs as a standalone Windows program.)
JADE provides flexibility in configuring a multiuser JADE application environment by enabling you to specify the:
Minimum and maximum number of server node, short, and long threads
This provides an application administrator with full control of how much resource the server node can use and when new resource is activated.
When a non‑GUI application thread fails to respond within 45 seconds, JADE attempts to interrupt the processing of that thread, waits for another 10 seconds, and then terminates the thread. See also "Note about Shutting Down a Database Server Node", in the following subsection.
Active users are calculated from the total of all JADE application instances on all JADE client nodes plus one additional system user for each JADE client node. For example, running one JADE development client node counts as two active users; that is, one for the JADE development application and one for the system user. Similarly, a client node running a deployed JADE application counts as two active users. If both these JADE client nodes run at the same time, you use a total of four active users. However, when running the same deployed JADE application from within another JADE application (for example, the development environment), you use two users for JADE application instances plus one system user, totaling three.
JADE’s flexible approach to distributed processing provides scalable applications that maximize the utilization of the available hardware resources. A scalable system enables you to minimize potential bottlenecks, both physical and logical.
Two or more processes can communicate independently with the server node, as there is one logical connection for each node process.
The maximum number of server methods that can execute concurrently is limited to the number of long threads available on the server node.
If an exception handler is armed in the executing node and an exception is raised, it is handled in the executing node. If no exception handler is armed in the executing node, the exception is reported back to the invoking node for exception handling.