Server Smalltalk Guide
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.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]