NAME¶
ns_proxy - Proxy-process Tcl interface
SYNOPSIS¶
ns_proxy active pool
ns_proxy cleanup
ns_proxy config pool ?-opt val -opt val ...
ns_proxy eval handle script ?timeout?
ns_proxy get pool ?-handle n -timeout ms?
ns_proxy ping handle
ns_proxy release handle
ns_proxy recv handle
ns_proxy send handle script
ns_proxy wait handle ?timeout?
DESCRIPTION¶
This command provides a simple, robust proxy mechanism to evaluate Tcl scripts
in a separate, pipe-connected process. This approach can be useful both to
isolate potentially thread-unsafe code outside the address space of a
multithreaded process such as AOLserver or to enable separation and timeout of
potentially misbehaving, long running scripts.
The command is provided by the
nsproxy dynamic library which can be
loaded into an interpreter via the Tcl
load command, for example:
load /usr/local/lib/libnsproxy.so
ns_proxy ...
It can also possible to load the library into all interpreters of an AOLserver
virutal server by specifying an
nsproxy.so entry in the server's module
config entry, for example:
ns_section ns/server/server1/modules
ns_param nsproxy nsproxy.so
When loaded, the library adds the single
ns_proxy command with takes
multiple options as described below. Proxies are normally created on demand
when requested and connected to the parent process via pipes used to send
scripts and receive response. The processes remain active until the parent
process exits, effectively closing all pipes to the slave processes.
- ns_proxy active pool
- Returns a list of all currently evaluating scripts in proxies for the
given pool. The output is a list which includes two elements, the
string name of the proxy handle and the string for the script being
executed. It is also possible to view the currently evaluating scripts
with the Unix ps command as the proxy slave process re-writes it's
command argument space with the request script before evaluation and
clears it after sending the result.
- ns_proxy cleanup
- Releases any handles from any pools currently owned by a thread. This
command is intended to be used as part of a garbage collection step at the
end of a transaction. Calling this command within AOLserver is not
necessary as the module registers a trace to release all handles via the
Ns_TclRegisterTrace facility when interpreters are deallocated
after a transaction, for example, at the end of a connection.
- ns_proxy config pool ?-opt val -opt val ...
- Configures options for the pool specified by pool. The pool is
created with default options if it does not already exist. The result of
ns_proxy config is a list of the current options in the form
-opt val -opt val .... Configurable options include:
- -init script
- Specifies a script to evaluate when proxies are started. This can be used
to load additional libraries and/or source script files. The default is no
script.
-
-reinit script
- Specifies a script to evaluate after being allocated and before being
returned to the caller. This can be used to re-initalizes shared state.
The default is no script.
-
-min n
- Sets the minimum number of proxy slave processes to pre-start before any
allocations. This defaults to 0 which results in on-demand start the first
time proxies are requested. Setting it to a higher number can be useful if
initialization takes a significant amount of time.
-
-max n
- Sets the maximum number of proxy slave processes. Requests for proxies
beyond the maximum will result in requesting threads waiting for existing
proxies to be available instead of creating new proxy processes. Setting
this value to 0 disables the pool, causing all subsequent allocation
requests to fail immediately (currently allocated proxies, if any, remain
valid).
-
-exec program
- Specifies the filename of a slave proxy program. This defaults to
nsproxy in the bin subdirectory of the AOLserver process. It
is possible to create a custom program and enter the proxy event loop with
the Ns_ProxyMain application startup routine; see the source code
for details.
- -getimeout ms
- Specifies the maximum time to wait to allocate handles from the pool. The
default is 500 milliseconds, i.e., 1/2 of a second.
-
-evaltimeout ms
- Specifies the maximum time to wait for a script to be evaluated in a
proxy. This parameter can be overridden on a per-call basis with the
optional timeout parameter to ns_proxy eval. The default is
100 milliseconds, i.e., 1/10 of a second which assumes scripts are
evaluated with minimal delay.
-
-sendtimeout ms
-
-recvtimeout ms
- Specifies the maximium time to wait to send a script and receive a result
from a proxy. The default is 100 milliseconds, i.e., 1/10 of a second
which assumes minimal delay sending and receiving reasonably sized scripts
and results over the connecting pipe.
- -waittimeout ms
- Specifies the maximum time to wait for a proxy to exit. The wait is
performed in a dedicated reaper thread. The reaper will close the
connection pipe and wait the given timeout. If the timeout is exceeded,
the reaper will send a SIGTERM signal and finally a SIGKILL signal to
ensure the process eventually exits. The default is 100 milliseconds which
should be ample time for a graceful exit unless the process is hung
executing a very long, misbehaving script, resulting in a more disruptive
SIGTERM or SIGKILL.
- ns_proxy eval handle script ?timeout?
- Evalutes script in the proxy specified by handle. The
optional timeout argument specifies a maximum number of
milliseconds to wait for the command to complete before raising an error
(see ERROR HANDLING below for details on handling errors).
- ns_proxy send handle script
- Sends script in the proxy specified by handle. Unlike with
ns_proxy eval, this option will return immediately while the script
continues to execute in the proxy process. A later ns_proxy wait
followed by an ns_proxy recv is expected.
- ns_proxy wait handle ?timeout?
- Waits for a script sent via ns_proxy send in the proxy specified by
the handle argument to complete. The optional timeout
parameter specifies the number of milliseconds to wait for the script to
complete, the default is an indefinite wait.
- ns_proxy recv handle
- Receives a response from a script that was sent via ns_proxy
send and waited on via ns_proxy wait.
- ns_proxy get pool ?-handle n -timeout ms? Returns one
or
- more handles to proxies from the specified pool. The pool will be
created with default options if it does not already exist. The optional
-handle n arguments can be used to specify the number of handles to
allocate, the default being 1. The optional -timeout ms arguments
specifies the maximum amount of time in milliseconds to wait for the
handles to become availale before raising an error (see ERROR
HANDLING below for details on handling errors). Requesting more than
one handle in a single call if more than one handle is required is
necessary as it is an error to request handles from a pool from which
handles are already owned in the thread. This restriction is to avoid a
possible deadlock condition and is similar to the manner in which the
ns_db gethandles command operates.
- ns_proxy ping handle
- This command sends a null request to the proxy specified by the
handle argument. The proxy will be verified alive and restarted if
necessary. This command is not normally required as the ns_proxy
eval command will also verify and restart proxies as needed.
- ns_proxy release handle
- This command can be used to release a single proxy specified by the
handle argument. All handles owned by a thread to the cooresponding
pool must be returned before any handles can be allocated again. Within
AOLserver, a call to this routine is recommended for clarity but not
stricting necessary. As described above, AOLserver installs a trace to
release all handles at the end of every connection during interprepter
deallocation.
ERROR HANDLING¶
Errors generated by a script evaluated in a proxy interpreter are completely
returned to the calling interpreter, including mapping the
errorInfo
and
errorInfo global variables from the proxy to the parent if present
and raising a Tcl exception. This enables proxy code to look very similar to
that which may use the internal
eval command.
Errors raised by a failure to communicate with the proxy process due to a
timeout or unexpected process exit are also communicated back to the parent
interpreter as Tcl exceptions. To distinguish between these cases,
communication related errors set the
errorCode global variable with the
first element
NSPROXY. The second element is one of the following:
- EDeadlock
- The interpreter attempted to allocate handles from a pool from which it
already owns one or more handles.
- EExec
- The slave program specified by the -exec program option could not
be started.
- ERange
- Insufficient handles available in pool.
- ERecv
- There was an error receiving the result from the slave process.
- ESend
- There was an error sending the script to the slave process.
- ETimeout
- The timeout specified for the pool by the -evaltimeout option or as
the optional argument to the current call to ns_proxy eval
was exceeded.
EXAMPLES¶
The following demonstrates sending a script to a remote proxy:
set handle [ns_proxy get myproxy]
ns_proxy eval $handle {info patchlevel}
ns_proxy release $handle
The following demonstrates an asyncronous request:
set handle [ns_proxy get myproxy]
ns_proxy send $handle {long running script}
... continue other work ...
ns_proxy wait $handle
set result [ns_proxy recv $handle]
ns_proxy release $handle
The following demonstrates using multiple proxies:
ns_proxy config myproxy -max 10
set handles [ns_proxy get myproxy -handle 10]
foreach h $handles {
ns_proxy eval $h {puts "alive: [pid]"}
}
ns_proxy cleanup
SEE ALSO¶
eval(n)
KEYWORDS¶
threads, interpreters, proxy, initialization
