NonStop CORBA 2.3 Programmer's Guide for C++ Next NonStop CORBA 2.3 Programmer's Guide for C++ Part number: 520546001. Published April 2002. Legal Notice Abstract This manual provides information for application programmers about writing applications for Compaq NonStop" CORBA® 2.3 in C++. The information provided focuses on the NonStop CORBA-specific implementation of the Object Management Group's CORBA standards. Product Version: Compaq NonStop" CORBA® 2.
Components of the NonStop CORBA Environment Using the NonStop Distributed Component Console Running NSDAdminServer and NSDEnvironServer Application Profiles: Configuring and Managing an Application 3.
Information Collected in a Trace Categories of Tracing How to Enable and Disable Tracing Calling the Trace Facility Trace Settings for Application Processes Simple Tracing Example How the Trace Facility Interface Works Using the showior tool The showior Tool Syntax Examples of showior Commands Using the esadmin Tool The esadmin Tool Syntax Running the esadmin Tool esadmin Tool Commands Viewing the Naming Service Using the Console to View the Naming Service Setting Up ns_browse to View the Naming Service The
Use of TMF Transaction Service Features Not Supported in NonStop CORBA TransactionalObject Interface Checked Transaction Behavior Transaction Branches and the Diamond Access Problem 8.
Global State Information Database Access Applications Using Proprietary Features 11.
Client ORB Tries Again (flows 6 and 7 in the figure) Comm Server Receives and Relays Request (flows 7 and 8 in the figure) Naming Service Processes Request (flows 8 and 9 in the figure) Comm Server Receives and Relays Reply (flows 9 and 10 in the figure) Client ORB Processes an is_a Reply Summary B.
Copyright 2002 Compaq Information Technologies Group, L.P. Compaq, the Compaq logo, Alpha, Atalla, CLX, Deskpro, Enform, Expand, Guardian, Himalaya, Inspect, Integrity, NonStop, OpenVMS, PayMaster, ProLiant, ServerNet, SignMaster, SNAX, Tandem, VAX, VMS, and WebSafe are trademarks of Compaq Information Technologies Group, L.P. in the U.S. and/or other countries.
information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.
About This Guide Prev Next About This Guide Table of Contents Who Should Read This Guide Organization of this Guide Manuals in the NonStop CORBA Set Your Comments Invited Reader Comments Notation Conventions This NonStop" CORBA® 2.3 Programmer's Guide for C++ provides information about designing and implementing application programs for the NonStop CORBA 2.3 environment. The guide explains how to take advantage of the specific implementation features of NonStop CORBA.
Organization of this Guide Section 1, Introduction to NonStop CORBA Programming, describes prerequisite knowledge and basic design activities. The major components of NonStop CORBA are introduced. Section 2, NonStop CORBA Administrative Environment, describes working in the Open System Services (OSS) environment and in the NonStop CORBA administrative environment. The NonStop Distributed Component Console is introduced. Application profiles are described.
Manuals in the NonStop CORBA Set The NonStop CORBA 2.3 Getting Started Guide describes how to install the product and verify installation. It also includes an introduction to the product. The NonStop CORBA 2.3 Administration Guide gives basic configuration information and describes how to use the NonStop Distributed Component Console and the command-line interface to perform configuration tasks. NonStop CORBA 2.
Also, please include the document title associated with your comments: To help us improve our software documentation, please answer the following questions in your comments: ● Are the documents technically accurate? ● Do they provide the information you need? ● Is the organization and content clear? ● Is the format convenient to use? If you are reporting a documentation error, please cut and paste the section in question into your e-mail message or include a copy of the page in your FAX.
{} | ... "" Other punctuation Long Commands A group of items enclosed in braces is a list from which you are required to choose one item. The items in the list may be arranged either vertically, with aligned braces on each side of the list, or horizontally, enclosed in a pair of braces and separated by vertical lines.
Chapter 1. Introduction to NonStop CORBA Programming Prev Next Chapter 1. Introduction to NonStop CORBA Programming Table of Contents Before You Begin Design Activities Introduction to NonStop CORBA Components Compaq NonStop" CORBA® 2.3 is based on the OMG standards for CORBA 2.3. This guide describes features specific to the NonStop CORBA implementation as the features apply to designing and coding applications.
You must also understand the following characteristics of NonStop CORBA and related products, which are described in later chapters of this guide: ● Advantages and implications of using NonStop TS/MP (TMF programming environment) server classes and stateless or stateful request processing. TS/MP server classes are referred to as server pools in NonStop CORBA.
NonStop CORBA Object Request Broker (ORB) and act as CORBA clients. Clients running elsewhere as network or remote clients These processes reside on some other system (not the same NonStop Himalaya system or Expand network as the NonStop CORBA ORB). The processes act as CORBA clients. Such network clients send IIOP requests for the services of an application through the NonStop CORBA communication services. Network clients often use a different vendor's ORB.
The LSD acts as an Internet InterORB protocol (IIOP) port mapper. The LSD uses an object's object key to determine how to forward requests. The LSD configuration is held in the configuration database. The LSD updates the database for each new client-address/Comm-server mapping, and it updates existing mappings daily. Interoperable Location Service Daemon (ILSD) The ILSD acts as a forwarding agent for the Interoperable Naming Service.
Chapter 2. NonStop CORBA Administrative Environment Prev Next Chapter 2. NonStop CORBA Administrative Environment Table of Contents Working in the Open System Services (OSS) Development Environment Using Guardian Commands and Files Through OSS OSS Environment Variables and the env.
● User commands and utilities. The osh command enters the OSS environment and starts an OSS shell process. To work with NonStop CORBA, you need to have a basic understanding of the OSS environment and you need to know how to use some of the OSS commands. A few of the commands most used in preparing a NonStop CORBA application are described in the following sections.
OSS Environment Variables and the env.sh File A shell implements environment variables that you can set and display. Processes started from the OSS shell can access exported environment variables. For example, NonStop CORBA processes and utilities use environment variables when you configure the system, develop a component, or run an application. The $NSD_ROOT/etc/env.sh file stores shell commands that set environment variables. The env.sh shell script must be executed during shell initialization by using .
modules. Thereafter, when you modify a module on which other modules depend, the make utility automatically initiates recompilation of the dependent modules. The NonStop CORBA sample programs use a Makefile to perform all the steps for building and configuring applications: running the IDL compiler, compiling and linking application programs. c89 This utility is the front end for the C++ compiler. You can invoke c89 from within the make file. nld This utility is the native (TNS/R) linker.
Components of the NonStop CORBA Environment The NonStop CORBA administrative environment has the following components: ● The NonStop Distributed Component Console is a GUI-based interface used to manage the administrative environment. ● Security domains are the processes that are managed under a single user ID. ● Business domains are collections of related business application processes, configuration data, and NonStop services for CORBA. You identify business domains by using the Console.
When you use the Console to make configuration changes, it stores the changes in the configuration database. The Console software also checks entries to make sure they fall between allowed ranges. If you change one field in the Console screens that has dependencies on other fields, the Console will either automatically make changes to the other fields or leave them blank, prompting you to fill in a value.
class. Also, applications obviously must not have any conflicting configuration needs in order to share a profile@ORB database entity. If no -ORBprofile argument is passed in the run command to a NonStop CORBA application, the default@ORB entity is used. This entity acts as a subsystem configuration domain for any settings not found in an application's profile@ORB entity.
If tsmp_server is true, you must specify a name for server_class. fs_server {true | false} Default is false. This configuration is referred to as GIOP over the Guardian file system. profile@ORB Client Transport Protocols One or more of the client transport protocols must be enabled to act as a CORBA client. tsmp_client {true | false} Default is true. fs_client {true | false} Default is true. tcp_client {true | false} Default is true. profile@ORB Miscellaneous Settings These settings are all optional.
is useful when one side is waiting for data (the next request for a server, or a reply for a client) and the other side fails. Prev Chapter 1. Introduction to NonStop CORBA Programming Up Home Next Chapter 3.
Chapter 3. Compiling and Building an Application Prev Next 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.
● Create an object implementation header file based on information found in the server skeleton header. ● Create the server main program and object implementation. Code must be written for each method declared in the IDL interface definition. ● Compile the server implementation code, producing an object file. ● Compile the server skeleton code produced by the IDL compiler, producing an object file.
useful for building any NonStop CORBA application. The samples vary in complexity and illustrate how to use different NonStop CORBA features, such as the Naming and Event Services, stateful and stateless objects, application data in a NonStop SQL/MP database, and writing multithreaded applications. Note The make utility is vital in combining your program modules into a coherent application and enabling you to maintain individual modules.
Note If you change your .profile file, be sure to source it in for the changes to take effect. IDL Compiler Syntax Preliminary IDL Compiler Setup The IDL compiler is a Java application packaged in the $NSD_ROOT/idl/nsdidl.jar file. This jar file contains all necessary compiler class files. A reference to the nsdidl.jar file is normally added to the CLASSPATH environment variable by env.sh.
compiler generates a delegating class called a tie. This class is partially opaque to the application programmer, though like the skeleton, it provides a method corresponding to each OMG IDL operation. The name of the generated tie class is the same as the generated skeleton class with the addition that the string _tie is appended to the end of the name. -h suffix Specify the file suffix used for generated C++ header files. By default h is used for C++ header files.
nsdidl Compiler Error Handling If you make an error while entering a compiler option, the following message appears: nsdidl: Error: unknown option: -demo, use: nsdidl [-?][-v][-D name][-D name=definition][-U][-I dir][-language (C++ | J ava)][-version][-o dir][-generate arg][-h suffix][-s suffix][-client suffix][-se rver suffix][-no_][-include level][-typecodes][-IR][-ir][-preprocessor arg][-pre processed][-map2package module package][-dll define-name][filename]* 1 error In the command line, you must place a
Chapter 4. Deploying a NonStop CORBA Application Prev Next Chapter 4. Deploying a NonStop CORBA Application The general steps to consider 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.
environments, see the TS/MP System Management Manual (note that in TS/MP documentation, server pools are called server classes). The following sample OSS script illustrates how the environment might be configured: In the following script, the trace settings have been disabled by placing the comment character open bracket [ in front of the line. For more information about tracing see Tracing and Debugging Applications. # # # # # # # # # Bank server PATHMON start-up and configuration script.
# Start a PATHMON environment: # 1. Get "default" volume name. This is where the PATHCTL file is # created by PATHMON. We'll create the PATHMON log file there as well. # 2. Blindly create the PATHMON log file. If it is already there, ignore # the error. # 3. Start the PATHMON process PMLOG=$(info_define -detail =_DEFAULTS | awk '/VOLUME/ {print $3}').${PATHMON}LOG gtacl -c "fup create $PMLOG" > /dev/null 2>&1 gtacl -c "pathmon/name \$$PATHMON,nowait,out $PMLOG/" sleep 1 # Configure the pathway server pool.
set server env NSDOM_CFG_DBM=$NSDOM_CFG_DBM set server arglist "-ORBprofile", "bank_server_pool" [ [ [ [ set set set set server server server server env env env env NSDOM_CFG_TRACE_POA=1 NSDOM_CFG_TRACE_PROXY=1 NSDOM_CFG_TRACE_GIOP_FW=1 NSDOM_CFG_TRACE_GCFEH=1 $APPL_TRACE_ENABLED [ define to use SRL set server define =_SRL_01, class map, file $NSD_SRL_SUBVOL.NSDSRL set server stdin /dev/null set server stdout $PWD/server.log set server stderr $PWD/server.
Chapter 5. Tracing and Debugging Applications Prev Next Chapter 5.
Viewing the Naming Service Using the Console to View the Naming Service Setting Up ns_browse to View the Naming Service The ns_browse Tool Syntax Examples of ns_browse Commands Troubleshooting Application Components Troubleshooting a NonStop CORBA application or component involves evaluating information from the following sources: ● System exceptions raised by the NonStop CORBA run-time environment, reported to the client program.
For a more general understanding of NonStop CORBA component interactions, architecture, and message flows, see Appendix A, Architectural Walkthrough. Using the Error Logging Facility Unexpected conditions detected by NonStop CORBA can be logged through the Event Management Service (EMS) on NonStop Himalaya systems. Looking at the log messages is one of the first things to do when troubleshooting a problem. Often the source of a problem can be ascertained readily from information contained in the log.
Name of the process that logged the error Process ID of the process that logged the error Thread ID of the thread that logged the error Exception type (not all log messages are associated with an exception) Exception name (not all exceptions are named) Name of source file that logged the error Line number of the source file that logged the error PName PId TId ExcptType ExcptName File Line While much of this information is composed by the error logging facility at the time the call is made, you must supply
To start an alternate collector for the NonStop CORBA Software Developer Kit (SDK) environment, you enter the following commands at the 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 MY_COLLECTOR in the $NSD_ROOT/etc/env.sh file or in log_file in the default@ORB entity in the configuration database.
The date and time of the event is given first. Because the log might contain many messages from a number of different processes, examining EMS messages that were logged during a particular interval is a useful strategy. The second part contains the text error message GIOP Proxy demarshal 0 profiles, which provides information that can help you troubleshoot the problem.
NSDOM_LOG_INFO_ENV(pv_err_num, pp_text, pp_env) ; NSDOM_LOG_SET_COMPONENT_NAME(pp_comp_name) ; #define NSDOM_LOG_SET_LOG_FILE(pp_log_file_name) ; 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.
NSDOM_Error_Log::get_default().log_critical(__FILE__, __LINE__, \ pv_err_num, pp_text, pp_exc); NSDOM_Error_Log::get_default().log_error(__FILE__, __LINE__, \ pv_err_num, pp_text); NSDOM_Error_Log::get_default().log_error(__FILE__, __LINE__, \ pv_err_num, pp_text, pp_exc); NSDOM_Error_Log::get_default().log_info(__FILE__, __LINE__, \ pv_err_num, pp_text); NSDOM_Error_Log::get_default().log_info(__FILE__, __LINE__, \ pv_err_num, pp_text, pp_exc); NSDOM_Error_Log::get_default().
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().OK()) // log an error LOG_ERROR_ENV( 7003, "Error writing to CustDB", lv_env); ...
// log critical/error/warning/info message // void log_critical(char *pp_src_file_name, // name of src file int pv_src_line_num, // line num of src long pv_err_num, // error number char *pp_text); // text void log_critical(char *pp_src_file_name, // name of src file int pv_src_line_num, // line num of src long pv_err_num, // error number char *pp_text, // text const CORBA::Exception &pr_ex); // exception void log_error(char *pp_src_file_name, // name of src file int pv_src_line_num, // line num of src long
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. In this case, focusing more narrowly on the server hosting the object should prove fruitful. NonStop CORBA provides tracing for a number of internal components, which you can control by using specific trace settings. However, you should be judicious in enabling tracing because the volume of output can be large.
NSDOM_CFG_TRACE_ES event_svc n/a trace (in NS@name _service_settings) NSDOM_CFG_TRACE_IR ir NSDOM_CFG_TRACE_GCFEH event_context_free NSDOM_CFG_TRACE_GFSEH event_file_system NSDOM_CFG_TRACE_SOCKEH NSDOM_CFG_TRACE_SOCKEH_DETAIL event_socket NSDOM_CFG_TRACE_EVENT_CORE event_core NSDOM_CFG_TRACE_GIOP_FW orb_giop_connections NSDOM_CFG_TRACE_ORB orb_request_queue NSDOM_CFG_TRACE_POA poa NSDOM_CFG_TRACE_OTS none NSDOM_CFG_TRACE_PROXY NSDOM_CFG_TRACE_PROXY_DETAIL orb_proxy NSDOM_CFG_TRACE_TH
NSDOM_CFG_TRACE_FULL_BUFFERING none If STDOUT is configured, sets full buffering on (default is full buffering) How to Enable and Disable Tracing You can enable tracing by using one of the following techniques: ● Use the NonStop Distributed Component Console. The Console updates the configuration database. The Console can only change trace settings for NonStop CORBA subsystem processes, not user application processes. ● Use the cfgmgt tool to modify the configuration database directly.
Removing the open bracket ([) uncomments the line. When you enable tracing by using an export statement, you can set individual environment variables as shown by this example: export NSDOM_CFG_TRACE_PROXY=TRUE Clearing the environment variable is done by using the unset statement. For example, unset NSDOM_CFG_TRACE_PROXY Caution You need to be very careful to keep changes made with the Console and changes made to the nsdstart script consistent with your intentions.
Naming Service NSDOM_CFG_TRACE_ORB NSDOM_CFG_TRACE_POA OTS NSDOM_CFG_TRACE_ORB NSDOM_CFG_TRACE_POA NSDOM_CFG_TRACE_OTS XID Broker NSDOM_CFG_TRACE_ORB NSDOM_CFG_TRACE_POA NSDOM_CFG_TRACE_OTS NSDOM_CFG_TRACE_POA NSDOM_CFG_TRACE_PROXY NSDOM_CFG_TRACE_ORB NSDOM_CFG_TRACE_GIOP_FW NSDOM_CFG_TRACE_GFSEH NSDOM_CFG_TRACE_GCFEH NSDOM_CFG_TRACE_POA NSDOM_CFG_TRACE_PROXY NSDOM_CFG_TRACE_ORB NSDOM_CFG_TRACE_OTS NSDOM_CFG_TRACE_GIOP_FW NSDOM_CFG_TRACE_GFSEH NSDOM_CFG_TRACE_GCFEH NSDOM_CFG_TRACE_POA NSDOM_CFG_TRACE_
Trace Settings for Application Processes To enable tracing for an NonStop CORBA client or server process, set one or more environment variables prior to running the process. For a client process, setting NSDOM_CFG_TRACE_PROXY to TRUE is a useful starting point. If more detail is needed, enable one or more of the protocol trace variables (depending on the protocols in use by the client). For a server process, setting NSDOM_CFG_TRACE_POA to TRUE is a useful starting point.
static void open_trace_file (CORBA::Environment &pr_env); static void close_trace_file (CORBA::Environment &pr_env); static void log_trace (char *pp_trace_data, short pv_trace_data_len, CORBA::Environment &pr_env); }; Trace Method Descriptions The NSDOM_Trace::log_trace() method writes a trace message to the trace file.
The -o switch decodes and displays the object key information in a form similar to that displayed by the Console (see Figure 5.3). IOR-filename This option specifies the name of the IOR file to be displayed. The default filename is objref. Examples of showior Commands The following command runs showior with the default display and default IOR file objref. showior The next command runs showior with the -o switch enabled to show the object key information. The filename specified is NameService.
c:\jorblite\lib\NameService The CLASSPATH and PATH settings can be changed by editing and running the env.bat file. The esadmin Tool Syntax esadmin esadmin has no options. Running the esadmin Tool When you run esadmin, it gathers the list of the event channels stored in the NonStop CORBA Naming Service database. The tool displays this list in a dialog box from which you can select the event channel to administer, as shown in Figure 52 . Figure 5.2.
The Event Channel Status window displays statistics for the specified event channel. The statistics displayed are updated periodically. To adjust the update interval, go to the Admin menu and click Preferences. Set the desired update interval using the dialog displayed. To display and alter event channel policies, go to the Admin menu and click Policies. This command displays the current policy values.
An example of the Console view of the Naming Service is shown in Figure 53 . Figure 5.3. Naming Service Display For more information about using the Console, see the NonStop CORBA 2.3 Administration Guide and the online help provided with the Console. Setting Up ns_browse to View the Naming Service The ns_browse tool runs on the NonStop Himalaya system, and it allows you to look at entries stored in the Naming Service database.
This option specifies one of the following operation commands: bind bind_context bind_new_context destroy list new_context rebind rebind_context remove_context resolve unbind Note that the specified operation is performed against the base naming context, as specified with the -ior option. Each operation is described in detail below. bind object-name stringified-IOR This option binds the name specified by object-name to the object whose IOR is specified by stringified-IOR.
resolve object-name This option returns the stringified IOR of the object which is bound to the name specified by object-name. unbind object-name This option unbinds the name specified by object-name from the object it is currently bound to. Examples of ns_browse Commands The following commands demonstrate how the ns_browse tool works: 1. Run ns_browse without any parameters, as follows: ns_browse This command causes the tool to display usage information. 2.
Chapter 4. Deploying a NonStop CORBA Application Home Chapter 6.
Chapter 6. Writing Scalable Applications Prev Next Chapter 6.
● Configure application server processes as server pools. NonStop CORBA then uses the capabilities of TS/MP to spread the workload among multiple processes, adds new processes as needed, and provides load balancing. ● Configure the Comm Server, LSD, ILSD, and/or BSD processes in your NonStop CORBA system to use Parallel Library TCP/IP, so that a single TCP/IP port is shared by multiple communications processes. ● Increase the number of Comm Server processes to support increased request traffic.
Stateful and Stateless Objects In NonStop CORBA, objects can be either stateful or stateless. The use of stateful and stateless objects is closely related to the use of server pools. If an object is stateful, all operations directed to that object must be handled by the same servant (instance of the object). Operations directed to other objects in the class can be handled by different servants in other processes.
The state policy (PortableServer::StatePolicy) is a NonStop CORBA proprietary policy you can apply to allow persistent stateful objects in a server-pool process to be accessed by the GIOP over TS/MP transport protocol. (By default, an object with a lifespan policy of PERSISTENT is assumed to be stateless.) The state policy has two values: STATEFUL and STATELESS.
provides for additional load balancing. If you use a stateful POA for a servant in a TS/MP process, always set the DELETEDELAY parameter in the TS/MP configuration to zero. Otherwise, TS/MP server processes are deleted if they are inactive for some time, even if a stateful session is still in progress. The use of stateful servants thus disallows dynamic shrinking of the server pool.
ILSD, and BSD process runs as a server pool consisting of one process listening at an assigned TCP/IP port; thus there is a one-to-one ratio between communications processes and ports. When you configure these processes with Parallel Library TCP/IP, up to sixteen Comm Server, LSD, ILSD, or BSD processes running in a server pool can share the same port. When configured this way, the server pool appears as a single IP host to the outside world.
Parallel Library TCP/IP is the recommended alternative. If you do not use Parallel Library TCP/IP, it is recommended that you configure multiple Comm Server processes to avoid performance bottlenecks. You can also use the two alternatives in combination if you need more than sixteen Comm Server processes.
Chapter 7. Managing Transactions Prev Next Chapter 7.
NSOTS and TMF communicate through a pseudo-file called a recoverable resource manager (RM) file. They exchange signals through this file using the TMF APIs. These signals are used to start and terminate transactions. The RM file is also used during the initialization of NSOTS to recover any in-doubt transactions following a failure. The operations tmf_start and tmf_end are added to the CosTransactions::Current interface to control the participation of NSOTS in outstanding TMF transactions.
may potentially be working on the transaction, the Transaction Service components of NonStop CORBA throw the exception BAD_INV_ORDER. Transaction Branches and the Diamond Access Problem Because of the way TMF handles distributed transactions, you may need to design your application to avoid database access deadlocks between transaction branches, sometimes called the diamond access problem. This problem is not specific to NonStop CORBA, and can occur in any system where TMF is used.
In this figure, the application starts a debit/credit transaction on System A. The debit account is held on System B and the credit account is held on System C. System D has an object that requires input from both debits and credits (in this case a Bank Vault Account that tracks debits and credits). The problem occurs when Systems B and C attempt to write to the Bank Vault object on System D. At that time, one write operation might be locked out by the other.
In configurations where the NSotsTM process runs as a server pool with multiple processes, contention between NSotsTM processes can cause the diamond access problem to occur. To avoid this cause of the problem, no application changes are required. NonStop CORBA provides the NSotsXID process to act as a broker between NSotsTM processes, so that only one process has control at a time.
Chapter 8. Writing Multithreaded Applications Prev Next Chapter 8.
Note On NonStop Himalaya systems, threads are not run in separate processors. To take advantage of parallel processing, use separate processes rather than threads. Multithreading on NonStop Himalaya systems is non-preemptive. Multithreading in Client Applications One typical use of multithreading in NonStop CORBA client programs is to issue concurrent requests to one or more objects. When multithreading is not used, operations are synchronous.
vthread API provides a mutex mechanism for thread-safe programming. ● NonStop CORBA provides jacket procedures for some Guardian calls, which essentially convert process-blocking calls to thread-blocking calls. Such jacket procedures are available for some TS/MP and TMF calls. See the NonStop DCE Application Programming Guide for more information about these jacket procedures.
Creating and Using Threads To create and use threads through the vthread API, perform the following steps: 1. Include the $NSD_ROOT/include/nsdevent/vthread.h header file in your program: #include 2. Create a function that will be the body of a thread in the global area of your application; for example: void my_function (void* threadArg); This function cannot be a class instance method; otherwise a compiler error occurs.
1. Include the $NSD_ROOT/include/nsdevent/vthread.h header file in your program: #include 2. Define a mutex: Fw_Thread::Mutex appMutex; 3. Enclose the critical section of codefor example, the portion of code that modifies critical datawith calls to lock() and unlock(): appMutex.lock(); //Code to be protected goes here appMutex.unlock(); Alternatively, if needed, you can use the try_lock() method.
the condition variable, the current owner of the condition variable must unlock the associated mutex. Since a mutex is built into a condition variable, you do not need to declare a separate mutex for the condition variable. All you need to do is to enclose the critical section of code with the lock() and unlock() member functions of the condition variable and use the wait() and signal() member functions as indicated above. If needed, you can use the broadcast() method in place of the signal() method.
1. Include the $NSD_ROOT/include/nsdevent/timer.h header file in your program: #include 2. Declare and initialize a timer, as in the following example that sets a five-second timer: NSDEFw_Timer::my_app_timer (5*Fw_Time_Stamp::Ticks_Per_Second); 3. At the point in the thread where a pause is required, call the NSDEFw_Timer.wait() function to wait for the set time period: my_app_timer.wait(); Note The timer.
Chapter 9. Designing Advanced Applications Prev Next Chapter 9.
other platforms. ● The role of each object interfacefor example, whether each object represents an entity in a databaseand the relationships among objects. ● Local/remote transparency. The implications of having users, information, and therefore objects distributed across a network. ● Reuse. How to reuse existing software whenever possible by deriving new object interfaces or classes from existing ones. ● Granularity.
Object Roles and Relationships The following three-tier classification of object roles is not specific to NonStop CORBA but is used throughout this section: ● Interface objects typically run on a client workstation or other end-user device, such as a bank-teller input device or a gas-station pump. ● Control objects typically run on a server machine.
described in Parallel Processing and Its Implications. Entity Objects An entity object typically represents stored data, although it could also represent a device. Entity objects can be used by either interface objects or control objects: an interface object need not always use a control object for access to an entity object.
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.
Parallel Processing and Its Implications NonStop CORBA can run application servers as server pools. This style of implementation allows many processes to act as one logical server; each new unit of work goes to the next available free server process in the pool. Server processes can run in different processors to allow for parallel processing.
an object interface. ● Server pools. Implications of the use of server pools and whether the use of server pools must be transparent to the application. ● Transaction management. Whether a client or object has responsibility for managing nested transactions. ● Concurrency. Whether clients or an object must coordinate concurrent access to data, and whether the client requires threads. ● Interoperability.
Taking Advantage of Concurrency If your application has the potential for concurrency (that is, it includes thread-blocking operations but not process-blocking operations), you may be able to use multithreading to reduce the number of processes required to handle a given workload. For details, refer to Writing Multithreaded Applications. If your application performs process-blocking operations, you can take advantage of process concurrency by using server pools.
Chapter 10. Porting CORBA Applications to NonStop CORBA Prev Next Chapter 10. Porting CORBA Applications to NonStop CORBA Table of Contents 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.3. For specific details about the NonStop CORBA implementation that may be useful in porting applications, refer to the NonStop CORBA 2.3 Programmer's Reference.
Prev Chapter 9. Designing Advanced Applications Up Home Next Chapter 11.
Chapter 11. Writing Wrappers for Legacy Clients and Servers Prev Next Chapter 11.
For example, you might have an operational Pathway server program that you want to make accessible to remote CORBA clients. By creating a legacy server wrapper, you can provide an object-oriented CORBA interface to your legacy server without making changes to the legacy server itself. You can also develop a legacy client wrapper to allow non-CORBA clients to make use of a CORBA server.
3. Demarshal the legacy reply message. 4. Translate the legacy results into CORBA interface components. 5. Return. If the POA for your server wrapper uses the default threading policy (ORB_CTRL_MODEL), NonStop CORBA automatically creates a new thread, as needed, for each CORBA request to the wrapper. Existing threads are recycled; when a request completes, its thread is returned to the thread pool for later reuse.
Caution Although you should refer to the NonStop DCE Application Programming Manual for information about the DCE_SERVERCLASS_SEND_ procedure, do not use the libraries provided by the NonStop DCE product; doing so may interfere with the operation of the NonStop CORBA ORB. Instead, use the version of the pthread.h header file provided in the $NSD_ROOT/include directory, which includes the DCE_SERVERCLASS_SEND_ procedure and all necessary underlying routines.
the underlying event framework. To send such requests, the wrapper invokes the services of a client event handler through the event framework API. The server wrapper acts as a user of a client event handler: in other words, a client event-handler user. NonStop CORBA provides various types of client event-handler objects to support transport functions such as I/O completions and error handling.
Caution Although you should refer to the NonStop DCE Application Programming Manual for information about the NonStop DCE procedures, do not use the libraries provided by the NonStop DCE product; doing so may interfere with the operation of the NonStop CORBA ORB. Instead, use the version of the pthread.h header file provided in the $NSD_ROOT/include directory, which includes the NonStop DCE procedures and all necessary underlying routines.
A client wrapper operates as follows: 1. Creates a factory object, inheriting from Fw_Listener_EH_User. 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.
workCompleted.lock(); workCompleted.signal(); workCompleted.unlock(); } The wait_for_completion() method is used to wait for the client-wrapper factory object to complete its work: void Client_Wrapper::Factory::wait_for_completion() { workCompleted.lock(); workCompleted.wait(); workCompleted.unlock(); } 5. When OPEN messages arrive on $RECEIVE, the event handler invokes the factorys connect_in() method. The connect_in() method creates a worker to service that connection.
incoming connect indications. 4. When a connect indication arrives from the legacy client, the factory creates a new worker object (Fw_Server_EH_User) to handle the server side of the connection. 5. Acting as the server event-handler user, the new worker object creates a socket server event-handler object (Fw_Sock_Server_EH) and associates itself with that event-handler object as its user. 6.
and methods in these APIs, refer to the NonStop CORBA 2.3 Programmer's Reference. Design of the Event Framework The NonStop CORBA event framework supports the handling of I/O events over various transport protocols. It is the core of the NonStop CORBA run-time environment and is designed to fit the needs of the ORB. Note The NonStop CORBA event framework is distinct from the Event Service, which is defined by OMG and is part of the Common Object Services.
core makes an upcall to the registered event handler. The types of events that an event handler can register with the core are: Time Tell me when n ticks have elapsed. Outside of the ORB internals, Fw_Timer events are most often used in their derivative form, NSDEFw_Timer, which blocks a thread for a specified interval. This usage is described in Using a Timer for a Thread. Socket I/O Tell me when a completion occurs on socket n.
The semantics of the NonStop CORBA event handlers lend themselves readily to TCP/IP, which is a streaming protocol. However, more specific protocols were developed to provide the correct semantics for GIOP over the Guardian file system and GIOP over TS/MP. Therefore the socket event handlers defined in the event framework are likely to fit the needs of a legacy wrapper, but the file-system and TS/MP event handlers in the event framework often will not do so.
Client Event Handler and Event-Handler User 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 125 . Figure 11.5.
Contains classes and methods for Guardian file-system I/O. gcfehoss.h Builds on the definitions in gfsehoss.h and adds classes and methods for TS/MP I/O. sockeh.h Contains classes and methods for TCP/IP socket I/O. The $NSD_ROOT/include/nsdevent subdirectory also contains the vthread.h and timer.h header files, whose contents are described in Writing Multithreaded Applications, and several other header files containing definitions for NonStop CORBA internal use.
The Fw_MD, or framework message data descriptor, class provides an abstraction for a single segment of data and a get/put recycling factory. Fw_MD objects can be written to and read from, and can be combined to form an abstract message (Fw_Message object). The message data descriptor object allows a long message to be transmitted and received in fragments. See also Transfer Event Handler and Event-Handler User.
to provide an Fw_Listener_EH implementation. Class NSDEFw_GFS::Server The NSDEFw_GFS::Server class provides classes and methods needed by a server event handler that performs Guardian file-system style communication with a legacy client in cooperation with a listener event handler.
Appendix A. Architectural Walkthrough Prev Next 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 would 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.
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. This section describes the flow of messages from a client to and from a single service, the Naming Service, as an example of how the flow might happen in a typical application.
● Comm Server receives and relays reply (flows 9 and 10 in the figure). ● Client ORB processes reply. The client is now ready to execute methods against the root naming context. The following sections describe each of the above events in more detail: Naming Service Calls ORB_init (flow 1 in the figure) When the Naming Service calls ORB_init, the NS@ORB entity is read. The ORB sets up a GIOP server component for the configured server transport protocols.
ORB.resolve_initial_references (NameService) , for example), but this relatively simple way is used for this example. Network Client ORB Tries to Contact Target Object (flow 4 in the figure) Once it has the CORBA::Object, the client ORB narrows the reference to a COSNaming Naming Context. The client ORB must determine if the target object is a naming context, so it performs the following: ● Connects to the address in the IIOP profile (LSD). ● Sends an _is_a request to the LSD.
Comm Server Receives and Relays Reply (flows 9 and 10 in the figure) When the server_agent receives the reply, it ● Demarshals the reply through the request ID. ● Interposes original request ID. ● Asks the originating client_agent to relay the reply. The client_agent then relays the reply (flow 10 in the figure), sending the reply message on its connection. Client ORB Processes an is_a Reply Now the client ORB demarshals the reply. It ● Sees the result is true.
Appendix B. Object References Prev Next Appendix B.
Obtaining Object References NonStop CORBA obtains server IORs at three points: ● Explicitly, when the application calls CORBA::Object::object_to_string(). This action is usually done when an IOR must be "hand delivered" to a client, for example, during initial testing of a system when the Naming Service is being avoided. ● Implicitly, when an object is returned as an out parameter or result for an operation. An example is found in the Naming Service resolve() operation.
NSDOM_GCF_IOP::Profile_Tag Addresses If a server is configured to enable GIOP over TS/MP (tsmp_server true), the profile address will contain pathmon-process-name and server-class. NSDOM_GFS_IOP::Profile_Tag Addresses If a server is configured to enable GIOP over the Guardian file system (fs_server true), the address field will contain a Guardian file system address. If the servant's POA has the PERSISTENT lifespan policy, the profile address will be set to pname.subdevice.
tcp_server tcp_process host_name port_number true $ztc1 oss2.widget.com 0 When NonStop CORBA builds an IOP::TAG_INTERNET_IOP profile, the profile's host field must be in dot-decimal form to avoid having to export the DNS/host-file configuration to every client. Also, the port field must have the actual port number selected by TCP if it was configured as 0.
pool after sending the reply This behavior is similar to the CORBA process-per-request scenario. Because NonStop CORBA establishes a new TS/MP link to process each request, load balancing occurs at the time of the request. IORs for Stateful Objects in a Server Pool A stateful request (that is, a request for an operation on a stateful object) must always go to the process where the object was created. Therefore, NonStop CORBA generates a reference for a stateful object.
Appendix C. Servant Reference Counting in NonStop CORBA Prev Next Appendix C. Servant Reference Counting in NonStop CORBA The OMG specification for CORBA 2.3 defines two options for servant reference counting: ● Reference counting using the RefCountServantBase mix-in class ● No reference counting The NonStop CORBA 2.3 product supports both these options and adds a third: reference counting within the CORBA::Object associated with the servant.
NSDOM_ServantBase::_remove_nsd_ref() { if (_uses_which_ref_type() == Uses_NSDOM_ref_count) { CORBA::release( this->_this_reference() ); } else this->_remove_ref(); } Prev Appendix B.
Index Prev Index Symbols pthread API libraries to use in NonStop CORBA programs, Using the NonStop CORBA Portable Threading (vthread) API .profile script, OSS Environment Variables and the env.
B BAD_INV_ORDER exception, Checked Transaction Behavior Basic Object Adapter (BOA), porting considerations, Applications Using Proprietary Features Bootstrap Service Daemon (BSD) reconfiguring for scalability, Adjusting TS/MP Configuration Parameters Bootstrap Service Daemon (BSD) defined, Introduction to NonStop CORBA Components using with Parallel Library TCP/IP, Using Parallel Library TCP/IP broadcast() method, Creating and Using a Condition Variable Buffer size adjusting for performance, Adjusting Messa
transaction management in, Managing Transactions in Client Wrappers Clients design considerations for, Designing a Client network, Design Activities running on Himalaya, Design Activities Comm Servers defined, Introduction to NonStop CORBA Components increasing number of, Increasing the Number of Comm Server Processes reconfiguring for scalability, Adjusting TS/MP Configuration Parameters using with Parallel Library TCP/IP, Using Parallel Library TCP/IP Compiler options See IDL compiler Concurrency and clie
requester, client wrapper for, Writing a Client Wrapper for a Context-Free Pathsend Requester server wrapper with waited calls, Calling a Context-Free or Context-Sensitive Pathsend Server for Waited Operations Context-free Pathsend and stateless CORBA objects, Basic Structure of a Server Wrapper server wrapper with nowait calls, Calling a Context-Free Pathway Server for Nowait Operations Context-sensitive Pathsend and stateful CORBA objects, Basic Structure of a Server Wrapper Context-sensitive Pathsend req
DCE_SERVERCLASS_SEND_ procedure, Calling a Context-Free Pathway Server for Nowait Operations Delegation, Object Distribution Deploying applications, Deploying a NonStop CORBA Application Designing applications, Designing Advanced Applications detach() method, in vthread API, Detaching a Thread Diamond access problem, Transaction Branches and the Diamond Access Problem Direct TCP/IP server, Addresses disconnect() method figure, Transfer Event Handler and Event-Handler User disconnect() method using in TCP/IP
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 Facility information system supplies, System-Supplied Information information you must supply, User-Supplied Information interface, How the Error Logging Facility Works introduction to, Using the Error Logging Facility log entries, Design of the Error Logging Faci
Event Service contrasted with event framework, Design of the Event Framework managing with esadmin, Using the esadmin Tool Event-handler role in event framework, I/O Event-Handler Framework Event-handler user role in event framework, I/O Event-Handler Framework Exceptions from TMF, Use of TMF Exit() method, in vthread API, Terminating Execution of a Thread F Factory objects in application design, Designing Object Interfaces and Classes stateless, using for scalability, Using Stateless Factory Objects to Cr
functional description, Class Fw_MD Fw_Message class functional description, Class Fw_Message using in TCP/IP server wrappers, Calling a TCP/IP Server Fw_Server_EH class, Server Event Handler and Event-Handler User Fw_Server_EH_User class functional description, Server Event Handler and Event-Handler User using in Pathsend client wrappers, Writing a Client Wrapper for a Context-Free Pathsend Requester using in TCP/IP client wrappers, Writing a Client Wrapper for a Remote (TCP/IP) Client Fw_Sock_Address clas
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 options, IDL Code-Generation Options errors, nsdidl Compiler Error Handling introduction
Interoperable Location Service Daemon (ILSD) defined, Introduction to NonStop CORBA Components using with Parallel Library TCP/IP, Using Parallel Library TCP/IP Interoperable Naming Service (INS), Introduction to NonStop CORBA Components Interoperable object references See IORs io_size configuration option, Adjusting Message-Buffer Sizes IORs actual TCP/IP addresses in, Configured Versus Actual TCP/IP Addresses and stateful objects in server pools, IORs for Stateful Objects in a Server Pool and stateless ob
L Legacy clients, wrappers for, Writing a Wrapper for a Legacy Client Legacy servers, wrappers for, Writing a Wrapper for a Legacy Server Legacy wrappers, defined, Writing Wrappers for Legacy Clients and Servers Lifespan policy, relationship to state policy, State Policy LINKMON processes increasing maximum requests from, Adjusting TS/MP Configuration Parameters increasing number that can communicate with servers, Adjusting TS/MP Configuration Parameters Listener event handler and event-handler user functio
See Error logging log_file See Application Profiles 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 buf
Naming Service adding, renaming, or removing a context, Using the Console to View the Naming Service how to view, Viewing the Naming Service using ns_browse with, Setting Up ns_browse to View the Naming Service viewing with Console, Using the Console to View the Naming Service NonStop CORBA architecture basic (figure), Architectural Walkthrough extended view (figure), Architectural Walkthrough layers (figure), Architectural Walkthrough message flows, Walkthrough of Message Flows Using the Naming Service as
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 NSDEFw_GFS) using in Pathsend client wrappers, Writing a Client Wrapper for a Context-Free Pathsend Requester NSDEFw_Timer class, Using a Timer for a Thread NSDEnvironServer defined, Components of the NonStop CORBA Environment starting and stopping, Running NSDAdminServer and NSDEnvironServer nsdidl See IDL compiler nsdo
introduction to, Working in the Open System Services (OSS) Development Environment using Guardian commands and files with, Using Guardian Commands and Files Through OSS Open System Services (OSS) tools, OSS Development and Debugging Tools ORB other vendor's, Troubleshooting Application Components ORB_CTRL_MODEL threading-policy setting, Multithreading in Server Implementations ORB_init() method used by event framework to launch null thread, Null Thread using to initialize event framework, Writing a Client W
Waited Operations Pathway protocol See GIOP over TS/MP protocol Pathway server wrapper with nowait calls, context-free, Calling a Context-Free Pathway Server for Nowait Operations wrapper with nowait calls, context-sensitive, Calling Other Types of Legacy Servers Pathway server classes See Server pools Performance, tuning NonStop CORBA applications for, Tuning Applications for Performance Persistent objects and state policy, State Policy in application design, Designing Object Interfaces and Classes POA pol
increasing concurrency for, Using Multithreaded Servers isolating in applications, Object Distribution jacket procedures to convert to thread-blocking, Multithreading in Server Implementations Processes automatic restart, Stateful and Stateless Objects management using TS/MP, Writing Your Application to Use Server Pools priority, Adjusting Process Priorities profile@ORB See Application profiles Protocols, transport See Transport protocols pthread API relationship to vthread API, Using the NonStop CORBA Port
S Scalability features automatically provided, Writing Scalable Applications taking advantage of, Writing Scalable Applications using server pools for, Using Stateless Objects and Server Pools Scripts .profile, OSS Environment Variables and the env.
changing processor assignments for, Adjusting TS/MP Configuration Parameters client design considerations, Designing a Client implemented as TS/MP server classes, Design Activities increasing number of processes in, Adjusting TS/MP Configuration Parameters increasing maximum requests to processes in, Adjusting TS/MP Configuration Parameters object design considerations for, Parallel Processing and Its Implications using, Using Stateless Objects and Server Pools Server wrappers, legacy basic structure, Basic
introduction to, Using the showior tool syntax, The showior Tool Syntax signal() method, Creating and Using a Condition Variable signal_completion() method, Writing a Client Wrapper for a Context-Free Pathsend Requester SINGLE_THREAD_MODEL threading-policy setting, Multithreading in Server Implementations Skeletons (figure), Development Process Socket protocol wrapper for legacy client using, Writing a Client Wrapper for a Remote (TCP/IP) Client wrapper for legacy server using, Calling a TCP/IP Server speci
Stateless objects and IORs, IORs for Stateless Objects in a Server Pool and server pools, Stateful and Stateless Objects defined, Stateful and Stateless Objects factory, Using Stateless Factory Objects to Create Stateful Servants POA policy for, State Policy Static invocation, Designing a Client stop_listening() method figure, Listener Event Handler and Event-Handler User stop_listening() method using in Pathsend client wrappers, Writing a Client Wrapper for a Context-Free Pathsend Requester using in TCP/IP
Thread-safe code, Multithreading in Server Implementations Threading See Multithreading Threading policy, Multithreading in Server Implementations Timer, for vthread API, Using a Timer for a Thread timer.
Transaction branches, Transaction Branches and the Diamond Access Problem Transaction Management Facility (TMF), use by NonStop CORBA, Use of TMF Transaction Service features not supported, Transaction Service Features Not Supported in NonStop CORBA how implemented, Managing Transactions implementation components, Components of Transaction Service Implementation TransactionalObject interface, TransactionalObject Interface Transactions checked, Checked Transaction Behavior design considerations for, Designin
using esadmin, Using the esadmin Tool try_lock() method, for a mutex, Creating and Using a Mutex TS/MP adjusting configuration for scalability, Adjusting TS/MP Configuration Parameters process management using, Writing Your Application to Use Server Pools server classes See Server pools ts_client See Application Profiles tsmp_client See Application Profiles tsmp_server See Application profiles U unlock() method for a condition variable, Creating and Using a Condition Variable for a mutex, Creating and Usin
features of, Using the NonStop CORBA Portable Threading (vthread) API join() method, Using the yield(), join() and cancel() Methods using a thread, Creating and Using Threads vthread.
