![]() |
This topic provides reference information about the properties that you can set to control the runtime environment of C++ CORBA clients and servers. Each property is listed in the following form:
- property_name=value_type
- [default_value] A description of the property, where
- property_name
- is the name of the property
- value_type
- is the type of value that the property can have.
- [default value]
- is the default value of the property (only shown if the property has a default value).
Client and Server general ORB properties
You can specify the following general ORB properties for both clients and servers:
- com.ibm.CORBA.nameServerHost=host_name
- The name of the host on which the client's name server runs. This host name is used with the com.ibm.CORBA.nameServerPort property to access the name server.
- com.ibm.CORBA.nameServerPort=port_number
- [900] The number of the port that the name server uses to communicate with clients and servers. This property is an integer port number, in the range 0 through 65536. This port number is used with the com.ibm.CORBA.nameServerHost property to access the name server.
- com.ibm.CORBA.protocolVersion=iiop_version
- [1.2] The default GIOP/IIOP protocol version that the ORB uses to export object references. This property enables WebSphere Application Server ORBs to interoperate with non-WebSphere ORBs that use the same format. This property can be set to 1.0, 1.1, or 1.2 (for IIOP 1.0, IIOP 1.1, or IIOP 1.2 respectively).
Note: The C++ ORB may downgrade the level depending on responses from a remote server.- com.ibm.CORBA.requestTimeout=time_seconds
- [30] The time, in seconds, that a request waits for a response before timing out and issuing an error that indicates NO RESPONSE. If this property is set to 0 (zero), requests wait indefinitely until a response is received.
This property is either 0 (zero, for an indefinite wait) or an integer number of seconds in the range 1 through 300 seconds.
For tracing and debugging, this property must be set to 0 (zero).
- com.ibm.CORBA.eMNumThreads=number_threads
- [3] The initial size of the thread pool that is created to push events to consumers. This property is an integer in the range 1 through 20.
- com.ibm.CORBA.enableFilters=yes_or_no
- [yes] Whether or not the client or server can use RAS request interceptors to help you map runtime problems back to a specific client. This property has one of the following values:
- Yes
- Log entries (and trace entries if you have turned trace on) have additional 'UnitOfWork' information that can help you debug runtime problems. But that information comes with a performance penalty. When your application environment is fully debugged and deployed, you should consider turning off this option to disable RAS interceptor filters and thereby improve performance.
- No
- Log entries (and trace entries if you have turned trace on) do not have 'UnitOfWork' information.
By disabling the filters on a client, the server-side RAS trace and activity log entries do not contain the data needed to map an event back to that specific client. If you later decide that you need that information, enable the filters again in the client properties file then restart the client.
By turning off the filters on the server side, no RAS trace and activity log entries is mappable back to any specific client. If you later decide that you need that information, enable the filters again in the server then restart the server.
You can disable RAS request Interceptors to improve the performance of your WebSphere application environment, but should consider this only if you are confident that the environment has been stable for some time and that you need some extra performance. You can disable or enable RAS request interceptors in any combination of servers and clients. For maximum performance improvement, you should disable RAS request interceptors in both your clients and servers.
- com.ibm.CORBA.maximumHops=number_of_location_forwards
- [5] The maximum number of location forwards that the client or server should follow before aborting object location.
This property is an integer in the range 0 through 65536. A value of 0 (zero), indicates that the client or server should keep following location forwards indefinitely until the object is located.
Server-specific ORB properties
You can specify the following ORB properties for servers only:
- com.ibm.CORBA.hostName=host_name
- The hostname string that should be included in object references (IORs) exported by the server. The value is a TCP/IP hostname of up to 256 ASCII characters.
Normally, the C++ ORB uses the dotted-decimal form of the hostname, but this property can be used to override the dotted-decimal form with an alternate name. This might be useful in situations where the server is operating behind a firewall, and you do not want the dotted-decimal hostname published outside the firewall.
- com.ibm.CORBA.serverListenPort=port_number
- [0] The port number on which the server listens for incoming requests from clients. For example, this enables the server to support a static firewall scenario, in which the firewall enables use of a set of "secure" ports.
If you leave this property to default to 0 (zero), the server is automatically assigned a number for it's listening port.
- com.ibm.CORBA.threadPoolSize=number_threads
- [5] The size of the ORB thread pool in which servant objects process method invocations. This property is an integer in the range 0 through 1000.
When the ORB receives a request, it activates a thread from the appropriate pool for the target object to service the request.
- com.ibm.CORBA.threadStackSize=number_bytes
- [65536] The size, in bytes, of the thread stack used when creating new threads. This property is an integer in the range 0 through 65536 bytes.
Client and server code page support properties
You can specify the following code page properties for clients and servers:
- com.ibm.CORBA.translationEnabled=yes_no
- [no] Whether or not the client or server should perform code set translation for character data received in remote messages. This property can have the following values:
- no
- Code set translation is not performed the com.ibm.CORBA.nativeWCharSet property is ignored.
- yes
- Code set translation is performed. Also, consider the following points:
- If you do not specify a value for the com.ibm.CORBA.nativeWCharSet property, then the ORB assumes that the user does not want to use wchar (wide character) data because a wchar code set was not specified.
- You should not use the default of LANG or LC_ALL, but should manually set an appropriate value.
- Code set translation is not supported by the IIOP 1.0 protocol.
- com.ibm.CORBA.isoLatin1=yes_no
- [no] Whether or not the ORB uses ISO-Latin1 as the default transmission code set for character data in remote requests.
This property is ignored if you set com.ibm.CORBA.translationEnabled=yes. You should only set this property if the ORB communicates with a remote process that uses the IIOP 1.0 protocol.
- com.ibm.CORBA.nativeCharSet=codesetnum
- [0] The number of the native OSF (Open Systems Foundation) code set used by applications for single-byte char and string data.
This property is either 0 (zero) or a decimal code set number. If set to 0, the number of the native OSF code set used is calculated by the ORB.
- com.ibm.CORBA.nativeWCharSet=codesetnum
- [0] The number of the native OSF (Open Systems Foundation) code set used by applications for wchar (wide character) and wstring (wide string) data. This property need be set only if both applications (on the server) and the ORB support wchar and wstring types. If it is set, then the C++ ORB supports wchar translations; if it is not set, then wchar data is copied without translation.
This property is either 0 (zero, if you do not want to use wchar data) or a decimal code set number.
Note: If the code set property com.ibm.CORBA.nativeWCharSet does not match the current system code set, a DATA_CONVERSION exception is logged in the ORB's activity log.
Client and server trace and activity log support properties
You can specify the following trace and activity log properties for clients and servers:
- com.ibm.CORBA.activityLogMaxSize=
- [100] The maximum size (in kilobytes) that the activity log can reach. If the activity log reaches this size, it will wrap around, with the oldest messages in the log being overwritten with any new messages. This property is an integer number of kilobytes in the range 0 through infinity. When setting this property make sure that there is enough room available for the activity log on the disk where this directory is located (the directory of the activity log is set by the com.ibm.CORBA.activityLogDirectory property).
- com.ibm.CORBA.activityLogDirectory=
- [] The name of the directory that is used to store the activity log for the related client or server. If this value is left blank then the default directory is used, wasee_install\services; where, wasee_install is the directory into which you installed WebSphere Application Server enterprise services on the host. When setting this property make sure that there is enough room available for the activity log on the disk where this directory is located (the size of the activity log is set by the com.ibm.CORBA.activityLogMaxSize property).
- com.ibm.CORBA.orbCommunicationsTraceLevel=trace_level
- [none] Controls the amount of trace data that is written to the trace log for communications between the Object Request Broker (ORB) and servers and clients. ORB communications trace provides hexadecimal representation of the IIOP packets sent and received by processes. It is helpful in diagnosing problems with ORB communications. Knowledge of the IIOP protocol is needed to interpret the trace data.
This property has one of the following values. Each succeeding value increases the amount of information that is captured.
- None
- Trace data is not recorded for this component.
- Basic
- The smallest amount of trace information, critical path trace data, is recorded. This data is primarily used for the highest level data and performance measurements.
- Intermediate
- For ORB communications trace, the data recorded is the same as for the Basic setting.
- Advanced
- For ORB communications trace, the data recorded is the same as for the Basic setting.
Trace is used by or for IBM Service personnel to assist in collecting data in possible defect situations. This support should only be used under direction of IBM Service personnel. Incorrectly setting trace properties for objects can result in performance degradation for normal operation.
- com.ibm.CORBA.orbIRTraceLevel=trace_level
- [none] Controls the amount of trace data that is written to the trace log for interface repository (IR) operations performed by the Object Request Broker (ORB).
This property has one of the following values. Each succeeding value increases the amount of information that is captured.
- None
- Trace data is not recorded for this component.
- Basic
- The smallest amount of trace information, critical path trace data, is recorded. This data is primarily used for the highest level data and performance measurements.
- Intermediate
- Record trace messages and any throw instructions that are processed, in addition to the information recorded for the basic trace level.
- Advanced
- Record all trace information, including process flow and detailed data, in addition to the information recorded for the intermediate trace level. Further, messages sent to the activity and error logs are also recorded in the trace log. This data is primarily for extended problem determination. It controls the recording of extra raw data, component extended messages, and indications that an exception subclass was thrown.
Trace is used by or for IBM Service personnel to assist in collecting data in possible defect situations. This support should only be used under direction of IBM Service personnel. Incorrectly setting trace properties for objects can result in performance degradation for normal operation.
- com.ibm.CORBA.orbMutexTraceLevel=trace_level
- [none] Controls the amount of trace data that is written to the trace log for mutex operations performed by the Object Request Broker (ORB). The ORB mutex trace records data at the base ORB level about threads claiming and releasing mutexes. This can be valuable in debugging deadlock situations.
This property has one of the following values. Each succeeding value increases the amount of information that is captured.
- None
- Trace data is not recorded for this component.
- Basic
- The smallest amount of trace information, critical path trace data, is recorded. This data is primarily used for the highest level data and performance measurements.
- Intermediate
- For ORB mutex trace, the data recorded is the same as for the Basic setting.
- Advanced
- For ORB mutex trace, the data recorded is the same as for the Basic setting.
Trace is used by or for IBM Service personnel to assist in collecting data in possible defect situations. This support should only be used under direction of IBM Service personnel. Incorrectly setting trace properties for objects can result in performance degradation for normal operation.
- com.ibm.CORBA.orbRequestTraceLevel=trace_level
- [none] Controls the amount of trace data that is written to the trace log for request operations performed by the Object Request Broker (ORB).
This property has one of the following values. Each succeeding value increases the amount of information that is captured.
- None
- Trace data is not recorded for this component.
- Basic
- The smallest amount of trace information, critical path trace data, is recorded. This data is primarily used for the highest level data and performance measurements.
- Intermediate
- Record trace messages and any throw instructions that are processed, in addition to the information recorded for the basic trace level.
- Advanced
- Record all trace information, including process flow and detailed data, in addition to the information recorded for the intermediate trace level. Further, messages sent to the activity and error logs are also recorded in the trace log. This data is primarily for extended problem determination. It controls the recording of extra raw data, component extended messages, and indications that an exception subclass was thrown.
Trace is used by or for IBM Service personnel to assist in collecting data in possible defect situations. This support should only be used under direction of IBM Service personnel. Incorrectly setting trace properties for objects can result in performance degradation for normal operation.
- com.ibm.CORBA.traceLogMaxSize=
- [100] The maximum size (in kilobytes) that the trace log can reach. If the trace log reaches this size, it will wrap around, with the oldest messages in the log being overwritten with any new messages. This property is an integer number of kilobytes in the range 100 through infinity. When setting this property make sure that there is enough room available for the trace log on the disk where this directory is located (the directory of the trace log is set by the com.ibm.CORBA.traceLogDirectory property).
Trace is used by or for IBM Service personnel to assist in collecting data in possible defect situations. This support should only be used under direction of IBM Service personnel. Incorrectly setting trace properties for objects can result in performance degradation for normal operation.
- com.ibm.CORBA.traceLogDirectory=
- [] The name of the directory used to store the trace log for the related host. If this value is left blank then the default directory is used. When setting this property make sure that there is enough room available for the trace log on the disk where this directory is located (the maximum size of the trace log is set by the com.ibm.CORBA.traceLogMaxSize property).
Trace is used by or for IBM Service personnel to assist in collecting data in possible defect situations. This support should only be used under direction of IBM Service personnel. Incorrectly setting trace properties for objects can result in performance degradation for normal operation.
- com.ibm.CORBA.transactionTraceLevel=trace_level
- [none] Controls the amount of trace data that is written to the trace log for transaction object service operations for servers.
This property has one of the following values. Each succeeding value increases the amount of information that is captured.
- None
- Trace data is not recorded for this component.
- Basic
- The smallest amount of trace information, critical path trace data, is recorded. This data is primarily used for the highest level data and performance measurements.
- Intermediate
- Record trace messages and any throw instructions that are processed, in addition to the information recorded for the basic trace level.
- Advanced
- Record all trace information, including process flow and detailed data, in addition to the information recorded for the intermediate trace level. Further, messages sent to the activity and error logs are also recorded in the trace log. This data is primarily for extended problem determination. It controls the recording of extra raw data, component extended messages, and indications that an exception subclass was thrown.
Trace is used by or for IBM Service personnel to assist in collecting data in possible defect situations. This support should only be used under direction of IBM Service personnel. Incorrectly setting trace properties for objects can result in performance degradation for normal operation.
Client and server transaction support properties
You can specify the following transaction support properties for clients and servers:
- com.ibm.CORBA.defaultTimeout=
- [300] The default time, in seconds, after which a top-level transaction is rolled back if it has not completed.
Because a transaction may hold locks on database records, it is important to ensure that all transactions complete within a reasonable period of time. This is especially important in a distributed environment where a transaction may be originated by a non-recoverable client. If such a client dies without ending all the transactions it started, then those transactions should have a period of time after which they are automatically rolled back by the server on which they were created.
This timeout value is the time from when the originator started the top-level transaction to the time when the originator must request that the transaction be committed or rolled back. It is an integer number of seconds greater than 0. If you set this property to 0 (zero), the top-level transaction never times out in the lifetime of the server on which the transaction was created.
If the application server's default transaction timeout is set to 0 (zero), transactions started using the CosTransactions::Current interface do not have a time limit set. An application program can set a time limit by calling the set_timeout() operation on the CosTransactions::Current object, passing the time limit required as a parameter.
- com.ibm.CORBA.deferredBegin=deferbegin
- [always] This property is used to control whether clients should attempt to defer the begin of transactions until the first remote business method is called.
In general, it is desirable for clients to have a transaction created on the same application server as at least one of the Enterprise JavaBean objects. The transaction service provides the ability to defer the creation of a transaction until the first remote business method is called, allowing the transaction service on the remote application server to create the transaction during the processing of that first business method. However, the transaction service on the remote application server must be capable of supporting this function.
You determine whether clients should attempt to defer the creation of transactions by setting the com.ibm.CORBA.deferredBegin property to one of the following values:
- always
- Always defer the creation of a transaction. This setting can be used even if WebSphere application servers are started with their default property settings. WebSphere application servers handle deferred begins by default, but do not indicate that they support this capability.
- never
- Never defer the creation of a transaction. When a client application requests that a transaction be begun, a transaction factory is obtained using a factory finder. The factory finder may be specified with the Factory finder property. If a value is not specified for the factory finder property, an arbitrary application server is chosen. This setting may be detrimental to performance when communicating with application servers that can support deferred begin, because transactions may be created on an application server that is not otherwise involved in the transaction.
- serverDependent
- Defer the creation of a transaction depending on the capability of the remote server.
The transaction's client code determines the capability of the remote transaction service to support the deferred begin protocol. The client determines the capability of the remote server from information contained in the target object's proxy object, so no remote flows are required for this test.
WebSphere application servers that are started specifying the property com.ibm.ejs.jts.jts.ControlSet.nativeOnly=false export this information in the target object's proxy.
Note: This is not the default startup property for the application server.- com.ibm.CORBA.transactionfactoryFinder=
- [(A null value.) ] The name to be used to find a transaction factory for transactional clients.
The value is the fully-qualified name path from the local root, which can be used in a resolve to get the factory desired. For example, one possible value to specify is:
com.ibm.CORBA.transactionfactoryFinder=node/servers/xyzServerYou can specify any transaction factory that is bound into the name space. Through the use of this property, you can direct of the search for a particular transaction factory. The above example finds a factory on the local node (host) in server xyzServer. The format of the property value may be either of the following:
node/servers/servername or domain/nodes/nodename/servers/servernamewhere nodename is the name of one of the nodes in the configured WebSphere domain and servername is the name of a server. If a null value is supplied, a search starts on the local bootstrap node and if no factory is found, the search when proceeds throughout the domain searching all configured nodes and servers for an available transaction factory. Thus a null default value on a large configuration may incur a performance overhead.Note: This property is only used if transactions are not deferring the start of a transaction until the first business method.- com.ibm.CORBA.transactionEnabled=
- [yes] Whether or not this client is enabled to use the transaction service. The possible values for this property are yes or no.
Client and server OLT- and debug-specific properties
You can specify the following OLT- and debug-specific properties for clients and servers:
- com.ibm.CORBA.debugEnabled=
- [yes] Whether or not the OLT runtime is enabled for tracing and debugging. The possible values for this property are yes or no.
- com.ibm.CORBA.oltHostname=host_name
- The hostname of the machine where the OLT server is running.
- com.ibm.CORBA.oltPort=port_number
- [2102] The number of the port at which the OLT server listens.
For tracing and debugging, the property com.ibm.CORBA.requestTimeout=0 must be set.
For more information about tracing and debugging, see 4.1.2.1: IBM Distributed Debugger and Object Level Trace.
Related tasks... | |
Specifying properties for C++ CORBA clients and servers | |