sample.reg

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;           omniORB (4.0 or above) configuration file                      ;
;                                                                          ;
; To add the entries in this file to the registry, run the command:        ;
;      regedit sample.reg                                                  ;
;                                                                          ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;                                                                          ;
;            ORB wide options                                              ;
;                                                                          ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Tracing level
;     level 0 - critical errors only
;     level 1 - informational messages only
;     level 2 - configuration information and warnings
;     level 5 - the above plus report server thread creation and
;               communication socket shutdown
;     level 10 - the above plus execution trace messages
;     level 25 - output trace message per send or receive giop message
;     level 30 - dump up to 128 bytes of a giop message
;     level 40 - dump the complete giop message
;
;     Valid values = (n >= 0)
;
;"traceLevel" = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Trace Exceptions
;     If true, then system exceptions will be logged when they are thrown.
;
;     Valid values = 0 or 1
;
"traceExceptions" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Trace Invocations
;     If true, then each local and remote invocation will generate a trace 
;     message.
;
;     Valid values = 0 or 1
;
"traceInvocations" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Trace Invocation returns
;     If true, then each local and remote invocation will generate a trace 
;     message as it returns.
;
;     Valid values = 0 or 1
;
traceInvocationReturns = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Trace thread id
;     If true, all trace messages include the thread id of the thread doing
;     the logging.
;
;     Valid values = 0 or 1
;
traceThreadId = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Trace time
;     If true, all trace messages include the current time.
;
;     Valid values = 0 or 1
;
traceTime = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; dumpConfiguration
;     Set to 1 to cause the ORB to dump the current set of configuration
;     parameters.
;
;     Valid values = 0 or 1
;
"dumpConfiguration" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; maxGIOPVersion
;
;   Set the maximum GIOP version the ORB should support. The ORB tries
;   to match the <major>.<minor> version as specified. This function
;   should only be called before ORB_init(). Calling this function
;   after ORB_init()  does not cause the ORB to change its maximum
;   supported version; in this case the ORB just returns its version
;   number in <major>.<minor>.
;
;   Valid values = 1.0 | 1.1 | 1.2
;
"maxGIOPVersion" = "1.2"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; giopMaxMsgSize
;
;    This value defines the ORB-wide limit on the size of GIOP message 
;    (excluding the header). If this limit is exceeded, the ORB will
;    refuse to send or receive the message and raise a MARSHAL exception.
;
;    Valid values = (n >= 8192)
;
"giopMaxMsgSize" = "2097152"
; 2 MBytes.


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; strictIIOP flag
;    Enable vigorous check on incoming IIOP messages
;
;    In some (sloppy) IIOP implementations, the message size value in
;    the header can be larger than the actual body size, i.e. there is
;    garbage at the end. As the spec does not say the message size
;    must match the body size exactly, this is not a clear violation
;    of the spec.
;
;    If this flag is non-zero, the incoming message is expected to
;    be well behaved. Any messages that have garbage at the end will
;    be rejected.
;    
;    The default value of this flag is true, so invalid messages are
;    rejected. If you set it to zero, the ORB will silently skip the
;    unread part. The problem with this behaviour is that the header
;    message size may actually be garbage, caused by a bug in the
;    sender's code. The receiving thread may block forever on the
;    strand as it tries to read more data from it. In this case the
;    sender won't send any more as it thinks it has marshalled in all
;    the data.
;
;    Valid values = 0 or 1
;
"strictIIOP" = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; lcdMode
;
;   Set to 1 to enable 'Lowest Common Denominator' Mode.
;   This will disable various features of IIOP and GIOP which are
;   poorly supported by some ORBs, and disable warnings/errors when
;   certain types of erroneous message are received on the wire.
;
;   Valid values = 0 or 1
;
"lcdMode" = "0"



;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; tcAliasExpand flag
;
;    This flag is used to indicate whether TypeCodes associated with Anys
;    should have aliases removed. This functionality is included because
;    some ORBs will not recognise an Any containing a TypeCode with
;    aliases to be the same as the actual type contained in the Any. Note
;    that omniORB will always remove top-level aliases, but will not remove
;    aliases from TypeCodes that are members of other TypeCodes (e.g.
;    TypeCodes for members of structs etc.), unless tcAliasExpand is set to 1.
;    There is a performance penalty when inserting into an Any if 
;    tcAliasExpand is set to 1. The default value is 0 (i.e. aliases of
;    member TypeCodes are not expanded). Note that aliases won't be expanded
;    when one of the non-type-safe methods of inserting into an Any is
;    used (i.e. when the replace() member function or non - type-safe Any
;    constructor is used. )
;
;     Valid values = 0 or 1
;
"tcAliasExpand" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; useTypeCodeIndirections
;
;    If true (the default), typecode indirections will be used. Set
;    this to false to disable that. Setting this to false might be
;    useful to interoperate with another ORB implementation that cannot
;    handle indirections properly.
;   
;    Valid values = 0 or 1
"useTypeCodeIndirections" = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; acceptMisalignedTcIndirections
;
;    If true, try to fix a mis-aligned indirection in a typecode. This
;    could be used to work around some versions of Visibroker's Java ORB.
;   
;    Valid values = 0 or 1
"acceptMisalignedTcIndirections" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; scanGranularity
;
;   The granularity at which the ORB scan for idle connections.
;   This value determines the minimum value that inConScanPeriod or
;   outConScanPeriod can be implemented.
;
;   Valid values = (n >= 0 in seconds) 
;                   0 --> do not scan for idle connections.
;
"scanGranularity" = "5"


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; nativeCharCodeSet
;
;   set the native code set for char and string
;
"nativeCharCodeSet" = "ISO-8859-1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; nativeWCharCodeSet
;
;   set the native code set for wchar and wstring
;
"nativeWCharCodeSet" = "UTF-16"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; abortOnInternalError
;
;   If the value of this variable is TRUE then the ORB will abort
;   instead of throwing an exception when a fatal internal error is
;   detected. This is useful for debuging the ORB -- as the stack will
;   not be unwound by the exception handler, so a stack trace can be
;   obtained.
;   It is hoped that this will not often be needed by users of omniORB!
;
;   Valid values = 0 or 1
;
"abortOnInternalError" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; abortOnNativeException
;
;   On Windows, "native" exceptions such as segmentation faults and
;   divide by zero appear as C++ exceptions that can be caught with
;   catch (...). Setting this parameter to TRUE causes such exceptions
;   to abort the process instead.
;
;   This parameter has no effect on other platforms.
;
;   Valid values = 0 or 1
;
"abortOnNativeException" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; maxSocketSend
; maxSocketRecv
;
;   On some platforms, calls to send() and recv() have a limit on the
;   buffer size that can be used. These parameters set the limits in
;   bytes that omniORB uses when sending / receiving bulk data.
;
;   The default values are platform specific. It is unlikely that you
;   will need to change the values from the defaults.
;
;   The minimum valid limit is 1KB, 1024 bytes.
;
;   e.g. to limit to 64KB sends / receives:
;
;     "maxSocketSend" = "65536"
;     "maxSocketRecv" = "65536"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; socketSendBuffer
;
;   On Windows, there is a kernel buffer used during send operations.
;   A bug in Windows means that if a send uses the entire kernel
;   buffer, a select() on the socket blocks until all the data has
;   been acknowledged by the receiver, resulting in dreadful
;   performance. This parameter modifies the socket send buffer from
;   its default (8192 bytes on Windows) to the value specified. If
;   this parameter is set to -1, the socket send buffer is left at the
;   system default.
;
;   On Windows, the default value of this parameter is 16384 bytes; on
;   all other platforms the default is -1.
;
;     "socketSendBuffer" = "-1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; validateUTF8
;
;   When transmitting a string that is supposed to be UTF-8, omniORB
;   normally passes it directly, assuming that it is valid. With this
;   parameter set TRUE, omniORB checks that all UTF-8 strings are
;   valid, and throws DATA_CONVERSION if not.
;
;   Valid values = 0 or 1
;
"validateUTF8" = "0"


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; sslCAFile
; sslKeyFile
; sslKeyPassword
; sslVerifyMode
;
;   SSL transport options
;
;   sslCAFile specifies the file containing the SSL Certificate
;   Authority certificate.
;
;   sslKeyFile specifies the file containing the SSL key.
;
;   sslKeyPassword specifies the password to unlock the key.
;
;   sslVerifyMode specifies the verify mode, as given to
;   SSL_CTX_set_verify. Valid values are "none", representing
;   SSL_VERIFY_NONE, and "peer", representing SSL_VERIFY_PEER. If peer
;   is selected, additional options "fail" and "once" can also be
;   specified, corresponding to SSL_VERIFY_FAIL_IF_NO_PEER_CERT and
;   SSL_VERIFY_CLIENT_ONCE respectively. e.g.
;
;     "sslVerifyMode" = "peer,fail"
;
;   These options are only available if the SSL transport is linked.



;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;                                                                          ;
;            Client Side Options                                           ;
;                                                                          ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; InitRef
;
;   Specify the IOR the ORB should return in response to a call to
;   resolve_initial_references.
;
;   There can be more than one configuration line defining InitRef.
;   Each line adds one initial reference to the ORB.
;
;   Here are some valid examples:
;
;   Specify the root context of the Naming Service.
;
; [HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\InitRef]
; "0"="NameService=IOR:010000002800000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578743a312e300001000000000000002c000000010102000c0000003139322e3136382e312e3000f90a00000c000000349568c45cb1e6780000000100000000"
;
;   Alternatively, and more cleanly, specify the Naming service with a
;   corbaname URI:
;
; "0"="NameService=corbaname::my.host.name"
;
;
;   Specify the Trading service and the interface repository using corbaloc:
;
; [HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\InitRef]
; "1" = "TradingService=corbaloc:iiop:marrow:5009/MyObjectKey"
; "2" = "InterfaceRepository=corbaloc::1.2@marrow:5009/Intf"
;
;   The default for the set of initial references is empty.
[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\InitRef]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; DefaultInitRef
;
;   DefaultInitRef provides a prefix string which is used to resolve 
;   otherwise unknown names. When resolve_initial_references() is unable to 
;   resolve a name which has been specifically configured (with InitRef),
;   it constructs a string consisting of the default prefix, a `/' character,
;   and the name requested. The string is then fed to string_to_object().
;   For example, if DefaultInitRef is set up like this:
;      DefaultInitRef = corbaloc::myhost.example.com
;   A call to resolve_initial_references("MyService") will return the object
;   reference denoted by `corbaloc::myhost.example.com/MyService'.
;
;   The default is empty.
[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\DefaultInitRef]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; clientTransportRule
;
;    When the client receives an IOR that defines 1 or more ways to contact
;    the server, the rules in clientTransportRule filter and prioritise
;    the order in which the transports are used. 
;
;    There can be more than one configuration line of this type.
;    Each line adds one rule to the selection process. The rules are applied
;    in the order it is defined. The relative positions of the rules define
;    the relative priority. The first rule has the highest priority.
;
;    The syntax of a rule is as follows:
;    clientTransportRule =   [^]<address mask>      [action]+
;
;        <address mask> can be:
;            1. localhost            if the address is this machine
;            2. w.x.y.z/m1.m2.m3.m4  IPv4 address with the bits selected by
;                                    the mask. e.g. 172.16.0.0/255.240.0.0
;            3. *                    the widecard that matches any address
;
;        <action>+ can be one or more of the following:
;            1. none              Do not use this address
;            2. tcp,ssl,unix      Use the 3 transports in the specified order 
;                                 if any or all of them are available
;            3. bidir             Any connection to this address should be
;                                 used bidirectionally.
;
;         The optional prefix ^ before <address mask>, if present, causes
;         the ORB to remove previously declared clientTransportRules from
;         its internal store because adding the current rule.
;
;    By default, no rule is defined. The ORB implicitly uses the following
;    rule:
;        clientTransportRule =     *   unix,tcp,ssl
;    If any rule is specified, no implicit rule will be applied.
;
;    Give an IOR, for each of the addresses within it, the ORB matches the
;    address to the rules. If one is found, the position of the matched rule
;    and the action is noted. If the action is none, the address is discarded.
;    If the action does not contain the transport the address is specified for,
;    e.g. the action is "ssl" but the address is "tcp", the address is 
;    discarded. Otherwise, the address and action is entered as one of the
;    candidates to use. Having gone through all the addresses, the candidiates
;    available are then ordered based on the priority of the matching rules and
;    used accordingly.
;
;    Here are some example usages:
;
;    A) Restrict to only contacting server on the same host:
;           clientTransportRule = localhost      unix,tcp
;                               =   *            none
;    B) Use tcp to contact servers in the intranet and must use bidirectional
;       ssl otherwise.
;           clientTransportRule = 172.16.0.0/255.240.0.0  unix,tcp
;                               =            *                bidir,ssl
;    C) When a fast network (192.168.1.0) exists in the cluster, use it in
;       preference to the external network.
;           clientTransportRule = 192.168.1.0/255.255.255.0  unix,tcp
;           clientTransportRule = 172.16.0.0/255.240.0.0 unix,tcp
;                               =       *                    none
;     
;             
[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\clientTransportRule]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; clientCallTimeOutPeriod
;
;    Call timeout. On the client side, if a remote call takes longer
;    than the timeout value, the ORB will shutdown the connection and
;    raise a COMM_FAILURE.
;
;    Valid values = (n >= 0 in milliseconds) 
;                    0 --> no timeout. Block till a reply comes back
;
[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB]
"clientCallTimeOutPeriod" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; clientConnectTimeOutPeriod
;
;    Connect timeout. When a client has no existing connection to
;    communicate with a server, it must open a new connection before
;    performing the call. If this parameter is non-zero, it sets a
;    timeout specifically for establishing the connection. If the
;    timeout specified here is shorter than the overall timeout for
;    the call (set with clientCallTimeOutPeriod or per-object or
;    per-thread timeouts), the connect timeout is used for
;    establishing the connection, then additional time is permitted
;    for the call to complete. If the connect timeout is longer than
;    the normal call timeout, the deadline for the entire call is
;    extended to match the connect timeout.
; 
;    If this parameter is zero, the normal call timeout applies to the
;    total time taken to perform the connect and the subsequent call.
; 
;    Valid values = (n >= 0 in milliseconds) 
;                    0 --> same timeout (if any) as other calls
"clientConnectTimeOutPeriod" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; supportPerThreadTimeOut
;

;    If true, each client thread may have its own timeout. This adds
;    some overhead to each call, so it is off by default.
;
;    Valid values = 0 or 1
;
"supportPerThreadTimeOut" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; resetTimeOutOnRetries
;
;    If true, the call timeout is reset when an exception handler
;    causes a call to be retried. If false, the timeout is not reset,
;    and therefore applies to the call as a whole, rather than to each
;    individual call attempt.
;
;    Valid values = 0 or 1
;
"resetTimeOutOnRetries" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; outConScanPeriod
;
;   Idle connections shutdown. The ORB periodically scans all the
;   outgoing connections to detect if they are idle.
;   If no operation has passed through a connection for a scan period,
;   the ORB would treat this connection idle and shut it down.
;
;   Valid values = (n >= 0 in seconds) 
;                   0 --> do not close idle connections.
;
"outConScanPeriod" = "120"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; maxGIOPConnectionPerServer
;
;   The ORB could open more than one connection to a server
;   depending on the number of concurrent invocations to the same
;   server. This variable decides the maximum number of connections
;   to use per server. This variable is read only once
;   at ORB_init. If the number of concurrent invocations exceed this
;   number, the extra invocations would be blocked until the
;   the outstanding ones return.
;
;   Valid values = (n >= 1) 
;
"maxGIOPConnectionPerServer" = "5"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; oneCallPerConnection
;
;   1 means only one call can be in progress at any time per connection.
;
;   Valid values = 0 or 1
;
"oneCallPerConnection" = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; maxInterleavedCallsPerConnection
;
;   The maximum number of calls that can be interleaved on a
;   connection. If more concurrent calls are made, they are queued.
;
;   Valid values = (n >= 1)
;
"maxInterleavedCallsPerConnection" = "5"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; offerBiDirectionalGIOP
;
;   Applies to the client side. Set to 1 to indicate that the
;   ORB may choose to use a connection to do bidirectional GIOP
;   calls. Set to 0 means the ORB should never do bidirectional.
;
;   Valid values = 0 or 1
;
"offerBiDirectionalGIOP" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; diiThrowsSysExceptions
;
;   If the value of this variable is 1 then the Dynamic Invacation Interface
;   functions (Request::invoke, send_oneway, send_deferred, get_response,
;   poll_response) will throw system exceptions as appropriate. Otherwise 
;   the exception will be stored in the Environment pseudo object associated
;   with the Request. By default system exceptions are passed through the 
;   Environment object.
;
;   Valid values = 0 or 1
;
"diiThrowsSysExceptions" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; verifyObjectExistsAndType
;
;   If the value of this variable is 0 then the ORB will not
;   send a GIOP LOCATE_REQUEST message to verify the existence of
;   the object prior to the first invocation. Set this variable
;   if the other end is a buggy ORB that cannot handle GIOP
;   LOCATE_REQUEST. 
;
;   Valid values = 0 or 1
;
"verifyObjectExistsAndType" = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; giopTargetAddressMode
;
;   On the client side, if it is to use GIOP 1.2 or above to talk to a 
;   server, use this Target Address Mode.
;
;   Valid values = 0 (GIOP::KeyAddr)
;                  1 (GIOP::ProfileAddr)
;                  2 (GIOP::ReferenceAddr)
;
"giopTargetAddressMode" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; immediateAddressSwitch
;
;   If true, the client will immediately switch to use a new address
;   to contact an object after a failure. If false (the default), the
;   current address will be retried in certain circumstances.
;
;   Valid values = 0 or 1
;
"immediateAddressSwitch" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; resolveNamesForTransportRules
;
;   If true, names in IORs will be resolved when evaluating client
;   transport rules, and remembered from then on; if false, names
;   will not be resolved until connect time. Client transport rules
;   based on IP address will therefore not match, but some platforms
;   can use external knowledge to pick the best address to use if
;   given a name to connect to.
;
;   Valid values = 0 or 1
;
"resolveNamesForTransportRules" = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; retainAddressOrder
;
;   For IORs with multiple addresses, determines how the address to
;   connect to is chosen. When first estabilishing a connection, the
;   addresses are ordered according to the client transport rules
;   (after resolving names if resolveNamesForTransportRules is true),
;   and the addresses are tried in priority order until one connects
;   successfully. For as long as there is at least one connection
;   open to the address, new connections continue to use the same
;   address.
;
;   After a failure, or after all open connections have been
;   scavenged and closed, this parameter determines the address used
;   to reconnect on the next call. If this parameter is true, the
;   address order and chosen address within the order is remembered;
;   if false, a new connection attempt causes re-evaluation of the
;   order (in case name resolutions change), and the highest priority
;   address is tried first.
;
;   Valid values = 0 or 1
;
"retainAddressOrder" = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; bootstrapAgentHostname
;
; Applies to the client side. Non-zero enables the use of Sun's bootstrap
; agent protocol to resolve initial references. The value is the host name
; where requests for initial references should be sent. Only use this
; option to interoperate with Sun's javaIDL.
;
;"bootstrapAgentHostname" = "localhost"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; bootstrapAgentPort
;
; Applies to the client side. Use this port no. to contact the bootstrap 
; agent.
;
"bootstrapAgentPort" = "900"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; principal
;
; The value of the principal field in GIOP 1.0 and 1.1 requests
;
; principal = me


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;                                                                          ;
;            Server Side Options                                           ;
;                                                                          ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; endPoint
; endPointNoPublish
;
;    These options cause the server to listen on specific endpoints,
;    and provide endpoints to be published in IORs..
;
;    There are two possible ways to specify the endpoints a server
;    should create.
;
;    The two forms differ in the following ways:
;         endPoint - create, listen on the connection and publish it in IORs
;         endPointNoPublish - same as endPoint but do not publish it in IORs
;
;    See the endPointPublish parameter for further options about
;    details to publish in IORs.
;
;    There can be more than one entry defining endPoints. Each entry adds
;    one endpoint to the server. e.g.
;
;[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\endPoint]
;"0" = "giop:tcp:neem:12345"
;"1" = "giop:ssl:neem:23456"
;
;
;    The value of an endPoint configuration is a transport specific string.
;    The transport strings recongised by the ORB and its supported transports
;    are:
;         1. giop:tcp:[<host>]:[<port>]
;               The <host> and <port> parameter are optional. If either or
;               both are missing, the ORB fills in the blank. For example,
;               "giop:tcp::" will cause the ORB to pick an arbitrary tcp port
;               as the endpoint and it will pick one IP address of the host
;               as the host name.
;
;         2. giop:ssl:[<host>]:[<port>]
;               Similar to the tcp transport except that SSL is run on top
;               of the tcp connection.
;
;         3. giop:unix:[<filename>]
;               Create a unix domain socket and bind to the file with pathname
;               <filename>. If <filename> is not specified, e.g. "giop:unix:",
;               the ORB would pick a file name based on the process ID and 
;               the current timestamp.
;               Therefore, if one wants to write an application that always
;               restarts to use the same file to bind to its unix domain 
;               socket, a filename should be specified in the transport string.
;
;   It is possible to use the ORB's transport extension framework to add
;   a new transport to the ORB. In that case, the transport must define its
;   own transport string format and must obey the colon separation rule.
;   For example, if one is to create a transport which executes an arbitrary
;   shell script and let the ORB use its stdin and stdout for sending and
;   receiving giop messages,  a transport string could look like this:
;         giop:shell:magic_gw
;                ^     ^
;                |     +--------- transport specific part
;                +--------------- transport name
;
;   By default, no endPoint configuration is defined. In this case the ORB
;   will create just 1 tcp endpoint as if the line:
;         endPoint = giop:tcp::
;   is specified in the configuration file
;
;   Other than tcp, none of the transports are guaranteed to be available
;   on all platforms. If one specifies say:
;          endPoint = giop:ssl::
;   and the ORB cannot initialise an ssl endpoint, the INITIALIZE exception
;   will be raised. Even though ssl is supported on a platform, its transport
;   is implemented as a separate shared library and must be linked with the
;   application for the ORB to initialise the endpoint.
;
;   Here are some examples of valid endPoint configurations:
;
;[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\endPoint]
;"0" = "giop:tcp::"
;"1" = "giop:ssl::"
;
;[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\endPointNoPublish]
;"0" = "giop:tcp::"
;"1" = "giop:ssl::"
;
;[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\endPointNoListen]
;"0" = "giop:tcp:192.168.1.1:12345"
;
[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\endPoint]

[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\endPointNoPublish]

[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; endPointPublish
;
;    Servers listen on a number of endpoints, controlled by the
;    endPoint and endPointNoPublish parameters. For clients to be able
;    to connect to the server, details about the endpoints must be
;    published in the server's IORs. Endpoints to be published are
;    chosen according to the endPointPublish parameter.
;
;    endPointPublish contains a comma-separated list of publish rules.
;    The rules are applied in turn to each of the configured
;    endpoints; if a rule matches an endpoint, it causes one or more
;    endpoints to be published.
;
;    The following core rules are supported:
;
;        addr      -- the first natural address of the endpoint
;        ipv4      -- the first IPv4 address of a TCP or SSL endpoint
;        ipv6      -- the first IPv6 address of a TCP or SSL endpoint
;        name      -- the first address that can be resolved to a name
;        hostname  -- the result of the gethostname() system call
;        fqdn      -- the fully-qualified domain name
;
;    The core rules can be combined using the vertical bar operator to
;    try several rules in turn until one succeeds. e.g:
;
;        name|ipv6|ipv4
;                  -- the name of the endpoint if it has one;
;                     failing that, its first IPv6 address;
;                     failing that, its first IPv4 address.
;
;    Multiple rules can be combined using the comma operator to
;    publish more than one endpoint. e.g.
;
;        name,addr -- the name of the endpoint (if it has one),
;                     followed by its first address.
;
;    For endpoints with multiple addresses (e.g. TCP endpoints on
;    multi-homed machines), the all() manipulator causes all addresses
;    to be published. e.g.:
;
;        all(addr) -- all addresses are published
;        all(name) -- all addresses that resolve to names are published
;
;        all(name|addr)
;                  -- all addresses are published by name if they have
;                     one, address otherwise.
;
;        all(name,addr)
;                  -- all addresses are published by name (if they
;                     have one), and by address.
;
;        all(name),all(addr)
;                  -- first the names of all addresses are published,
;                     followed by all the addresses.
;
;    A specific endpoint can be published by giving its endpoint URI,
;    even if the server is not listening on that endpoint. e.g.:
;
;        giop:tcp:not.my.host:12345
;        giop:unix:/not/my/socket-file
;
;    If the host or port number for a TCP or SSL URI are missed out,
;    they are filled in with the details from each listening TCP/SSL
;    endpoint. This can be used to publish a different name for a
;    TCP/SSL endpoint that is using an ephemeral port.
;
;"endPointPublish" = "addr"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; serverTransportRule
;
;    When the server sees a connection request from a client, it looks at the
;    client's address and uses the rules in serverTransportRule to determine
;    if the connection should be accepted.
;
;    There can be more than one configuration line of this type.
;    Each line adds one rule to the selection process. The rules are applied
;    in the order they are defined until one matching rule is found. 
;
;    The syntax of a rule is as follows:
;[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\serverTransportRule]
;"(n>=0)" =  "[^]<address mask>      [action]+"
;
;        <address mask> can be:
;            1. localhost            if the address is this machine
;            2. w.x.y.z/m1.m2.m3.m4  IPv4 address with the bits selected by
;                                    the mask. e.g. 172.16.0.0/255.240.0.0
;            3. *                    the widecard that matches any address
;
;        <action>+ can be one or more of the following:
;            1. none              Do not accept this connection.
;            2. tcp,ssl,unix      Accept if the transport is any of the
;                                 3 specified.
;            3. bidir             Allow bidirectional requests if the
;                                 client requests it.
;
;         The optional prefix ^ before <address mask>, if present, causes
;         the ORB to remove previously declared clientTransportRules from
;         its internal store because adding the current rule.
;
;    By default, no rule is defined. The ORB implicitly uses the following
;    rule:
;[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\serverTransportRule]
;"0" = "* unix,tcp,ssl"
;
;    If any rule is specified, the implicit rule will not be applied.
;
;    Here are some example usages:
;
;    A) Only accept connections from our intranet
;
;[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\serverTransportRule]
;        "0"                 = "localhost              unix,tcp,ssl"
;        "1"                 = "172.16.0.0/255.240.0.0 tcp,ssl"
;        "2"                 = "*                      none"
;
;    B) Only accept ssl connections if the client is not on our intranet
;
;[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\serverTransportRule]
;
;        "0"                 = "localhost              unix,tcp,ssl"
;        "1"                 = "172.16.0.0/255.240.0.0 tcp,ssl"
;        "2"                 = "*                      bidir,ssl"
[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB\serverTransportRule]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; serverCallTimeOutPeriod
;
;    Call timeout. On the server side, if the ORB cannot completely 
;    unmarshal a call's arguments in the defined timeout, it shutdown the
;    connection.
;
;    Valid values = (n >= 0 in milliseconds) 
;                    0 --> no timeout.
;
[HKEY_LOCAL_MACHINE\SOFTWARE\omniORB]
"serverCallTimeOutPeriod" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; inConScanPeriod
;
;   Idle connections shutdown. The ORB periodically scans all the
;   incoming connections to detect if they are idle.
;   If no operation has passed through a connection for a scan period,
;   the ORB would treat this connection idle and shut it down.
;
;    Valid values = (n >= 0 in seconds) 
;                    0 --> do not close idle connections.
;
"inConScanPeriod" = "180"


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; threadPerConnectionPolicy
;
;   1 means the ORB should dedicate one thread per connection on the 
;   server side. 0 means the ORB should dispatch a thread from a pool
;   to a connection only when a request has arrived.
;
;   Valid values = 0 or 1
;
"threadPerConnectionPolicy" = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; maxServerThreadPerConnection
;
;   The max. no. of threads the server will dispatch to serve the
;   requests coming from one connection.
;
;   Valid values = (n >= 1) 
;
"maxServerThreadPerConnection" = "100"


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; maxServerThreadPoolSize
;   The max. no. of threads the server will allocate to do various
;   ORB tasks. This number does not include the dedicated thread
;   per connection when the threadPerConnectionPolicy is in effect
;
;   Valid values = (n >= 1) 
;
"maxServerThreadPoolSize" = "100"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; threadPerConnectionUpperLimit
;
;   If the one thread per connection is in effect, this number is
;   the max. no. of connections the server will allow before it
;   switch off the one thread per connection policy and move to
;   the thread pool policy.
;
;   Valid values = (n >= 1) 
;
"threadPerConnectionUpperLimit" = "10000"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; threadPerConnectionLowerLimit
;
;   If the one thread per connection was in effect and was switched
;   off because threadPerConnectionUpperLimit has been exceeded
;   previously, this number tells when the policy should be restored
;   when the number of connections drop.
;
;   Valid values = (n >= 1 && n < threadPerConnectionUpperLimit) 
;
"threadPerConnectionLowerLimit" = "9000"


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; threadPoolWatchConnection
;
;   After dispatching an upcall in thread pool mode, the thread that
;   has just performed the call can watch the connection for a short
;   time before returning to the pool. This leads to less thread
;   switching for a series of calls from a single client, but is less
;   fair if there are concurrent clients. The connection is watched
;   if the number of threads concurrently handling the connection is
;   <= the value of this parameter. i.e. if the parameter is zero,
;   the connection is never watched; if it is 1, the last thread
;   managing a connection watches it; if 2, the connection is still
;   watched if there is one other thread still in an upcall for the
;   connection, and so on.

"threadPoolWatchConnection" = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; connectionWatchPeriod
;
;   For each endpoint, the ORB allocates a thread to watch for new
;   connections and to monitor existing connections for calls that
;   should be handed by the thread pool. The thread blocks in select()
;   or similar for a period, after which it re-scans the lists of
;   connections it should watch. This parameter is specified in
;   microseconds.
;
;   Valid values = (n >= 0 in microseconds)
;
"connectionWatchPeriod" = "50000"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; connectionWatchImmediate
;
;   When a thread handles an incoming call, it unmarshals the
;   arguments then marks the connection as watchable by the connection
;   watching thread, in case the client sends a concurrent call on the
;   same connection. If this parameter is set to the default false,
;   the connection is not actually watched until the next connection
;   watch period (determined by the connectionWatchPeriod parameter).
;   If connectionWatchImmediate is set true, the connection watching
;   thread is immediately signalled to watch the connection. That
;   leads to faster interactive response to clients that multiplex
;   calls, but adds significant overhead along the call chain.
;
;   Note that this setting has no effect on Windows, since it has no
;   mechanism for signalling the connection watching thread.
;
;   Valid values = 0 or 1
;
"connectionWatchImmediate" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; acceptBiDirectionalGIOP
;
;   Applies to the server side. Set to 1 to indicate that the
;   ORB may choose to accept a client's offer to use bidirectional
;   GIOP calls on a connection. Set to 0 means the ORB should
;   never accept any bidirectional offer and should stick to normal
;   GIOP.
;
;   Valid values = 0 or 1
;
"acceptBiDirectionalGIOP" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; supportCurrent
;
;   If the value of this variable is TRUE, per-thread information is
;   made available through the Current interfaces, e.g.
;   PortableServer::Current. If you do not need this information, you
;   can set the value to 0, resulting in a small performance
;   improvement.
;
"supportCurrent" = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; copyValuesInLocalCalls
;
;   If the value of this variable is TRUE, valuetypes used in local
;   calls are properly copied, to retain local/remote transparency.
;   This involves copying all operation parameters / return values,
;   and is thus quite time consuming. If this parameter is set to
;   FALSE, valuetypes in local calls are not copied.
;
"copyValuesInLocalCalls" = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; objectTableSize
;
;   Hash table size of the Active Object Map. If this is zero, the ORB
;   uses a dynamically resized open hash table. This is normally the  
;   best option, but it leads to less predictable performance since   
;   any operation which adds or removes a table entry may trigger a   
;   resize. If you set this to a non-zero value, the hash table has   
;   the specified number of entries, and is never resized. Note that  
;   the hash table is open, so this does not limit the number of      
;   active objects, just how efficiently they can be located.
;
;   Valid values = (n >= 0)
;                  0 --> use a dynamically resized table.
;
"objectTableSize" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; poaHoldRequestTimeout
;
;   This variable can be used to set a time-out for calls being held
;   in a POA which is in the HOLDING state.  It gives the time in
;   seconds after which a TRANSIENT exception will be thrown if the
;   POA is not transitioned to a different state.
;
;   Valid values = (n >= 0 in milliseconds) 
;                   0 --> no time-out.
;
"poaHoldRequestTimeout" = "0"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; poaUniquePersistentSystemIds
;
;   The POA specification requires that object ids in POAs with the
;   PERSISTENT and SYSTEM_ID policies are unique between
;   instantiations of the POA. Older versions of omniORB did not
;   comply with that, and reused object ids. With this value true, the
;   POA has the correct behaviour; with false, the POA uses the old
;   scheme for compatibility.
;
;   Valid values = 0 or 1
;
"poaUniquePersistentSystemIds" = "1"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; idleThreadTimeout
;
;   When a thread created by omniORB becomes idle, it is kept alive
;   for a while, in case a new thread is required. Once a thread has
;   been idle for the number of seconds specified in this parameter,
;   it exits.
;
;   Valid values = (n >= 0 in seconds)
;
"idleThreadTimeout" = "10"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; supportBootstrapAgent
;
; Applies to the server side. 1 means enable the support for Sun's
; bootstrap agent protocol.  This enables interoperability between omniORB
; servers and Sun's javaIDL clients. When this option is enabled, an
; omniORB server will response to a bootstrap agent request.
;
"supportBootstrapAgent" = "0"