Dynamic Reactor Pattern for Distributed Systems in Control and Monitoring
Architectural pattern: Reactor
6
Architectural pattern: Reactor • Source: POSA II pp 179 – 214 • Environment: an application that receives multiple requests simultaneously but may process them synchronously and serially • Problem: – Application cannot block, waiting for requests from one client and starve the others – Application cannot afford thread-per- client
description
Architectural pattern: Reactor. Source: POSA II pp 179 – 214 Environment: an application that receives multiple requests simultaneously but may process them synchronously and serially Problem: Application cannot block, waiting for requests from one client and starve the others - PowerPoint PPT Presentation
Transcript of Architectural pattern: Reactor
Architectural pattern: Reactor
• Source: POSA II pp 179 – 214• Environment: an application that receives
multiple requests simultaneously but may process them synchronously and serially
• Problem: – Application cannot block, waiting for requests
from one client and starve the others– Application cannot afford thread-per-client
(Core of a) solution - reactors• Event handler knows how to process events (such
as session start, service request) related to the application. Event handlers register with the Reactor.
• Reactor manages registered event handlers and handles (operating-system supplied handles). When an event arrives, the Reactor dispatches it to the appropriate event handler.
• Synchronous event demultiplexer waits for events to occur, and notifies the Reactor when there are events ready for processing. Examples: select() in UNIX, WaitForMultipleObjects() in Win32.
Dynamics1. Application registers concrete event handlers and the
type of events each should handle with the Reactor.
2. Application invokes the Reactor’s handle_events() method, which starts the “event loop”
3. Reactor calls the synchronous event demultiplexer.
4. When events are available, demultiplexer returns to the Reactor.
5. Reactor determines the appropriate event handler and dispatches the event to it.
6. Event handler does the work.
7. Reactor continues at step 3.
Implementation1. Define the event handler interface
• Dispatch to objects or functions?• Single method or method-per-event-type?
2. Define the reactor interface• Does the event source come from the handler or the
registration call?
3. Implement the reactor• Includes picking the demultiplexer
4. Determine the number of reactors required5. Implement the concrete event handlers
• Includes deciding how to maintain state when needed
Known uses
• InterViews
• Xt toolkit
• ACE Reactor Framework
• Several CORBA ORB Core implementations
• Call Center management
• Non-software: receiving phone calls
Consequences• Benefits
– Separation of concerns– Modularity, reusability, configurability– Portability– Concurrency control (coarse grained)
• Liabilities– Restricted applicability (requires select() or
equivalent)– Non-preemptive– Complexity in testing and debugging
