Provided by: aolserver4-dev_4.5.1-18.1_amd64 bug

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