HP NonStop CORBA 2.6.1 Programmer's Guide for C++ HP NonStop CORBA 2.6.1 Programmer's Guide for C++ Part number: 525936–007. Published July 2011. Legal Notice Abstract This manual provides information for application programmers about writing applications for HP NonStop™ CORBA® 2.6.1 in C++. The information provided focuses on the NonStop CORBA-specific implementation of the Object Management Group's CORBA standards. Product Version: HP NonStop™ CORBA® 2.6.
4. Deploying a NonStop CORBA Application 5.
Using Parallel Library TCP/IP Increasing the Number of Comm Server Processes Using Multiple Instances of NonStop TCP/IP Using Multithreaded Servers 7. Managing Transactions Components of Transaction Service Implementation Use of TMF Transaction Service Features Not Supported in NonStop CORBA TransactionalObject Interface Checked Transaction Behavior Transaction Branches and the Diamond Access Problem 8.
Writing a Wrapper for a Legacy Server Basic Structure of a Server Wrapper Calling a Context-Free TS/MP Server for Nowait Operations Calling a Context-Free or Context-Sensitive Pathsend Server for Waited Operations Calling a TCP/IP Server Calling Other Types of Legacy Servers Managing Transactions in Server Wrappers Writing a Wrapper for a Legacy Client Basic Structure of a Client Wrapper Writing a Client Wrapper for a Context-Free Pathsend Requester Writing a Client Wrapper for a Remote (TCP/IP) Client Writ
3.1. The Process of Developing a Client and a Server 5.1. EMS Collectors 5.2. esadmin Tool 5.3. Naming Service Display 6.1. Stateless Factory Object and Stateless Servant 7.1. Diamond Access Problem 12.1. Legacy Server Wrapper 12.2. Legacy Client Wrapper 12.3. Listener Event Handler and Event-Handler User 12.4. Transfer Event Handler and Event-Handler User 12.5. Client Event Handler and Event-Handler User A.1. Basic NonStop CORBA Architecture A.2. Expanded View of NonStop CORBA Architecture A.3.
New and Changed Information New and Changed Information This edition of the HP NonStop CORBA 2.6.1 Programmer's Guide for C++ includes: In Chapter 2, subsection profile@ORB Server Transport Protocols is updated. In Appendix B, subsection IOP::TAG_INTERNET_IOP Addresses is updated. In Appendix B, subsection Configured Versus Actual TCP/IP and TCP/IPv6 Addresses is updated. This edition of the HP NonStop CORBA 2.6.1 Programmer's Guide for C++ includes: In Chapter 8.
© Copyright 2006 and 2011 Hewlett-Packard Development Company L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. The information contained herein is subject to change without notice.
About This Guide About This Guide Who Should Read This Guide Organization of this Guide Manuals in the NonStop CORBA Set Notation Conventions This NonStop CORBA 2.6.1 Programmer's Guide for C++ provides information about designing and implementing application programs for the NonStop CORBA 2.6.1 environment. The guide explains how to take advantage of the specific implementation features of NonStop CORBA.
Appendix C, Servant Reference Counting in NonStop CORBA, describes a specific reference counting option available in NonStop CORBA. Manuals in the NonStop CORBA Set The NonStop CORBA 2.6.1 Getting Started Guide for C++ describes how to install the product and verify installation. It also includes an introduction to the C++ product. The NonStop CORBA 2.6.1 Getting Started Guide for Java describes how to install the product and verify installation. It also includes an introduction to the Java product.
An ellipsis immediately following a single syntax item indicates that you can repeat that syntax item any number of times. For example: "s-char..." - A dash in a command usually indicates a separate flag. "" When quotation marks surround a defined syntax symbol (such as a bracket or brace), they symbolize an actual character that must be entered as shown. For example: Other punctuation Punctuation not previously described (such as parentheses, commas, and semicolons) must be entered as shown.
Chapter 1. Introduction to NonStop CORBA Programming Chapter 1. Introduction to NonStop CORBA Programming Before You Begin Design Activities Sample Programs Introduction to NonStop CORBA Components NonStop CORBA 2.6.1 is an implementation of the Common Object Request Broker Architecture (CORBA) defined and promoted by the Object Management Group (OMG). Because NonStop CORBA 2.6.1 is based on CORBA 2.6.
Make decisions about server implementation. Design or modify clients to take advantage of new features. To create an application, you: Define new object classes and create new class libraries and frameworks, or modify existing ones to suit your application. Create the client programs. Create the server programs.
An object interface definition written in IDL A server that implements the interface defined by the interface definition A client application that makes use of an instance of a stock object Introduction to NonStop CORBA Components You will work with several NonStop CORBA components as you design and write your applications, including: Bootstrap Service Daemon (BSD) For applications that need interoperability with the bootstrap protocol in some earlier versions of J2EE, the Bootstrap Service Daemon provides
About This Guide Chapter 2.
Chapter 2. NonStop CORBA Administrative Environment Chapter 2. NonStop CORBA Administrative Environment Working in the Open System Services (OSS) Development Environment Using Guardian Commands and Files Through OSS OSS Environment Variables and the env.
The OSS run command lets you run a process with specific attributes. For example, you could use the following syntax to run a named process: run -name=Guardian-process-name program-name For example, run -name=/G/svr Test_DII_SVR -ORBprofile tcp_sample_svr In this example, svr is an arbitrary process name. tcp_sample_svr is passed when ORB_init() is called. OSS Environment Variables and the env.sh File A shell implements environment variables that you can set and display.
Working in the NonStop CORBA Administrative Environment Applications that you write use services provided by the NonStop CORBA administrative environment. This section gives a brief overview of the administrative environment. For more information on the NonStop CORBA administrative environment, see the NonStop CORBA 2.6.1 Administration Guide.
Component Console. If it is stopped for any reason, it must be restarted as described in the NonStop CORBA 2.6.1 Administration Guide. The NSDEnvironServer is started on demand by the NSDAdminServer, and you generally do not need to start it. Application Profiles: Configuring and Managing an Application To configure your application, you set up your application's profile (the profile@ORB database entity) using the cfgmgt tool.
max_threads number The maximum number of servant threads available in a process. Default is 4097. The effective maximum number of threads in a server depends on the size of each thread's stack and the number of NSK threads available in a CPU. nsdom_ir file-name Default is $NSD_ROOT/etc/nsdom.ir . stack_size number Default is 65536. Minimum is 16384 and maximum is 32768000. This setting dictates the size of thread stacks.
Chapter 3. Compiling and Building an Application Chapter 3.
1. Define the CORBA object's interface in a CORBA Interface Definition Language (IDL) file. 2. Compile the IDL file using the NonStop CORBA IDL compiler. Compiling the IDL file will generate several files: A header file to include in client programs that use the CORBA object. A client stub source file to be compiled and linked with client programs. A header file to include in the server that implements the CORBA object. Note that the server header, in turn, includes the client header.
Tips for Building NonStop CORBA Application Components 1. Ensure that the $NSD_ROOT/etc/env.sh file was sourced into the OSS shell environment. 2. Run the NonStop CORBA IDL compiler on all your IDL files to produce header files, client stub files, and server skeleton files. For more information, see Using the IDL Compiler. nsdidl -language C++ *.idl Note: Do not modify the compiler-generated files. Write your own header file that includes the _server.h header generated by the IDL compiler.
documentation for further information. The default preprocessor invoked by the IDL compiler is called cfe . You can use the -preprocessor flag to specify a different preprocessor to be invoked by the IDL compiler. To use the default preprocessor, the directory containing cfe must be in the PATH environment variable. For example, to use the /usr/lib/cfe preprocessor, execute the following command from the command line or add it to your OSS .profile or env.
-no_ Specify no intervening underscore character when naming generated files. The default is to use an underscore. -o dir Place generated files in the specified output directory. The default is the current directory. -preprocessor Specify the preprocessor and preprocessor options to be used. The default is cfe -E . The -E is an input argument to cfe directing it how to operate for the NonStop CORBA environment. Any ANSI C or ANSI C++ preprocessor can be used.
Chapter 4. Deploying a NonStop CORBA Application Chapter 4. Deploying a NonStop CORBA Application The general steps in deploying a NonStop CORBA application after you have compiled your files are: Check that you have set up your application profile as described in Application Profiles: Configuring and Managing an Application. Use the Console to make sure that any other subsystem configuration profile settings are correct. Decide if you want to enable tracing.
esac done shift $(($OPTIND - 1)) print "Configuring $SERVER_CLASS" # Set G_HOMETERM to the terminal identifier on which standard # output is displayed. # When HOMETERM env variable is set the script used to fail. # The format of the HOMETERM set will be checked for $., # if it is not of the required format then it will use the default # HOMETERM set using who -m command DEFAULT=$(echo $HOMETERM | awk -F ".
[ Set TIMEOUT to a sensible value; this sets how long a SEND through the [ LINKMON will be allowed to be outstanding. set server createdelay 1 secs set server deletedelay 15 secs set server TIMEOUT 10 SECS set server MAXLINKS 16 set server LINKDEPTH 1 set server maxservers 6 set server numstatic 1 set server cpus (0,1,2,3) set server tmf on, AUTORESTART 0 add server $SERVER_CLASS start server $SERVER_CLASS eof Chapter 3. Compiling and Building an Application Chapter 5.
Chapter 5. Tracing and Debugging Applications Chapter 5.
System exceptions raised by the NonStop CORBA run-time environment, reported to the client program. Other exceptions, raised by object classes, reported to the client program. Run-time errors logged as text in a specified log file, displayed on the standard output device, STDERR , or sent to the Event Management Service (EMS). Generally, the log file contains information about unexpected error conditions encountered by the NonStop CORBA run-time.
Date and time the exception was logged No field name Error number for this entry No field name Text description of the exception No field name Severity level of the exception Severity Name of the component that logged the error Component Name of the process that logged the error PName Process ID of the process that logged the error PId Thread ID of the thread that logged the error TId Exception type (not all log messages are associated with an exception) ExcptType Exception name (not all exc
TACL prompt: > EMSACOLL /NAME $xxx, NOWAIT/ BLOCKING OFF For more information about starting the EMS collector, see the EMS Manual. Note: The variable $xxx is the process name for the collector that you set using file or in log_file in the default@ORB entity in the configuration database. MY_COLLECTOR in the $NSD_ROOT/etc/env.
NSDOM_LOG_WARNING(pv_err_num, pp_text) ; NSDOM_LOG_WARNING_ENV(pv_err_num, pp_text, pp_env) ; In the above macros, exc refers to a CORBA exception, and env refers to CORBA environment. Component Names Each NonStop CORBA component should be assigned a unique component name so NonStop CORBA can identify the process that is logging the error message. Component names are assigned once for each process, which must be done before an error message can be logged.
A short description of the error A list of actions that you can perform to resolve the problem Error Logging Examples The following code shows how to log an error using C++ exceptions: try { some CORBA work } catch (const CORBA::Exception& ex ) { NSDOM_LOG_ERROR_EXC (7003, "Error writing to CustDB", ex ); } The following code shows how to log an error using if/then logic. This technique is usually less desirable than using exceptions.. some CORBA work ... if (!CORBA::environment::default_environment().
Distributed applications typically involve interactions between a number of processes. When problems occur, you might wish to be able to gain insight into these dynamic interactions. The NonStop CORBA trace facility is provided for this purpose. Using the trace facility helps you to narrow the problem area to a specific set of interactions. For example, a client might send a request to an object and never receive a reply.
NSDOM_CFG_TRACE_THREADS threads NonStop CORBA thread framework NSDOM_CFG_TRACE_TIMER event_time NonStop CORBA timer objects NSDOM_CFG_TRACE_DETAIL none Sets verbose tracing NSDOM_CFG_TRACE_FULL_BUFFERING none If NSDOM_CFG_TRACE_PI NSDOM_CFG_TRACE_PI_DETAIL pi Traces basic Portable Interceptor activity.
Server Event Service NSDOM_CFG_TRACE_ES NSDOM_CFG_TRACE_ORB NSDOM_CFG_TRACE_POA NSDOM_CFG_TRACE_ES NSDOM_CFG_TRACE_POA NSDOM_CFG_TRACE_PROXY NSDOM_CFG_TRACE_ORB NSDOM_CFG_TRACE_GIOP_FW NSDOM_CFG_TRACE_SOCKEH es.
Facility works. The public section of NSDOM_Trace contains four methods. Three of these methods are used to actually create a trace message, while the fourth method can be used to create a specific, user-defined trace file (by default, the Trace Facility writes trace messages to the file specified during system configuration).
The SSL_handshake_done trace record is emitted by a SSL client or server once the SSL handshake completes with success. The SSL_handshake_done trace record identifies the SSL version, the cipher suite solicted, and the cipher-key size.
For JORB Lite, the required Java environment is: CLASSPATH PATH must include the path to the standard Java JVM classes file, the jorblite.jar file, and the esadmin.jar file. must include the path to the Java implementation. When NonStop CORBA is installed, the Naming Service writes the stringified IOR of the root naming context into the NameService file. This ASCII file must be copied to the computer where JORB Lite is installed and the full pathname of this file must be specified in the lite.
tracing enabled for long periods can result in unnecessarily large trace logs. To administer additional event channels, go to the Admin menu and click New. From the dialog displayed, select the additional event channels you want to monitor. Viewing the Naming Service You can use the NonStop Distributed Component Console or the ns_browse tool to look at entries stored in the Naming Service database. The Naming Service database can be viewed as a tree of naming contexts.
Setting Up ns_browse to View the Naming Service The ns_browse tool runs on the NonStop system, and it allows you to look at entries stored in the Naming Service database. You might use the ns_browse tool if for some reason you did not want to use the Console, or if the Console were not available. The ns_browse tool for NonStop CORBA is located in the $NSD_ROOT/bin/unsupported directory.
3. Run ns_browse to bind a new naming context with name TestCtx test (TestCtx is the name id and test is the name kind ) in the root naming context. This command returns a stringified IOR of the newly created context. ns_browse bind_new_context TestCtx test 4. Run ns_browse to bind a new naming context with name TestCtx1 "" (no kind specified) in the naming context with name TestCtx test .
Indicate number of days old a context must be to be considered for deletion (default 30). -d [] Specify a date or date range in the format mm/dd/yyyy. When a date is specified, contexts created prior to that date are candidates for deletion. When two dates are specified contexts created between the two dates are candidates for deletion. -p Specify the naming database on which to operate (identifies an enscribe file in the Guardian file space: $..).
Chapter 6. Writing Scalable Applications Chapter 6.
In the POA in the CORBA server application, ensure that the proprietary state policy has a value of STATELESS. You can do this either by setting the lifespan policy to PERSISTENT or by directly setting the state policy to STATELESS. Note: The use of server pools provides a number of other advantages, including availability, automatic load balancing, and process management (allowing the operator to configure, monitor, start, and stop processes).
The Comm Server process relays the first request to the server using the GIOP over TS/MP protocol, and TS/MP selects a server process, within the application server pool, to host a factory object. The factory object creates a stateless worker object and returns the worker's object reference to the Comm Server, which relays the object reference to the client. Subsequent requests from the client are routed through the same Comm Server and sent directly to the same worker object.
server pool can share the same port. When configured this way, the server pool appears as a single IP host to the outside world. A round-robin filter distributes the incoming connections among the communications processes in the pool. Because Parallel Library TCP/IP does the load balancing, when you use it to configure Comm Server processes the LSD process has less work to do than it would if you used separately configured logical Comm Server processes.
Chapter 7. Managing Transactions Chapter 7.
at termination. This means that all other threads must have suspended and that any references to Control , Coordinator , and Terminator object implementations must have been released. Without these checks, some application work might not actually complete within the transaction's boundaries, or a memory leak of object references might go undetected.
Chapter 6. Writing Scalable Applications Chapter 8.
Chapter 8. Writing Multithreaded Applications Chapter 8.
Multithreading in Server Implementations The behavior of the ORB with regard to multithreading depends on the setting of the threading policy in the POA. If the threading policy is set to SINGLE_THREAD_MODEL, client requests are processed sequentially. Although multiple ORB threads might still be used, only one thread is active on the POA at any given time. If you use the default POA threading policy (ORB_CTRL_MODEL), requests can be processed concurrently, in multiple threads.
subdirectory. Refer to the NonStop CORBA 2.6.1 Programmer's Reference for a detailed description of these classes and their methods. HP recommends that NonStop CORBA applications use the vthread API for multithreading because it is object-oriented and easier to use than the POSIX threading (pthread) API. However, if you require conformance to POSIX threading standards, you can use the underlying threading implementation for the specific platform.
appMutex.lock(); //Code to be protected goes here appMutex.unlock(); Alternatively, if needed, you can use the try_lock() method. This method attempts to lock the mutex and returns immediately with a nonzero result if the attempt fails. The class Fw_Thread::Preemption_Mutex is also included in $NSD_ROOT/include/nsdevent/vthread.h . This class, which wraps Fw_Thread::Mutex with a consciousness of preemption, is a no-op on non-preemptive threading platforms such as NonStop systems.
To retrieve the value of a 32–bit entry in the table, call the specific_get() method, passing the associated key returned by specific_key_create() . Terminating Execution of a Thread In a multithreaded process, you must explicitly exit each thread created by the process. This must be done because an application process can be designed to run for an extended period of time, and the threads will be present as long as the process is running. Use Fw_Thread::Exit to terminate the execution of a thread.
Chapter 9. Designing Advanced Applications Chapter 9.
The design of an object interface includes the creation of the object references that clients use to refer to objects in the interface. These object references are created by an object interface associated with the server. The resolution of issues for object interface design depends on the object references that are created and returned, the strategy for finding and creating object instances, and other aspects of interface design and use.
The following example shows an IDL object definition with multiple attributes: interface account { readonly attribute string CustomerName; readonly attribute string CustomerAddress; } If this type of object is distributed, the client must send a separate message to read each attribute.
creation and invocation, you can ensure that the same code will operate correctly regardless of where the object is. Static invocation or dynamic invocation. For example, whether the client will use a predictable set of object interfaces or might find out about new interfaces at run time. Object lifecycle. Issues such as creating, locating, and releasing objects, including how to use the Naming Service. Server selection.
Chapter 8. Writing Multithreaded Applications Chapter 10.
Chapter 10. Porting CORBA Applications to NonStop CORBA Chapter 10. Porting CORBA Applications to NonStop CORBA Global State Information Database Access Applications Using Proprietary Features This section describes general considerations for porting CORBA applications from other ORBs to NonStop CORBA 2.6.1. For specific details about the NonStop CORBA implementation that may be useful in porting applications, see the NonStop CORBA 2.6.1 Programmer's Reference.
Chapter 11. Using the IIOP/SSL API Chapter 11. Using the IIOP/SSL API SSLIOP IDL Interface SSLIOP::Current SSLIOP::Current::get_peer_certificate() SSLIOP::Current::get_peer_certificate_chain() This section describes the objects used by applications to access IIOP/SSL. Note: Before you begin to use IIOP/SSL you must have installed the IIOP/SSL option for NonStop CORBA. For more information about configuring and managing IIOP/SSL, see the NonStop CORBA 2.6.1 Administration Guide.
const const const const ComponentId ComponentId ComponentId ComponentId TAG_CIPHER_INFO = 0; TAG_PEER_DN = 1; TAG_PEER_CERT = 2; TAG_PEER_CERT_CHAIN = 3; struct TaggedData { ComponentId tag; sequence data; }; struct CipherInfo { int cipher_bits; string cipher; }; typedef sequence ServiceContextBody; }; #pragma prefix "omg.
Chapter 12. Writing Wrappers for Legacy Clients and Servers Chapter 12.
Figure 12.1. Legacy Server Wrapper Basic Structure of a Server Wrapper Because it is a NonStop CORBA server, the server wrapper must perform the usual ORB initialization operations: 1. Call ORB::init() . 2. Create a POA. 3. Create a servant. 4. Activate the servant. 5. Call ORB::run() . The ORB::run() operation blocks the main thread until the server is shut down. This blocking allows the event thread to take over to receive I/O events. The wrapper then must receive CORBA requests from the client.
For further information about the SPT_SERVERCLASS_SEND_ procedure, refer to the Open System Services Programmer's Guide (Section 11). Caution: Although you should refer to the Open System Services Programmer's Guide for information about the SPT_SERVERCLASS_SEND_ procedure, do not use the libraries provided by the product; doing so may interfere with the operation of the NonStop CORBA ORB. Instead, use the version of the spthread.
8. After all work is completed, invoke the disconnect() method to shut down the connection. Calling Other Types of Legacy Servers You can write a server wrapper to call on the services of a context-sensitive Pathsend server (nowait) or a Guardian file-system server (nowait). However, doing so is more complex than the cases described in this manual, and therefore it is not recommended that you do so without assistance.
1. Creates a factory object, inheriting from . 2. The factory object creates a listener event-handler object and associates with that event-handler object as its user. 3. The factory object invokes the start_listening() method on the event handler to register interest in incoming connect indications. 4. When a connect indication arrives from the legacy client (such as a Pathsend requester), the factory creates a new worker object (Fw_Server_EH_User ) to handle the connection. 5.
Caution: The same NonStop CORBA server (for example, your client wrapper) cannot receive Pathsend requests from both NonStop CORBA clients and legacy clients. Attempts to send both types of requests to the same process have unpredictable results. Writing a Client Wrapper for a Remote (TCP/IP) Client The client wrapper for a remote (TCP/IP) client is similar to that for a context-free Pathsend requester.
communication between components that use CORBA. The event framework is a low-level mechanism that does not require (but does enable) both communicating components to use CORBA. To provide an optimal tradeoff between coding, performance, and scalability within a process, the event framework uses a hybrid asynchronous (event-driven) and synchronous (threaded) approach.
and transfer data between a client and a server. This abstraction is defined in the header file ehbase.h . The problem space is separated into three session roles and two protocol stack roles. The session roles are the usual listener, client, and server roles. A listener waits for connect indications at a specific address. A client connects to the address; the listener creates a server to handle the session; and then the listener waits for another connection.
The client role adds the connect feature to the transfer role. The client event-handler user asks the client event handler to connect to a specific address. Depending on the outcome of the connect operation, the client event handler performs either a connected or a connect_failed upcall to the client event-handler user. The basic functions of a client event-handler user and a client event handler are shown in Figure 12–5 . Figure 12.5.
Implement the method, or Use the corresponding protocol-specific method from the event framework APIs for the Guardian file system (defined in gfsehoss.h ) or TCP/IP sockets (defined in sockeh.h ). Event Framework Messages and Message Data Descriptors The Fw_MD and Fw_Message classes provide methods to assemble and disassemble messages for use by event handlers and event-handler users. These classes are defined in the header file message.h .
The register_file_number() method in NSDEFw_GCF::Client , however, may be useful in server wrappers that issue nowait Pathsend requests without the use of a jacket procedure. This method makes a file number returned by a Pathsend call available to the NonStop CORBA pthread mechanism for I/O completions. TCP/IP Socket Event Handlers and Event-Handler Users (Classes Fw_Event, Fw_Sock_Client_EH, Fw_Sock_Server_EH, and Fw_Sock_Listener_EH) The classes in the header file sockeh.
Appendix A. Architectural Walkthrough Appendix A.
Figure A-2 expands the view of NonStop CORBA to include several more important concepts. Stubs and skeletons exist for each object type. The ORBs must use one or more transport protocol mechanisms or transport types. If the TCP/IP transport protocol is used, the Bootstrap Service Daemon (BSD), Interoperable Location Service Daemon (ILSD), and Location Service Daemon (LSD) might be called upon, and Comm Servers (CS) might be used. If Comm Servers are used, the LSD must also be used.
A layered architecture view of the NonStop CORBA architecture will look like Figure A-3. In this view the application might be a client, a server, or both. In all cases, the applications use IDL compiler-generated code to communicate with the ORB and POA. If the application needs the Transaction Service, you can link in the OTS run-time. The GIOP layer represents the general inter-ORB implementation. Below the GIOP there are three alternatives.
The following sections elaborate on the static view of NonStop CORBA components shown in Figures A-1 and A-2, by describing one way that requests and responses flow between the components. Walkthrough of Message Flows Using the Naming Service as an Example Message flows in a NonStop CORBA subsystem can be complex. Understanding the patterns is often helpful in debugging an application or tuning for performance. You may find it useful as background information when you deploy applications.
Naming Service calls ORB_init (flow 1 in the figure). Naming Service creates and publishes URL for the root naming context IOR (flow 2 in the figure). Network client imports IOR (flow 3 in the figure). Network client ORB tries to contact target object, for example, Naming Service root naming context (flow 4 in the figure). LSD sends forwarding reply (flows 5 and 6 in the figure). Client ORB tries again (flow 7 in the figure). Comm Server receives and relays request (flows 7 and 8 in the figure).
Naming Service Creates and Publishes Root Naming Context IOR URL (flow 2 in the figure) The Naming Service takes the following actions: Creates a naming context POA with a state policy of stateless. Creates a servant reference (this is an abstract reference). Creates the IOR URL . The information created is stored in the IOR. IOR = object_to_string(servant) . Tsmp profile contains pathmon:server_class . IIOP profile contains lsd1@actual_tcp_address . Object key contains stateless , tsmp relay profile.
Using the mapped Comm Server if mapping is present. (If the mapping is older than 24 hours, it updates the timestamp in the record.) Creating a new mapping for the Comm Server if no mapping is present. To create the mapping, the LSD searches the csmap@load_table for the least busy server, skipping dedicated comm_servers, and writes the new record in csmap@map_table , keyed by client’s TCP/IP address.
Appendix B. Object References Appendix B.
Addresses Servers may be configured as direct or indirect TCP servers: Direct TCP servers are configured with tcp_server true , and the host_name and port_number are specified. These servers communicate directly with TCP sockets. Indirect TCP servers are configured with tcp_server true and use_comm_server true . They are accessed by the NSK message system. Access via TCP will be bridged through a Comm Server. This configuration is useful with stateless servants, and for TCP connection concentration.
There are two distinct types of server pool objects: stateless and stateful. IORs for Stateless Objects in a Server Pool A stateless request (that is, a request for an operation on a stateless object) can go to any free server process within a server pool. The list below explains how NonStop CORBA creates and uses object references for stateless objects. In this scenario, the client can be local or remote with respect to the server pool.
Appendix C. Servant Reference Counting in NonStop CORBA Appendix C. Servant Reference Counting in NonStop CORBA The OMG specification for CORBA 2.6.1 defines two options for servant reference counting: Reference counting using the RefCountServantBase mix-in class No reference counting NonStop CORBA supports both these options and adds a third: reference counting within the CORBA::Object associated with the servant.
Index Index Symbols .profile script, OSS Environment Variables and the env.
functional description, Client Event Handler and Event-Handler User use in server wrappers, Calling a TCP/IP Server Client role in event framework, I/O Event-Handler Framework Client wrappers, legacy basic structure, Basic Structure of a Client Wrapper defined, Writing a Wrapper for a Legacy Client for context-free Pathsend requester, Writing a Client Wrapper for a Context-Free Pathsend Requester for context-sensitive Pathsend requester, Writing Other Types of Client Wrappers for Guardian file-system reques
Context-sensitive Pathsend and stateful CORBA objects, Basic Structure of a Server Wrapper requester, client wrapper for, Writing Other Types of Client Wrappers server wrapper with nowait calls, Calling Other Types of Legacy Servers server wrapper with waited calls, Calling a Context-Free or Context-Sensitive Pathsend Server for Waited Operations Control objects considerations for, Control Objects defined, Object Roles and Relationships use of, Designing Object Interfaces and Classes CORBA objects, Developm
errno variable, use by vthread API, Error Reporting from vthread Methods Error logging and EMS collectors, Starting a Separate EMS Collector for NonStop CORBA Messages and EMS collectors (figure), Starting a Separate EMS Collector for NonStop CORBA Messages calling the error logging facility, Calling the Error Logging Facility component names, Component Names error numbers, Error Numbers example EMS message, Examining EMS Messages examples, Error Logging Examples facility, Design of the Error Logging Facili
Frameworks NonStop CORBA event framework (see Event framework) fs_server (see Application profiles) Fw_Client_EH class, Client Event Handler and Event-Handler User Fw_Client_EH_User class functional description, Client Event Handler and Event-Handler User using in TCP/IP server wrappers, Calling a TCP/IP Server Fw_Listener_EH class, Listener Event Handler and Event-Handler User Fw_Listener_EH_User class functional description, Listener Event Handler and Event-Handler User using in Pathsend client wrappers,
Global state information negative effect on portability, Global State Information negative effect on scalability, Object Distribution Granularity of objects, Object Distribution Guardian file system legacy client wrapper, Writing Other Types of Client Wrappers legacy server wrapper, Calling Other Types of Legacy Servers H handle_event() method, The handle_event Method host_name (see Application profiles) I IDL introduction to, Development Begins with IDL and CORBA Objects IDL compiler code-generation opti
NSDOM_GFS_IOP::Profile_Tag addresses in, NSDOM_GFS_IOP::Profile_Tag Addresses showior tool syntax, The showior Tool Syntax using showior tool to view, Using the showior tool IR defined, Introduction to NonStop CORBA Components J Jacket procedures for multithreading, Using the NonStop CORBA Portable Threading (vthread) API for process-blocking operations, Multithreading in Server Implementations libraries to use in legacy wrappers, Calling a Context-Free TS/MP Server for Nowait Operations SPT_BEGIN_TRANSACT
LSD (see Location Service Daemon (LSD)) M Makefiles, Makefiles Managing processes, using TS/MP, Writing Your Application to Use Server Pools Marshaling costs, limiting, Object Distribution MAXLINKMONS parameter, in TS/MP, Adjusting TS/MP Configuration Parameters MAXLINKS parameter, in TS/MP, Adjusting TS/MP Configuration Parameters MAXSERVERS parameter, in TS/MP, Adjusting TS/MP Configuration Parameters Memory leaks, Checked Transaction Behavior Message buffers adjusting size of, Adjusting Message-Buffer S
ns_browse commands, Examples of ns_browse Commands introduction to, Setting Up ns_browse to View the Naming Service syntax, The ns_browse Tool Syntax NSDAdminServer defined, Components of the NonStop CORBA Environment starting and stopping, Running NSDAdminServer and NSDEnvironServer nsdcfgdb (see Configuration database) NSDEFw_GCF class, TS/MP Event Handlers and Event-Handler Users (Class NSDEFw_GCF) NSDEFw_GFS class functional description, Guardian File-System Event Handlers and Event-Handler Users (Class
using to initialize event framework, Writing a Client Wrapper for a Context-Free Pathsend Requester OSS (see Open System Services (OSS)) OTS client stub, Components of Transaction Service Implementation P Parallel Library TCP/IP, using, Using Parallel Library TCP/IP Parallel processing considerations for, Parallel Processing and Its Implications with stateless and stateful requests, Parallel Processing and Its Implications pathmon (see Application profiles) PATHMON process, role in availability, Stateful a
profile@ORB (see Application profiles) Protocols, transport (see Transport protocols) pthread API libraries to use in NonStop CORBA programs, Using the NonStop CORBA Portable Threading (vthread) API relationship to vthread API, Using the NonStop CORBA Portable Threading (vthread) API using with NonStop CORBA, Using the NonStop CORBA Portable Threading (vthread) API R Recoverable resource manager (RM) file, Use of TMF Reentrant code, Multithreading in Server Implementations , Creating and Using a Mutex Refe
increasing maximum requests to processes in, Adjusting TS/MP Configuration Parameters increasing number of processes in, Adjusting TS/MP Configuration Parameters object design considerations for, Parallel Processing and Its Implications relationship to stateless and stateless objects, Stateful and Stateless Objects using, Using Stateless Objects and Server Pools Server role in event framework, I/O Event-Handler Framework Server wrappers, legacy basic structure, Basic Structure of a Server Wrapper choosing P
SSLIOP::Current::get_peer_certificate, SSLIOP::Current::get_peer_certificate() SSLIOP::Current::get_peer_certificate_chain, SSLIOP::Current::get_peer_certificate_chain() SSLIOP::Sock_Client_EH::send_message, SSLIOP::Sock_Client_EH::send_message SSLIOP::Sock_Server_EH::send_message, SSLIOP::Sock_Server_EH::send_message stack_size (see Application Profiles) start_listening() method figure, Listener Event Handler and Event-Handler User using in Pathsend client wrappers, Writing a Client Wrapper for a Context-F
explanation of, Multithreading in Server Implementations increasing concurrency for, Using Multithreaded Servers Thread-safe code, Multithreading in Server Implementations , Creating and Using a Mutex Threading (see Multithreading) Threading policy, Multithreading in Server Implementations Timer, for vthread API, Using a Timer for a Thread timer.
Transfer event handler and event-handler user, Transfer Event Handler and Event-Handler User Transient objects, State Policy Transparency of objects, local/remote, Designing a Client Transport protocols and state policy, State Policy choosing for performance, Choosing the Most Efficient Transport Protocol information in IORs, Object References profile tags in IORs, Content of Object References selecting for clients, profile@ORB Client Transport Protocols selecting for servers, profile@ORB Server Transport P
terminating a thread, Terminating Execution of a Thread thread-specific data, Saving and Retrieving Thread-Specific Data using a thread, Creating and Using Threads using a timer with, Using a Timer for a Thread yield() method, Using the yield(), join() and cancel() Methods vthread.
