Date: 2004-02-22T10:21:09 Editor: JeremyBoynes <[EMAIL PROTECTED]> Wiki: Apache Geronimo Wiki Page: Architecture/WorkManager URL: http://wiki.apache.org/geronimo/Architecture/WorkManager
no comment New Page: This page describes the mechanisms in Geronimo that are used to control and schedule the application workload = Worker Pools = J2EE has a synchronous processing model where Java Threads are used to provide the processing context for a request. As a result, application work can be characterized as relatively long running with blocking. In other words, application work such as a Servlet request or EJB invocation runs on a single thread for a relatively long time, cannot be transfered to another thread (due to context on the stack), and occasionally blocks for extended periods (seconds) e.g to talk to a database or perform disk I/O. Invokers in Geronimo responsible for initiating application work should obtain a Thread from an external Worker Pool. This allows System Administrators to manage the thread resources available on the system for consumption by application work. On larger systems, System Administrators should be able to create multiple pools as needed; for example, to limit the number of OS threads used by the application server, or to affinity threads to specific hardware resources (note this may need platform specific extensions). Examples of such invokers are: * EJB invokers for transports such as RMI, IIOP, HTTP * Servlet invokers * Resource Adapters * EJB Timer Service * Web Service Invoker Other less obvious examples include: * HTTP Session passifier (which may need to dump large amounts of state to disk) * Stateful Session passifier (again, saving state) * Cluster state redistribution * Application distribution (copying the app during deployment) The size of a worker pool is relatively larger and determined by factors such as the number of available processors, the amount of concurrency in the appplication, and the amount of time a thread spends blocked. = Event Pools = Geronimo also has a need for rapid processing in response to events such as timer expirations, operator interactions or network notifications. This workload can be characterizes as short term and non-blocking. In other words it runs for a few micro or milliseconds and does not block for external resources such as databases or disks. Such a thread may be used to schedule workers; for example, it may determine a series of longer running tasks that need to be performed and then assign them to a work queue for processing by workers. System administrators may wish to allocate such threads to specific resources, or may wish to raise the priority of these threads to ensure system housekeeping can still be performed should the worker pool be overloaded. Again, such operations may need platform specific extensions. The size of a worker pool is likely to be relatively small and fairly independent of application workload. = Use Case = The passivation process for Stateful Session Beans can be used as a use case for these pools. To improve performance, instances may be retained in memory between transaction; however, the container is responsible for discarding the instance if the client abandons it. In one possible implementation of this, the container would register a timer event that would periodically fire. When the timer expires, a Thread would be selected from the event pool and used to notify the stateful session container. The container would use this thread to determine which, if any, instances needed to be passivated and would enqueue worker tasks to actually passify them; the event thread would then be returned to the event pool. The passivation tasks, which are longer running and may block on disk I/O, would then be scheduled from the worker pool. Note this is illustrative and not intended as a description of how SFSB passivation actually works in Geronimo.
