内に含まその他のドキュメントサポート リソース |  PDF 文書ファイルをダウンロードする (1957 KB)
Chapter 5 Predefined SAFs in magnus.confThis chapter lists the Init Server Application Functions (SAF) that you can specify in magnus.conf. Init SAFs load and initialize server modules and NSAPI plug-ins. Note – When you edit the magnus.conf file, you must restart the server for the changes to take effect. The following topics are described in detail in this chapter: Init SAFsThe Init directives are executed only once at server startup. Each Init directive has an fn parameter that specifies which Init SAF to invoke. Each Init directive has an optional LateInit parameter. For the UNIX platform, if LateInit is set to Yes, the function is executed by the child process after it is forked from the parent. If LateInit is set to No or is not provided, the function is executed by the parent process before the fork. For the Windows platform, LateInit functions are executed later than functions that do not have the LateInit parameter. When the server is started by a root user but runs as another user, perform all activities that must be performed as the user root (such as writing to a root-owned file) before the fork. Functions that create threads, with the exception of thread-pool-init, should be executed after the fork, that is, the relevant Init directive should have LateInit=yes set. This section describes the following SAFs: cindex-initThe cindex-init function sets the default settings for common indexing. Common indexing (also known as fancy indexing) is performed by the Service function index-common. Indexing occurs:
This function is applicable in Init-class directives. In common (fancy) indexing, the directory list shows the name, last modified date, size, and description of each indexed file or directory. ParametersThe following table describes the cindex-init parameters. Table 5–1 cindex-init Parameters
ExampleInit fn="cindex-init" widths="50,1,1,0" Init fn="cindex-init" ignore="*private*" Init fn="cindex-init" widths="22,0,0,50" define-perf-bucketThe define-perf-bucket function creates a performance bucket, which you can use to measure the performance of SAFs in obj.conf. This function is applicable in Init-class directives. For more information about performance buckets, see Sun Java System Web Server 7.0 Performance Tuning, Sizing, and Scaling Guide. ParametersThe following table describes the define-perf-bucket parameters. Table 5–2 define-perf-bucket Parameters
ExampleInit fn="define-perf-bucket" name="cgi-bucket" description="CGI Stats" init-davThe init-dav function performs initialization tasks to load the WebDAV plug-in. This function is applicable in Init-class directives. ExampleInit fn="load-modules"
shlib="libdavplugin.so"
funcs="init-dav,ntrans-dav,service-dav"
Init fn="init-dav"
init-filter-orderThe init-filter-order function controls the position of specific filters within the filter stacks. For example, you can use init-filter-order to ensure that a filter that converts outgoing XML to XHTML is inserted above a filter that converts outgoing XHTML to HTML. This function is applicable in Init-class directives. Filters that appear higher in the filter stack are given the first opportunity to process outgoing data, and filters that appear lower in the filter stack are given the first opportunity to process incoming data. The appropriate position of a specific filter within the filter stack is defined by the filter developer. For example, filters that translate content from XML to HTML are placed higher in the filter stack than filters that compress data for transmission. Filter developers use the filter-create function to define the filter's position in the filter stack. You can use init-filter-order to override the position defined by the filter developer. When two or more filters are defined to occupy the same position in the filter stack, filters that were inserted later will appear higher than filters that were inserted earlier. That is, the order of Input fn="insert-filter" and Output fn="insert-filter" directives in obj.conf becomes important. For example, consider two filters, xhtml-to-html and xml-to-xhtml, which convert XHTML to HTML and XML to XHTML, respectively. As both these filters transform data from one format to another, they may be defined to occupy the same position in the filter stack. To transform XML documents to XHTML and then to HTML before sending the data to the client, Output fn="insert-filter" directives in obj.conf should appear in the following order: Output fn="insert-filter" filter="xhtml-to-html" Output fn="insert-filter" filter="xml-to-xhtml" In general, you should use the order of Input fn="insert-filter" and Output fn="insert-filter" directives in obj.conf to control the position of filters in the filter stack. init-filter-order should only be used to address specific filter interoperability problems. Note – The load-module function that creates the filters should be called before init-filter-order attempts to order them. ParametersThe following table describes the init-filter-order parameter. Table 5–3 init-filter-order Parameter
ExampleInit fn="init-filter-order" filters="xml-to-xhtml,xhtml-to-html,http-compression" init-request-limitsThe init-request-limits function works with the obj.conf function check-request-limits to monitor incoming requests with a given attribute. check-request-limits maintains a table of monitored values. intit-request-limits purges existing entries in that table according to the timeout. This function is not required unless you want to override the default value for the purge timeout in check-request-limits. For more information, see check-request-limits. The default is 300 seconds (five minutes). This function is applicable in Init-class directives. ParametersThe following table describes the init-request-limits parameter. Table 5–4 init-request-limits Parameter
ExampleInit fn="init-request-limits" timeout="120" init-uhome(UNIX only) The init-uhome function loads information about the system’s user home directories into internal hash tables. This function slightly increases memory usage, but improves performance for servers that have a lot of traffic to home directories. This function is applicable in Init-class directives. ParametersThe following table describes the init-uhome parameter. Table 5–5 init-uhome Parameter
ExampleInit fn="init-uhome" Init fn="init-uhome" pwfile="/etc/passwd-http" load-modulesThe load-modules function loads a shared library or dynamic-link library (DLL) into the server. Specified functions from the library can then be executed from any subsequent directives. Use this function to load new plug-ins or SAFs. This function is applicable in Init-class directives. If you define your own SAFs, load them by using the load-modules function and specify the shared library or DLL to load. ParametersThe following table describes the load-modules parameters. Table 5–6 load-modules Parameters
ExamplesInit fn="load-modules" shlib="C:/mysrvfns/corpfns.dll" funcs="moveit" Init fn="load-modules" shlib="/mysrvfns/corpfns.so" funcs="myinit,myservice" Init fn="myinit" pool-initThe pool-init function changes the default values of pooled memory settings. You can change the size of the free block list, or disable pooled memory entirely. This function is applicable in Init-class directives. ParametersThe following table describes the pool-init function parameters. Table 5–7 pool-init Parameters
ExampleInit fn="pool-init" disable="true" register-http-methodThe register-http-method function enables you to extend the HTTP protocol by registering new HTTP methods. This function is applicable in Init-class directives. While accepting a connection, the server checks if the method it received is known to it. If the server does not recognize the method, it returns a 501 Method Not Implemented error message. ParametersThe following table describes the register-http-method parameters. Table 5–8 register-http-method Parameters
ExampleThe following example shows the use of register-http-method: Init fn="register-http-method" methods="MY_METHOD1,MY_METHOD2" The methods can be called from a Service function in obj.conf, for example: Service fn="MyHandler" method="MY_METHOD1" thread-pool-initThe thread-pool-init function creates a new pool of user threads. A pool must be declared before it is used. For a plug-in to use the new pool, specify the pool parameter when loading the plug-in with the Init-class function load-modules. For more information, see load-modules. This function is applicable in Init-class directives. One reason to create a custom thread pool would be if a plug-in is not thread-aware, in which case you can set the maximum number of threads in the pool to 1. The older parameter NativeThread=yes always engages one default native pool, called NativePool. The native pool on UNIX is normally not engaged, as all threads are kernel-level threads. In addition, native thread pool parameters can be added to the magnus.conf file for convenience. For more information, see Chapter 4, Syntax and Use of magnus.conf. ParametersThe following table describes the thread-pool-init parameters. Table 5–9 thread-pool-init Parameters
ExampleInit fn="thread-pool-init" name="my-custom-pool"
minthreads="1" maxthreads="5" queuesize="200"
Init fn="load-modules" shlib="myplugin.dll" funcs="tracker"
pool="my-custom-pool"
Common SAFsYou can call some SAFs from Init in magnus.conf as well as from ObjectType directives in obj.conf. These SAFs are documented in Chapter 7, Predefined SAFs and Filters in obj.conf, as referenced below: Deprecated Init SAFsThe following magnus.conf Init SAFs are deprecated for Sun Java System Web Server 7.0. Table 5–10 List of Deprecated Init SAFs
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|