Dispatchers
In contrast to invocation handlers, which have rather fixed behaviors, dispatchers are pluggable policy objects which describe how messages are sent and processed by an invocation handler. Their major protocol includes the following methods:
dispatchIncoming: request
Dispatches the incoming @request to its intended receiver according to the policies of the receiver. It is expected that request processing includes sending any required responses.
sendEarlyReply: value to: request continuation: continuation
Sends @value as an early reply to @request. An early reply is defined as a reply done before the method invoked as a result of dispatching @request has returned. @continuation is a zero argument block containing the code which should be executed after @value is replied. Returns an error if one should occur.
sendReply: value to: request
Sends @value in reply to @request. If an error occurs, replies an error value to the origin of @request (its sender) and returns the error from this method. In the event that an error occurs while trying to send the error reply, simply returns an error from this method. If a reply of any sort is actually sent then @request is marked as having been answered.
sendRequest: request to: endpoint
Sends @request to @endpoint for processing and return the result if one is required. It is assumed that @endpoint represents some remote location. Returns an error if one should occur.
You are free to build and use new kinds of dispatchers which override these methods to provide different behavior. As useful examples, SST provides a number of different dispatchers:
SstImmediateDispatcher
Incoming messages, both requests and replies, are processed using the active process (Processor activeProcess). If the invocation handler is active, the handler's server process is used, otherwise the user's process is used. This is the default dispatcher.
SstThreadedDispatcher
A new process is forked to handle each new request. Replies are handled by the active process.
SstPooledDispatcher
A process is pulled from a pool of available processes and asked to handle the request. Replies are handled by the active process. Pooled dispatchers have a high and low water mark for the pool of processes they use to handle requests. They also support a strictness setting. When in strict mode they guarantee to ensure that the number of processes used will always be between the high and low marks. With non-strict dispatchers, the high and low marks control the number of processes managed. That is, the number of processes may temporarily go above the high mark but when handling of that request is completed, the process used is destroyed.
In strict mode it is possible to deadlock the system if there are not enough processes to handle all messages in one dependency chain. Users with highly recursive algorithms should either not use strict mode or ensure that this upper bound is high enough for their use.
SstLPDispatcher
As part of the mechanisms for supporting Logical Processes, outgoing messages are tagged with an indication of the local process which caused the message to be sent (the active process). Incoming requests are checked for process tags and if found, the dispatcher attempts to process the message on the corresponding process. Replies are handled by the active process. For more information see Logical process invocation.
Whether or not message senders block waiting for a reply depends on the setting in the sent request's replyReceiver field. See Requests for more information.
Replies are normally executed on whichever process happened to ask the invocation handler to process the next request. If the handler is active, this process is the handler's serverProcess. Otherwise, it is some application process.
Last modified date: 04/21/2020