An Acoustic Sensor History Server for a Submarine Combat Control

An Acoustic Sensor History Server

for a Submarine Combat Control System

A Thesis Presented

by

Frederick Garvin Burkley

to

The Graduate School of Engineering

In partial fulfillment of the requirements for the degree of

Master of Science

in

Computer Systems Engineering

in the field of

Engineering Software Design

Northeastern University Boston, Massachusetts

August 2002

Abstract

Current submarine computer systems suffer from scaling problems originating from

statically sized database tables. These limitations manifest themselves as constraints with

respect to information processing loads. These legacy systems are only capable of

processing fixed sized data sets; there are hard limits with respect to the number of

contacts (ships) that can be tracked from a submarine combat control system. There are

also fixed limits with respect to the amount of historical data that can be maintained on

each tracked contact.

This situation has improved somewhat over the past few years with the introduction of

the Common Object Request Broker Architecture (CORBA) in the latest combat systems.

However the implementation is still lacking. While the CORBA architecture has lifted

the restrictions concerning the number of contacts that can be tracked, there are still

limits to the amount of historical data that is archived in back end databases for

subsequent information processing. This time limited historical data set impacts the

ability of the submarine to conduct long-term contact localization activities.

This thesis describes a software architecture that places no limits on the number of

contacts that can be tracked or on the amount of historical data that can be held on each

contact. A multi-threaded server is developed whose purpose is to store data from a

submarine sonar suite for subsequent processing by combat control applications.

Concurrent programming techniques are utilized to increase server throughput while

guaranteeing data integrity.

An analysis was conducted to measure the performance of the Java programming

language and to establish relationships between system performance and system load. A

performance comparison was conducted between the Windows 2000 Professional and

SuSE 7.2 GNU/Linux Professional operating system. Results showed that server

processing time is about 20% faster under MS Windows. The fundamental reason is

memory allocation is faster under Windows than GNU/Linux.

ii

Acknowledgements

I would like to acknowledge the following individuals for their assistance and or

guidance:

Professor Ronald R. Mourant, for patience and guidance throughout this process. Shelley

L. McInnis (Naval Undersea Warfare Center), for her technical review. Patrick L.

Clayton, Walter S. Wojciechowski, Susan A. Cadieux, John G. Baylog, and Chidambar

Ganesh (Naval Undersea Warfare Center), for domain knowledge and expert opinion.

Colleen Ciciulla, for proof reading services.

I would like to offer special thanks to Mohsen D. Ghassemi (Northeastern University),

for pointing me in the direction I needed to go.

Finally Maciej Puzio ([email protected]), for timing software that allowed consistent

timing measurements across different operating systems.

iii

Table of Contents 1 Introduction................................................................................................................... 1

1.1 Overview.............................................................................................................. 1 1.2 Objectives ............................................................................................................ 2 1.3 Organization of Thesis......................................................................................... 2 1.4 Typographic Conventions.................................................................................... 3

2 Background................................................................................................................... 4 2.1 Introduction.......................................................................................................... 4 2.2 Domain Description ............................................................................................. 4

2.2.1 Sound Waves ........................................................................................... 4 2.2.2 Sound Detection....................................................................................... 5 2.2.3 Target Motion Analysis ........................................................................... 6 2.2.4 Filtered Input Data Units (Fidus)............................................................. 8

2.3 The Sensor History Server ................................................................................... 8 2.4 Technology .......................................................................................................... 9

2.4.1. Threads and Concurrent Servers.............................................................. 9 2.4.2. Concurrent Programming....................................................................... 10 2.4.3. The Common Object Request Broker Architecture............................... 11 2.4.4. The Java Programming Language ......................................................... 12

2.5 Chapter Summary .............................................................................................. 13 3 Data Flow.................................................................................................................... 14

3.1 Introduction........................................................................................................ 14 3.2 Background........................................................................................................ 14 3.3 List Wraparound ................................................................................................ 17 3.4 Fidu Waterfall .................................................................................................... 17 3.5 Fidu Capacity ..................................................................................................... 17 3.6 Fidu Lifecycle .................................................................................................... 18

3.6.1. Fidu Arrival Prior to Tracker List Wraparound..................................... 19 3.6.2. Fidu Arrival with Tracker List Wraparound and Removal from the Same

Contact List............................................................................................ 19 3.6.3. Fidu Arrival with Tracker List Wraparound and Removal from a

Different Contact List ............................................................................ 20 3.7 Chapter Summary .............................................................................................. 21

4 Design Requirements .................................................................................................. 23 4.1 Introduction........................................................................................................ 23 4.2 Data Dependency ............................................................................................... 23

4.2.1 Use of the Observer Design Pattern....................................................... 25 4.3 Shared Resources ............................................................................................... 27 4.4 Resource Ordering ............................................................................................. 29 4.5 Chapter Summary .............................................................................................. 33

5 Use Cases .................................................................................................................... 34 5.1 Introduction........................................................................................................ 34 5.2 Use Case Diagram for the Sensor History Server.............................................. 35 5.3 Add Fidu ............................................................................................................ 36 5.4 Add Collection of Fidus..................................................................................... 37

iv

5.5 Get Fidus For Tracker........................................................................................ 38 5.6 Get Fidus For Contact........................................................................................ 39 5.7 Delete Tracker.................................................................................................... 40 5.8 Delete Contact.................................................................................................... 41 5.9 Get List of Trackers ........................................................................................... 42 5.10 Get List of Contacts ........................................................................................... 43

6 Requirements .............................................................................................................. 44 6.1 Introduction........................................................................................................ 44 6.2 Overview Statement........................................................................................... 44 6.3 Customers .......................................................................................................... 44 6.4 Goals .................................................................................................................. 44 6.5 System Functions ............................................................................................... 45

6.5.1 Fidu Ingestion ........................................................................................ 45 6.5.2 Fidu Collection Ingestion....................................................................... 45 6.5.3 Tracker List Capacity............................................................................. 46 6.5.4 Tracker List Capacity Exception ........................................................... 46 6.5.5 Contact List Capacity............................................................................. 46 6.5.6 Contact List Capacity Exception ........................................................... 47 6.5.7 Fidus Per Tracker List............................................................................ 47 6.5.8 Fidu Waterfall ........................................................................................ 47 6.5.9 Tracker List Delivery............................................................................. 48 6.5.10 Nonexistent Tracker Lists ...................................................................... 48 6.5.11 Contact List Delivery............................................................................. 48 6.5.12 Nonexistent Contact Lists ...................................................................... 48 6.5.13 Tracker List Deletion ............................................................................. 49 6.5.14 Contact List Deletion ............................................................................. 49 6.5.15 List of Tracker Properties ...................................................................... 49 6.5.16 List of Contact Properties ...................................................................... 49

7 Implementation ........................................................................................................... 50 7.1 Introduction........................................................................................................ 50 7.2 High Level Architecture .................................................................................... 50 7.3 Translation and Delegation Layer...................................................................... 52 7.4 Fidu List Manager.............................................................................................. 55 7.5 System Configuration ........................................................................................ 57

8 Interaction Diagrams................................................................................................... 58 8.1 Introduction........................................................................................................ 58 8.2 Add Fidu ............................................................................................................ 58 8.3 Add Collection of Fidus..................................................................................... 65 8.4 Get Fidus For Tracker........................................................................................ 67 8.5 Get Fidus For Contact........................................................................................ 69 8.6 Delete Tracker.................................................................................................... 71 8.7 Delete Contact.................................................................................................... 75 8.8 Get List of Trackers ........................................................................................... 79 8.9 Get List of Contacts ........................................................................................... 82

9 Results......................................................................................................................... 86 9.1 Introduction........................................................................................................ 86

v

9.2 Background........................................................................................................ 86 9.3 Lab Setup ........................................................................................................... 88 9.4 Get Fidus for Tracker......................................................................................... 89

9.4.1 Test Methodology .................................................................................. 89 9.4.2 Queuing Time ........................................................................................ 91 9.4.3 Wait Time .............................................................................................. 94 9.4.4 Service Time .......................................................................................... 96 9.4.5 Summary ................................................................................................ 98

9.5 Add Collection of Fidus..................................................................................... 99 9.5.1 Test Methodology .................................................................................. 99 9.5.2 Queuing Time ...................................................................................... 100

9.6 Chapter Summary ............................................................................................ 102 10 Discussion................................................................................................................. 104

10.1 Introduction...................................................................................................... 104 10.2 Memory Allocation.......................................................................................... 104 10.3 Towards a Component Based Submarine Combat System.............................. 107

11 Conclusions and Recommendations for Future Work .............................................. 109 11.1 Viability of Java in a Submarine Combat System ........................................... 109 11.2 Generalizing Measurement Types ................................................................... 110 11.3 Extension Via Type Specific Producer and Consumer Servants ..................... 112 11.4 Event Mechanism............................................................................................. 117

References....................................................................................................................... 118 Appendix A: Glossary of Terms ..................................................................................... 120 Appendix B: Uniformity of Time Step ........................................................................... 122 Appendix C: Investigation of System.currentTimeMillis() ............................................ 124

vi

List of Figures Figure 2-1 A spherical array at the fore end of a submarine. ............................................. 5 Figure 2-2 A submarine conducting Target Motion Analysis. ........................................... 7 Figure 3-1 A list of Fidus designated by tracker source. .................................................. 15 Figure 3-2 A list of Fidus designated by contact source................................................... 15 Figure 3-3 A list structure for Fidu storage. ..................................................................... 16 Figure 3-4 A pool of Fidus accessible via tracker list and/or contact list......................... 16 Figure 3-5 A tracker with history on multiple contacts. ................................................... 17 Figure 3-6 A tracker list prior to wraparound................................................................... 19 Figure 3-7 A tracker list at wraparound............................................................................ 20 Figure 3-8 A tracker list in wraparound with removal from the same contact list. .......... 20 Figure 3-9 A tracker list at wraparound with history on multiple contacts. ..................... 21 Figure 3-10 A tracker list in wraparound with removal from a different contact list....... 21 Figure 4-1 Subjects and observers. ................................................................................... 25 Figure 4-2 Removing a waterfalling Fidu (subject) from a tracker list (observer)........... 26 Figure 4-3 Fidu addition to a tracker list in wraparound. ................................................. 27 Figure 4-4 Multiple tracker lists with history on multiple contacts.................................. 31 Figure 5-1 Use case diagram for the Sensor History Server............................................. 35 Figure 7-1 Block structure of the Sensor History Server.................................................. 50 Figure 7-2 Class diagram for the CORBA translation and delegation layer. ................... 54 Figure 7-3 Class diagram for the Fidu List Manager........................................................ 56 Figure 8-1 Sequence diagram for the add Fidu use case. ................................................. 61 Figure 8-2 Sequence diagram for the add collection of Fidus use case............................ 66 Figure 8-3 Sequence diagram for the get Fidus for tracker use case. ............................... 68 Figure 8-4 Sequence diagram for the get Fidus for contact use case................................ 70 Figure 8-5 Sequence diagram for the delete tracker use case. .......................................... 73 Figure 8-6 Sequence diagram for the delete contact use case. ......................................... 77 Figure 8-7 Sequence diagram for the get list of trackers use case.................................... 80 Figure 8-8 Sequence diagram for the get list of contacts use case. .................................. 84 Figure 9-1 A simple queuing model. ................................................................................ 87 Figure 9-2 Fidu List Manager and application service infrastructure boundary. ............. 88 Figure 9-3 Hardware suite for performance benchmarking.............................................. 89 Figure 9-4 Queuing model view of the get Fidus for tracker use case. ............................ 91 Figure 9-5 Queuing time for the get Fidus for tracker use case........................................ 92 Figure 9-6 Wait time for the get Fidus for tracker use case.............................................. 95 Figure 9-7 Service time for the get Fidus for tracker use case. ........................................ 97 Figure 9-8 Queuing time for the add collection of Fidus use case. ................................ 101 Figure 10-1 Fidu instantiation time for Win2k vs. SuSE 7.2. ........................................ 106 Figure 11-1 Block structure of a Sensor History Server with type specific servants. .... 114 Figure 11-2 Class diagram of a Sensor History Server with type specific servants. ...... 116

vii

List of Tables Table 3-1 Relationship Between Fidu Arrivals and List Wraparound ............................. 18 Table 5-1 Use Cases for the Sensor History Server.......................................................... 34 Table 6-1 System Function Categories ............................................................................. 45 Table 9-1 General Queuing Parameters............................................................................ 87 Table 9-2 Successive Phases for One Get Fidus for Tracker Benchmark Run ................ 90 Table 9-3 Queuing Time for the Get Fidus For Tracker Use Case for Win2k ................. 93 Table 9-4 Queuing Time for the Get Fidus For Tracker Use Case for SuSE 7.2 ............. 93 Table 9-5 Wait Time for the Get Fidus For Tracker Use Case for Win2k ....................... 96 Table 9-6 Wait Time for the Get Fidus For Tracker Use Case for SuSE 7.2 ................... 96 Table 9-7 Service Time for the Get Fidus for Tracker Use Case for Win2k................... 98 Table 9-8 Service Time for the Get Fidus for Tracker Use Case for SuSE 7.2................ 98 Table 9-9 Get Fidus For Tracker Queuing Parameter Times ........................................... 99 Table 9-10 Queuing Time for the Add Collection of Fidus Use Case for Win2k .......... 102 Table 9-11 Queuing Time for the Add Collection of Fidus Use Case for SuSE 7.2 ...... 102 Table 10-1 Fidu Instantiation Times for Win2k vs. Linux ............................................. 104

1

1 Introduction

1.1 Overview

Submarine combat systems are evolving from specialized military computers towards

Commercial Off The Shelf (COTS) based hardware. These specialized computers are no

longer feasible due to the diminishing supply of dollars for military systems procurement

[Pow02].

The architecture of the software for these computers was influenced by hardware

constraints that are no longer relevant. Backend database table sizes were fixed at

compile time. These fixed table sizes limit the number of contacts that can be tracked

and the amount of data available for processing per contact.

As combat systems evolve towards COTS based hardware much of the underlying

software architecture remains unchanged. System limits are increased, yet they are still

static in nature. That is, once the system is developed, there are still upper limits on the

number of contacts that can be tracked and the amount of data available for processing

per contact.

The reason for this is financial. It is less expensive to port existing software and increase

limits in table definition files than to redesign the fundamental architecture of the system.

This paper describes the architecture of a data server whose software policies are set via

run-time configuration files rather than hardwired at compile time. This effectively

moves system limits from the software realm to the hardware realm. That is, it is now the

amount of computer RAM or hard disk space that imposes information processing limits.

This is both timely and relevant given the proliferation of highly capable / low cost

hardware.

2

1.2 Objectives

The objectives of this thesis are as follows:

• To design and implement an acoustic Sensor History Server that places no

architectural limits on the following items:

o The number of contacts that are stored in the server.

o The number of trackers1 that are stored in the server.

o The amount of historical data that is stored per tracker.

• Given an implementation in the Java programming language, evaluate the

performance of the server on the Windows 2000 Professional and SuSE 7.2

GNU/Linux Professional operating systems.

Of particular interest is how performance scales under increasing client load.

1.3 Organization of Thesis

Chapter 2, Background – establishes domain specific background, the role of the server

within this context, and surveys relevant software technology as it applies to the

implementation of the server.

Chapter 3, Data Flow – traces the flow of data through the server. The characteristics of

this data flow establish the foundation of the architecture of the server.

Chapter 4, Design Requirements – describes the forces behind the design of the server,

thereby illuminating and justifying the chosen architecture.

Chapter 5, Use Cases – describes the use cases of the server.

Chapter 6, Requirements – establishes the functional requirements of the server.

1 The notion of a tracker is discussed in Chapter 2.

3

Chapter 7, Implementation – describes the high level implementation of the server. It

illustrates the partitioning of core functional software components across architectural

boundaries.

Chapter 8, Interaction Diagrams – describes the interaction diagrams of the server.

Chapter 9, Results – presents the results of performance benchmarking of the most

important use cases for Windows 2000 and SuSE 7.2 GNU/Linux.

Chapter 10, Discussion – gives insight into fundamental reasons for performance

differences for this type of application.

Chapter 11, Recommendations for Future Work– establishes functional areas to

extend the server beyond the prototype stage.

1.4 Typographic Conventions

The following typographic conventions are used in this document:

Courier New Font – Is used to designate a software item, such as a Java class or

package name.

Italics – Are used to place special emphasis on a term, often when it is used for the first

time.

4

2 Background

2.1 Introduction

This Chapter establishes the technical domain in which the Sensor History Server is

relevant. The notion of underwater sound propagation is described, followed by a

description of Target Motion Analysis (TMA). The system solution of the TMA problem

introduces a data storage requirement that the server solves. The term system solution is

used to reflect the design of a computer software system to be used in the process of

Target Motion Analysis.

2.2 Domain Description

Three of the primary operational goals of a submarine are:

• Piloting and navigation.

• Surveillance and intelligence gathering.

• Weapons deployment.

Fundamental to each of these goals is the process of contact localization, also known as

Target Motion Analysis (TMA).

2.2.1 Sound Waves Any surface or subsurface vessel that moves through the ocean makes a certain amount of

noise. Sound originates from the propellers, vibrating machinery, etc., of these platforms

as they transit.

An object that vibrates back and forth in the water creates a pressure differential around

it. As the object moves forward, the particles of water directly in front of it are pressed

closer together. Each particle then passes this pressure along to the particle ahead of it.

5

This state of compression moves away from the object in all directions. When the object

moves backward, this pressure is removed and the particles are thinned out. This state of

rarefaction follows each compressive state [NavPers 16167].

The propagation of this pressure differential through the water describes a sound wave,

that is, a propagating disturbance in a fluid medium, such as air or water.

2.2.2 Sound Detection

A hydrophone is a device that transforms sound waves into electrical signals. A series of

hydrophones can be arranged in such a way as to determine the arrival angle of the

sound. The arrival angle, or bearing, of the sound determines the relative direction to the

contact that originated the disturbance.

Figure 2-1 shows a Spherical Array mounted at the fore end of a submarine. A Spherical

Array is an array of hydrophones physically mounted in a spherical pattern. Again, this

arrangement of hydrophones enables the determination of the bearing to the contact that

originated the sound wave.

SphericalArraySail Periscope

Figure 2-1 A spherical array at the fore end of a submarine.

6

2.2.3 Target Motion Analysis

TMA is a technique used to estimate the range, course, and speed of a contact (target)

from a set of measured bearings and frequencies. Contact range and bearing define the

position of the contact relative to that of the submarine. Contact course and speed define

the velocity of the contact as it transits through the ocean.

Figure 2-2 shows a submarine (ownship) conducting Target Motion Analysis. The line

extending from the aft end of each submarine represents the position history of each

submarine over some period of time. Figure 2-2 is a geographic plot of position history

(latitude, longitude) versus time. In the case of ownship, the position history is a known

item; ownship knows where it has been, and maintains a history of these positions. In the

case of the contact, the position history of the contact is an estimate. The point of TMA

is to accurately estimate the position and trajectory of a contact. If the range, bearing,

course, and speed of a contact are known, the position history of the contact is known.

More importantly, the future position of the contact can be predicted.2

A tracker is an algorithm that processes the electrical signals output from the hydrophone

array and determines the bearing to the contact. Every few seconds, the tracker will

produce a bearing which is valid at that particular instant in time. For example, the

bearing α1, the first bearing collected, might be 1800 seconds (30 minutes) old. The

second bearing, α2, might be 1780 seconds old, up until αn, which might be 20 seconds

old.

A shorthand expression for this process is to “assign a tracker to a contact”. Assigning a

tracker to a contact results in an incoming stream of measurements, each of which is the

bearing to the contact at a particular instant in time.

2 Some simplifying assumptions are made in this discussion.

7

Contact

Ownship

α1 α2 α3αn-1 αn

Figure 2-2 A submarine conducting Target Motion Analysis.

This measurement set, or time-history set of bearings is collected and fed into another

algorithm, the output of which is an estimate of the range, course and speed of the

contact. The bearing to the contact is already known, since it is one of the measurements.

When a submarine conducts TMA, it is said to track the contact. It is possible to track

multiple contacts at the same time. In this case, a separate tracker would be assigned to

each contact being tracked.

Trackers are given alphanumeric designators such as PBB1 (Passive Broadband tracker

1), PBB2 (Passive Broadband tracker 2), etc. The phrase “PBB1 is assigned to contact 1”

8

means Passive Broadband tracker 1 is generating a time-history set of bearings on contact

number 1.

2.2.4 Filtered Input Data Units (Fidus)

A tracker will often produce bearings at a rate of 1 per second. These 1-second bearings

are usually averaged into 20-second data units. This averaging, or filtering, occurs

before the TMA algorithm processes the measurement set. These filtered data units are

referred to as Filtered Input Data Units, or Fidus for short.

From a software development point of view, a Fidu is an object with several fields, a few

of which are:

• Bearing – The bearing to the contact.

• Tracker Designator – The tracker that produced the Fidu. If the Fidu originated from

tracker PBB1, then the Tracker Designator is PBB1.

• Contact Designator – The contact that the tracker is assigned to. If the tracker is

assigned to contact 2, then the Contact Designator is 2.

2.3 The Sensor History Server

As Fidus stream from a tracker (or trackers) they are held in a data store for subsequent

retrieval for TMA processing. This is the purpose of the Sensor History Server.

Within the server, Fidus are organized as lists of data. All Fidus with the same Tracker

Designator are stored on the same list; the PBB1 tracker list holds all Fidus that have a

Tracker Designator of PBB1. All Fidus with the same Contact Designator are stored on

the same list; the “contact 1” contact list holds all Fidus that have a Contact Designator of

1.

9

2.4 Technology

2.4.1. Threads and Concurrent Servers

The most basic type of server is an iterative server. An iterative server can only process

one client request at a time. If two clients make overlapping requests, the second client

will block until the server is finished processing the first client’s request. This technique

is inadequate for all but the simplest servers.

When client requests can take longer to service, multiple clients should be handled at the

same time. The simplest way to write a concurrent server under Unix is to fork a child

process to handle each client [Ste98]. The fork system call is the way to create a new

process under Unix. This new process is referred to as a child process, and the server is

knows as the parent process. The child process then services the client, and the parent

process waits for another connection.

Many operating systems support the notion of a single execution path, or thread, through

the process. Given a model such as this, the only way to write a concurrent server is to

fork a new child process for each incoming connection. The notion, however, of creating

a new process for each client connection is dated. Creating a new process is expensive;

context switching and kernel intervention is required for inter-process communication /

sharing of data.

Modern operating systems overcome the limitations of single-threaded processes by

providing multi-threaded concurrency mechanisms that support the creation of multiple

processes, each of which may contain multiple concurrent threads. Each thread serves as

a unit of execution that runs within a process address space that is shared by other threads

[SSR+00]. Windows 2000 and SuSE 7.2 GNU/Linux both take this approach.

10

In the case of a concurrent server, a new thread3, rather than a new process can service

each incoming client request.

The key benefits of threads are due to performance implications [Sta01]:

1. It takes far less time to create a new thread in an existing process than to create a

brand-new process.

2. It takes less time to terminate a thread than a process.

3. It takes less time to switch between two threads within the same process.

4. Threads enhance efficiency in communication between different executing programs.

In most operating systems, communication between independent processes requires

the intervention of the kernel to provide protection and the mechanisms needed for

communication. However, because threads within the same process share memory

and files, they can communicate with each other without invoking the kernel.

2.4.2. Concurrent Programming

Concurrency is a term that refers to a family of policies and mechanisms that enable one

or more threads or processes to execute their service processing tasks simultaneously

[Ben90]. Many networked applications, particularly servers, must handle requests from

multiple clients concurrently [SSR+00].

Separate threads in multi-threaded programs often communicate via access to shared

resources. A shared resource is any resource that is accessed by more than one thread of

execution. However, multi-threaded programs that access shared resources have certain

constraints placed upon them. In particular, critical sections of code should only be

accesses by one thread at a time.

Synchronization policies must be used to ensure that two threads do not access critical

sections of code simultaneously; this guarantees correctness of program state. There are

two basic kinds of synchronization: mutual exclusion and condition synchronization.

3 Other programming techniques, such as a thread pool, can also be used.

11

Mutual exclusion is a mechanism of ensuring that critical sections of statements do not

execute at the same time. Condition synchronization is a mechanism of delaying a

process until a given condition is true [And00].

Sections 4.3 and 4.4 describe how these policies and mechanisms apply to the design of

the server.

2.4.3. The Common Object Request Broker Architecture

CORBA4 provides platform-independent programming interfaces and modules for

portable distributed object oriented computing applications [HV99]. CORBA is one of

several popular distributed object oriented computing paradigms.

Use of a distributed object oriented paradigm simplifies network communication and

provides an abstraction consistent with the object oriented programming model. In the

most general sense, any object that has one of its methods invoked is providing a service

to the caller. The caller can be thought of as a client to the object whose method is being

invoked. The object whose method is being invoked (target object) is providing a service

to the caller, that is, acting as a server.

The use of CORBA (as well as other distributed object oriented computing paradigms)

extends this idea such that callers and target objects can be located on the same or on

different computers. The entire request invocation mechanism is completely transparent

to the client, to whom a request on a remote object looks like an ordinary method

invocation. This is known as location transparency. The client does not know or care

whether the target object is local to its address space, is implemented in a different

process on the same machine, or is implemented in a process on a different machine

[HV99].

The CORBA Interface Definition Language (IDL) is an interface specification language

whose purpose is to define services that objects will expose to distributed clients. An 4 See www.omg.org for a discussion of the Object Management Group and CORBA.

12

object specifies its interface via IDL, and then the IDL interface specification is compiled

into source code definitions for the target language, in this case Java.

2.4.4. The Java Programming Language

The Java programming language is well suited to a distributed object oriented multi-

threaded server for the following reasons:

• Java is a multi-platform language. Java can run on any computer that supports a Java

Virtual Machine (JVM). This reduces development cost, as developers do not have to

be concerned with subtle Application Programming Interface (API) differences across

distinct operating systems. This is especially evident when making operating system

and networking API calls. Operating system APIs are especially non-portable, even

across releases of the same platform [SSR+00].

• Core threading functionality is built into the language (java.lang). This facilitates

the process of writing operating system independent multi-threaded applications. The

heterogeneity of contemporary hardware and software platforms complicates the

development of concurrent applications and tools that must run on multiple operating

systems [SSR+00].

For example, shutting down multi-threaded applications gracefully and predictably is

hard. The problem stems from inconsistent thread cancellation semantics across

operating systems, such as Posix/Unix and Win32. Additionally, support for

advanced threading features such as thread specific storage and daemon5 threads

varies widely across operating systems [Lew95].

5 Under Unix, a daemon process is a process that does not have a controlling terminal; it is said to run in the background [Ste93]. Under Windows, the same principle is referred to as a Service. An example of a Unix daemon or a Windows Service is a print-queue manager. The concept of a daemon process extends to a thread running in a JVM. There are two types of threads in a JVM: daemon threads and user threads. The programmer explicitly creates user threads. Daemon threads are threads that will not prevent the JVM from exiting [OW99]. An example of a daemon thread is the Garbage Collector. It is started by the JVM on the user’s behalf. The JVM will exit after all of the user-defined threads have exited.

13

Software development for a JVM runtime, which encapsulates low-level operating

system specific semantics, relieves the developer of the complexities and intricacies

of these details.

• Core networking functionality is built into the language (java.net).

• An Object Request Broker (ORB) is built into the language (org.omg.CORBA), as

well as numerous third party ORBs.

2.5 Chapter Summary

The Sensor History Server is a concurrent multi-threaded server, which serves time-

history lists of Fidus; its architecture supports simultaneous requests for Fidu lists from

multiple clients. Within the server, tracker lists and contact lists are shared resources,

accessible by any thread that is handling a client request.

Concurrent programming techniques are used to ensure the integrity of these shared

resources during client access. Mutual exclusion is used to guarantee that a reader and

writer do not access the same list simultaneously. Mutual exclusion is achieved via

condition synchronization. A list that is being written will block reader access until the

writer is finished. Condition synchronization is also used to prevent two writers from

accessing the same list simultaneously.

A CORBA layer wraps the internal logic of the server. All remote requests occur via

CORBA IDL.

The architecture of the server is discussed in greater detail in Chapter 7.

14

3 Data Flow

3.1 Introduction

This Chapter traces the flow of a Fidu through the Sensor History Server. The

characteristics of this data flow lay the foundation for the architecture of the server.

The following cases are considered:

• The arrival of a Fidu for a tracker list / contact list prior to tracker list wraparound

(§3.6.1).

• The arrival of a Fidu for a tracker list / contact list accompanied by waterfall (§3.4) of

the oldest Fidu from the tracker list.

This case is further divided into the following two cases:

o Removal of the oldest Fidu from the same contact list to which the new Fidu is

being added (§3.6.2).

o Removal of the oldest Fidu from a different contact list than the list to which the

new Fidu is being added (§3.6.3).

3.2 Background

The server contains a series of tracker lists and contact lists. A tracker list or a contact

list is simply a ring buffer with a certain finite capacity. Fidus are added to the buffer

until the buffer is full. After this point, the arrival of a new Fidu necessitates the removal

of the oldest Fidu from the list.

Fidus are designated by Tracker Designator and Contact Designator. The receiving

process (server) forwards the Fidu to the appropriate tracker list / contact list based on

these designators.

15

Since each Fidu has two designators, the server holds each Fidu on two different lists: a

tracker list and a contact list.

This allows the server to handle two fundamental types of requests.

• Return all Fidus for a particular tracker, that is, return all Fidus for tracker PBB1.

• Return all Fidus for a particular contact, that is, return all Fidus for contact 1.

If the Fidus only lived on a list organized by tracker, the list might appear as:

N Fidus (bearing estimates) per tracker

Trac

kers PBB1

PBB2

Figure 3-1 A list of Fidus designated by tracker source.

Similarly, if Fidus only lived on lists organized by contact, the list might appear as:

Con

tact

s

N Fidus (bearing estimates) per contact

Contact 1

Contact 2

Figure 3-2 A list of Fidus designated by contact source.

What is required, however, is a list structure that looks like this:

16

Con

tact

1P

BB

2

TimeNewest Oldest

Figure 3-3 A list structure for Fidu storage.

Each box represents a Fidu. Each Fidu is always on two lists. The newest Fidu on each

list is towards the left in the diagram. The oldest Fidu is towards the right.

A contact list can have multiple tracker lists associated with it, that is, a contact list can

reference Fidus that are referenced from multiple tracker lists. Figure 3-4 shows a

contact list (Contact 1) that references Fidus that are referenced from two tracker lists

(PBB1 and PBB2).

Con

tact

1P

BB

1P

BB

2

Figure 3-4 A pool of Fidus accessible via tracker list and/or contact list.

A tracker list can also reference Fidus from multiple contact lists. In Figure 3-5, there is

one tracker list that references Fidus that are referenced by two contact lists.

17

Con

tact

1P

BB

2C

onta

ct 2

Figure 3-5 A tracker with history on multiple contacts.

3.3 List Wraparound

Once the ring buffer is full, the list is said to be in wraparound. The term wraparound

makes sense when applied to an array with first and last pointers denoting the most recent

and oldest elements in the array, respectively. When the array fills up, the pointers will

“wraparound”. Although this is not necessarily the actual implementation of any of the

classes in Sun’s Collection framework, the term is used for historical purposes.

3.4 Fidu Waterfall

The term waterfall refers to the process of removing a Fidu from the end of a tracker list.

Once the list is full, the arrival of a new Fidu forces the removal of the oldest Fidu on the

list. The Fidu is said to waterfall off the end of the list.

3.5 Fidu Capacity

Fidus are received over a period of time, nominally one Fidu per tracker every 20

seconds.

18

The notion of Fidu capacity only applies to tracker lists. In some implementations, a

tracker list is limited to 340 Fidus. This is due to legacy limitations with database size

(there is no reason to have this limitation with a modern architecture). With a default

Fidu capacity of 340, Fidus will begin to waterfall off of a given tracker list at the arrival

of the 341st Fidu.

Consequently, if a contact has two trackers assigned to it, the contact list will hold 680

Fidus, 340 from each tracker. The number of Fidus on a contact list is determined by two

factors:

• The number of trackers on the contact.

• The Fidu capacity of each tracker list.

Fidus waterfall off tracker lists, not contact lists. It is the tracker list that determines

when it is time to waterfall a Fidu. When a Fidu waterfalls off the tracker list, it must

(somehow) be removed from its contact list.

3.6 Fidu Lifecycle

Consider a PBB2 tracker list with some capacity M, where M is the maximum number of

Fidus that can be on the list. For purposes of illustration, let M = 340. At any point in

time, the number of Fidus on the list is N, where 1 <= N <= M. The total number of Fidu

arrivals for a given tracker list is λ, where λ >= 1.

Table 3-1 Relationship Between Fidu Arrivals and List Wraparound

Arrivals Number of Fidus on list Wraparound1 <= λ <= M 1 <= N <= M No

λ > M N = M Yes

19

Table 3-1 shows the relationship between the number of Fidu arrivals for a tracker list,

the number of Fidus on the tracker list and whether the list is in wraparound.

3.6.1. Fidu Arrival Prior to Tracker List Wraparound

Fidu arrival prior to tracker list wraparound implies λ <= M.

Consider the arrival of a Fidu with a Tracker Designator of PBB2 and a Contact

Designator of 1. This means the Fidu will go on the PBB2 tracker list and the “Contact

1” contact list. When the Fidu arrives, it is the newest Fidu on both lists.

Let this Fidu be the 155th Fidu to arrive for the PBB2 tracker list. Since the number of

Fidu arrivals on the tracker list λ is <= M, Fidu waterfall does not occur off the end of the

PBB2 list.

Figure 3-6 shows the state of the PBB2 tracker / Contact 1 list at this instant in time.

17

155 6 4

35

2

Con

tact

1P

BB

2

TimeNewest Oldest

Figure 3-6 A tracker list prior to wraparound.

3.6.2. Fidu Arrival with Tracker List Wraparound and Removal from the Same Contact

List

Figure 3-7 shows the PBB2 tracker / “Contact 1” contact list after 340 Fidu arrivals.

Since λ = M = 340, the arrival of the 341st Fidu will cause the 1st Fidu to waterfall off the

PBB2 tracker list and be removed from the “Contact 1” contact list.

20

17

340 6 4

35

2

Con

tact

1P

BB

2

TimeNewest Oldest

Figure 3-7 A tracker list at wraparound.

Figure 3-8 shows the lists after the arrival of the 341st Fidu. The 2nd Fidu to arrive is now

the oldest Fidu in both lists. The arrival of the 342nd Fidu will cause this Fidu to waterfall

of the tracker list and be removed from the “Contact 1” contact list.

28

341 7 5

46

3

Con

tact

1P

BB

2

TimeNewest Oldest

Figure 3-8 A tracker list in wraparound with removal from the same contact list.

3.6.3. Fidu Arrival with Tracker List Wraparound and Removal from a Different

Contact List

Figure 3-9 shows the PBB2 tracker list and two contact lists, Contact 1 and Contact 2.

Fidus one through five have a Tracker Designator of PBB2 and a Contact Designator of

“Contact 2”. Fidus six and up have a Tracker Designator of PBB2 and a Contact

Designator of “Contact 1”.

21

17

340 6 4

35

2

Con

tact

1P

BB

2C

onta

ct 2

TimeNewest Oldest

Figure 3-9 A tracker list at wraparound with history on multiple contacts.

The arrival of the 341st Fidu causes Fidu number 1 to waterfall from the PBB2 tracker list

and to be removed from the “Contact 2” contact list.

28

341 7 5

46

3

Con

tact

1P

BB

2C

onta

ct 2

TimeNewest Oldest

Figure 3-10 A tracker list in wraparound with removal from a different contact list.

3.7 Chapter Summary

Every Fidu is stored on two different lists, a tracker list and a contact list. This allows a

consumer to request all Fidus for a particular tracker or all Fidus for a particular contact.

Since contact lists can reference Fidus that are referenced from multiple tracker lists, a

22

request for a contact list may result in the delivery of Fidus from multiple tracker lists.

This is by design and facilitates TMA processing.

Fidus waterfall off of tracker lists. When this happens, the waterfalling Fidu must be

removed from its associated contact list. This implies some communication mechanism

is needed between Fidus, tracker lists, and contact lists. This is the topic of §4.2.

23

4 Design Requirements

4.1 Introduction

There are three fundamental forces behind the design of the server.

• There is a data dependency between trackers and contacts. That is, a dependency

exists between tracker lists and contact lists. As described in Chapter 3, every Fidu

on a tracker list is also on a contact list. Conversely, every Fidu on a contact list is

also on a tracker list.

• Tracker lists and contact lists are shared resources. Given this, synchronization

mechanisms must be applied to prevent simultaneous list access by producers and

consumers (writers and readers). At the same time, the choice of synchronization

technique should maximize program liveness.

• Resource ordering must be considered and enforced to preclude the possibility of

deadlock.

This Chapter describes these forces, thereby illuminating and justifying the architecture

of the server.

4.2 Data Dependency

The fact that every Fidu resides on two lists has the following implication:

• When a Fidu waterfalls off a tracker list, it must be removed from its corresponding

contact list.

Therefore contact lists are dependant upon Fidu state. When the Fidu state changes (the

Fidu waterfalls of the tracker list), the contact list must change as well.

24

The tracker list “knows” when it is time to waterfall a Fidu, based on its user defined list

capacity.

Tracker lists are also dependent on Fidu state. The server can receive a request to delete

a contact. The server will iterate through the requested contact list and delete every Fidu.

When this happens, each Fidu must be removed from its tracker list.

The dependency between tracker / contact lists and Fidu state implies coupling between

tracker lists and contact lists. An event occurring on a tracker list (a Fidu waterfall)

implies a change in a contact list. An event occurring on a contact list (a delete contact

request) implies a change in a tracker list.

Loose coupling increases the probability that a class can be reused by itself and that a

system can be learned, ported, modified, and extended more easily [GoF95].

The coupling between tracker lists and contact lists should happen at the Fidu level, not

the tracker list or the contact list level. This simplifies tracker lists and contact lists.

Tracker lists do not directly know about contact lists; contact lists do not directly know

about tracker lists. Fidus can be reused in other implementations.

The Observer design pattern decouples senders (subjects) from receivers (observers) by

defining an interface for signaling changes in subjects [GoF95]. The Fidu is the message

sender (subject). The tracker list and the contact list are message receivers (observers).

When a Fidu is deleted from a tracker list, the Fidu will send a message to its contact list.

When the contact list receives the message, it will delete the Fidu. Conversely, when a

Fidu is deleted from a contact list the Fidu will send a message to its tracker list. When

the tracker list receives the message, it will delete the Fidu.

Section 4.2.1 illustrates the use of the Observer design pattern.

25

4.2.1 Use of the Observer Design Pattern

The following example steps through the sequence of events that occur upon the addition

of a Fidu (subject) to a waterfalling tracker list (observer).

Figure 4-1 shows a tracker list and contact list after the addition of a few Fidus. Each

Fidu plays the role of the subject in the Observer design pattern (all Fidus are not labeled

as such). Each list plays the role of the observer.

17

214 6 4

35

2

Con

tact

1(O

bser

ver)

PB

B2

(Obs

erve

r)

TimeNewest Oldest

Sub

ject

Sub

ject

Sub

ject

Sub

ject

Sub

ject

Figure 4-1 Subjects and observers.

As new Fidus are added to the lists, each list must register itself as an observer of each

Fidu. This registration establishes the communication mechanism between subject and

observer.

The next diagram shows a tracker list that has reached its user defined capacity. As

stated in §3.6.2, the addition of the next Fidu will cause the 1st Fidu to waterfall off the

tracker list and be removed from the contact list.

26

17

340

339

6 4

35

2

Con

tact

1(O

bser

ver)

PB

B2

(Obs

erve

r)

TimeNewest Oldest

Sub

ject

Sub

ject

Sub

ject

Sub

ject

Sub

ject

The following sequence of events will occur upon arrival of the 341st Fidu:

1) The capacity of the PBB2 tracker list will be checked. Since the list is full, the

tracker list will be deregistered as an observer of the 1st Fidu.

2) The 1st Fidu will be removed from the PBB2 tracker list.

Figure 4-2 shows that state of the tracker list at this point. The 1st Fidu is no longer on

the PBB2 list.

17

340

339

6 4

35

2

Con

tact

1(O

bser

ver)

PB

B2

(Obs

erve

r)

TimeNewest Oldest

Sub

ject

Sub

ject

Sub

ject

Sub

ject

Sub

ject

Figure 4-2 Removing a waterfalling Fidu (subject) from a tracker list (observer).

3) A message will be sent to the 1st Fidu to delete itself. This Fidu will in turn send a

message to any of its observers that it is changing state (being deleted).

4) Since the contact list is still an observer of the 1st Fidu, it will be notified that this

Fidu is being deleted.

27

5) The contact list will be deregistered as an observer of the 1st Fidu. This Fidu will then

be removed from the contact list.

6) The tracker list will be registered as an observer of the 341st Fidu. This Fidu will be

added to the tracker list.

7) The contact list will be registered as an observer of the 341st Fidu. This Fidu will be

added to the contact list.

Figure 4-3 shows each list after the removal of the 1st Fidu and the addition of the 341st

Fidu.

399

28

341

340

7 5

46

3

Con

tact

1(O

bser

ver)

PB

B2

(Obs

erve

r)

TimeNewest Oldest

Sub

ject

Sub

ject

Sub

ject

Sub

ject

Sub

ject

Figure 4-3 Fidu addition to a tracker list in wraparound.

The sequence of events that occurs when Fidu removal is initiated via activity on a

contact list is similar.

4.3 Shared Resources

Tracker lists and contact lists are shared resources. At any time, multiple concurrent

threads may need to read from or write to a tracker list or a contact list.

Data corruption in tracker lists or contact lists can occur under two circumstances:

• Multiple concurrently executing threads try to read from and write to the same list.

• Multiple concurrently executing threads try to write to the same list.

28

To prevent this problem, the following conditions should be enforced:

• A reader and a writer should not be allowed into the same list simultaneously.

• Multiple writers should not be allowed into the same list simultaneously.

Code that should not execute concurrently in objects or functions can be synchronized

within a critical section [SSR+00]. A critical section is a sequence of instructions that

obeys the following invariant: while one thread or process is executing in the critical

section, no other process can execute in the same critical section [Tan95].

Tracker lists and contact lists are critical sections of code and their access must be

controlled with synchronization techniques.

A mutex, which stands for mutual exclusion, is the most basic form of synchronization.

A mutex lock is used to protect a critical region, to make certain that only one thread at a

time executes the code within the region [Ste99]. Note that the terms critical section and

critical region are interchangeable. A survey of relevant literature will reveal both uses.

Use of a mutex lock would meet the two conditions stated above; it would keep

simultaneous readers and writers out of the same list and it would keep simultaneous

writers out of the same list.

However, there is no reason not to allow multiple readers into the same list. Since

readers do not modify the list, there is no harm in allowing multiple readers access.

Doing so allows for the possibility of increased concurrency by allowing multiple threads

to process the same list simultaneously. Stated another way, allowing multiple readers

into the same list will allow the server to serve the same tracker list or contact list to

multiple consumers concurrently.

This type of problem (multiple readers and one writer) is, of course, the classic readers

and writers problem. It is also known as shared-exclusive locking, because obtaining a

29

read-write lock for reading is called a shared lock, and obtaining a read-write lock for

writing is called an exclusive lock [Ste99].

Read-write locks are generally preferable to plain locks when [Lea99]:

• The methods in a class can be cleanly separated into those that only access (read)

internally held data and those that modify (write).

• Reading is not permitted while writing methods are in progress.

• Target applications generally have more readers than writers.

• The methods are relatively time consuming, so it pays to introduce a bit more

overhead associated with read-write locks compared to simpler techniques in order to

allow concurrency among reader threads.

Read-write locks are often used in classes that provide access to large collections of data.

As is evident, read-write locks will be the basic synchronization mechanism to protect the

integrity of critical sections of code (tracker lists and contact lists).

4.4 Resource Ordering

Given the background established in Chapter 3 and §4.2, the process of adding a Fidu to

the server will always result in the acquisition of write locks for at least two resources

and often, a third.

A tracker list can be considered in a transient state when it is not in wraparound. That is,

before it has reached its user defined capacity. A tracker list is in steady state once it has

reached its capacity. As described in Chapter 3, when a tracker list has reached its

capacity the arrival of a (new) Fidu forces the waterfall of the oldest Fidu.

When a tracker list is in a transient state, the addition of a Fidu results in the acquisition

two write locks, a write lock for the designated tracker list and a write lock for the

designated contact list.

30

When a tracker list is in steady state, the addition of a Fidu results in the acquisition of a

third write lock; the write lock for the contact list the oldest Fidu on the tracker list is

being removed from.

Any time multiple threads attempt to acquire multiple resources a deadlock condition can

occur. Deadlock is a concurrency hazard that occurs when multiple threads attempt to

acquire multiple locks and become blocked indefinitely in a circular wait state [SSR+00].

Resource ordering is a simple technique to preclude deadlock when a thread needs to

acquire locks on multiple resources to perform its task. Deadlock cannot occur if the

resources are always acquired in a predictable order.

The following example illustrates the need to establish a predictable pattern around the

acquisition of resources.

Consider a situation with two tracker lists and two contact lists as in Figure 4-4. Each

tracker list is in wraparound and has history on multiple contacts. The specific number of

Fidus on each tracker list is arbitrary, as long as each tracker list is in wraparound.

Thread 1 is adding the 341st Fidu to the PBB2 tracker list / Contact 1 list. Thread 2 is

adding the 350th Fidu to the PBB1 tracker list / Contact 2 list.

31

17

340

339

6 4

35

2

Con

tact

1P

BB

2C

onta

ct 2

TimeNewest Oldest

PB

B1

348

1016349

15 13

1214

11

Thread 1

Thread 2

Figure 4-4 Multiple tracker lists with history on multiple contacts.

It is possible that the simultaneous arrival of Fidus for each set of lists could lead to the

following sequence of events:

Thread 1

1. Request and acquire the write

lock for the PBB2 Tracker list.

2. Since the PBB2 Tracker list is

in wraparound, request and

acquire the write lock for the

Contact 2 list.

3. Thread 1 gets swapped out and

Thread 2 gets swapped in.

Thread 2

4. Request and acquire the write

lock for the PBB1 Tracker list.

5. Since the PBB1 Tracker list is

in wraparound, request and

32

As is evident, deadlock can occur without a predictable scheme to acquire resources. The

following resource acquisition scheme will guarantee that deadlock cannot occur:

• Tracker lists are always locked before contact lists.

• Two contact lists are never locked at the same time.

Given the scenario in Figure 4-4, Thread 1 will acquire and release the write lock for

Contact 2 before it tries to acquire the write lock for Contact 1. Since locks for multiple

contact lists are not held simultaneously, deadlock cannot occur due to interleaving lock

acquisition patterns. The same reasoning applies for Thread 2.

7. Request the write lock for the

Contact 1 list. At this point,

Thread 1 will block on the

request, waiting until Thread 2

releases the Contact 1 lock.



acquire the write lock for the

Contact 1 list.



9. Request the write lock for the

Contact 2 list. At this point,

Thread 2 will block on the

request, waiting until Thread 1

releases the Contact 2 lock.

33

4.5 Chapter Summary

There are three fundamental forces behind the design of the server:

1. A dependency exists between trackers lists and contact lists.

2. Tracker lists and contact lists are shared resources.

3. Resource ordering must be enforced to preclude the possibility of deadlock.

These forces lead to the following design strategies:

1. The Observer design pattern will be used to decouple tracker lists from contact lists,

and to allow Fidus to signal state changes to tracker lists and contact lists.

2. Tracker lists and contact lists are shared resources. Read write locks (shared

exclusive locks) will be used as the basic synchronization mechanism. Read write

locks allow multiple readers into the same list simultaneously, while allowing a writer

exclusive access.

3. Tracker lists will always be locked before contact lists. Two contact lists are never

locked at the same time. This will prevent deadlock due to interleaving contact list

access patterns.

34

5 Use Cases

5.1 Introduction

This Chapter describes the use cases of the server. A use case is a narrative document

that describes the sequences of events of an actor (an external agent) using a system to

complete a process [Lar98]. They are an informal description of what a system does and

who or what is interacting with the system. They are often used to capture the high level

functional requirements of a system.

The following use cases will be described:

Table 5-1 Use Cases for the Sensor History Server

Use Case Purpose Add Fidu Add a Fidu to the server Add Collection of Fidus Add a collection of Fidus to the server Get Fidus for Tracker Stream a tracker list to the client Get Fidus for Contact Stream a contact list to the client Delete Tracker Delete a tracker list from the server Delete Contact Delete a contact list from the server Get List of Trackers Stream a description of all tracker lists to the client Get List of Contacts Stream a description of all contact lists to the client

A use case diagram for the server is presented followed by a description of each use case.

35

5.2 Use Case Diagram for the Sensor History Server

Direction of arrow indicates flow of information.

Add Fidu

Add Sequence Fidus

Producer

Get Fidus For Tracker

Get Fidus For Contact

Delete Tracker

Delete Contact

Get Tracker List

Consumer

Get Contact List

Figure 5-1 Use case diagram for the Sensor History Server.

There are two external agents interacting with the system: a producer of Fidus and a

consumer of Fidus. The producer and consumer are each capable of initiating multiple

use cases. It is possible to have several producers and it is expected to have several

consumers.

36

5.3 Add Fidu

Actors: Producer (initiator), Sensor History Server.

Purpose: Add a Fidu to the server.

Overview: The producer creates a Fidu and streams it to the server. The server

examines the Fidu for pre-condition adherence, and adds the Fidu to its

designated tracker list and contact list.

Typical course of events

Actor Action System Response

Alternative Courses

Line 2: Invalid Tracker Designator. Throw exception to the client (Fidu producer).

Line 2: Invalid Contact Designator. Throw exception to the client.

Line 2: User specified tracker list capacity reached. Throw exception to the client.

Line 2: User specified contact list capacity reached. Throw exception to the client.

1. The Fidu producer creates a Fidu and streams it to the server.

2. The server receives the Fidu

and examines the Tracker Designator and Contact Designator.

3. The server adds the Fidu to the tracker list specified by the Tracker Designator.

4. The server adds the Fidu to the contact list specified by the Contact Designator.

37

5.4 Add Collection of Fidus

Actors: Producer (initiator), Sensor History Server.

Purpose: Add a Collection of Fidus to the server.

Overview: The producer creates a collection of Fidus and streams it to the server.

The server examines each Fidu for pre-condition adherence, and adds

each Fidu to its designated tracker list and contact list.



Alternative Courses

Line 2: Invalid Tracker Designator. Throw exception to the client.


Line 2: User specified tracker list capacity reached. Throw exception to the client.

Line 2: User specified contact list capacity reached. Throw exception to the client.

1. The Fidu producer creates a collection of Fidus and streams it to the server.

2. The server receives the Fidu

collection and examines the Tracker Designator and Contact Designator of each Fidu.

3. The server adds each Fidu to the tracker list specified by the (Fidu’s) Tracker Designator.

4. The server adds each Fidu to the contact list specified by the (Fidu’s) Contact Designator.

38

5.5 Get Fidus For Tracker

Actors: Consumer (initiator), Sensor History Server.

Purpose: Stream a tracker list to the client.

Overview: The consumer requests a collection of Fidus for a tracker. The server

examines the Tracker Designator for pre-condition adherence, and

streams a tracker list to the client.



Alternative Courses


Line 2: The tracker list specified by the Tracker Designator does not exist. Throw

exception to the client.

1. The consumer requests a collection of Fidus for a Tracker Designator.

2. The server receives the

request and examines the Tracker Designator.

3. The server streams the tracker list specified by the Tracker Designator to the client.

39

5.6 Get Fidus For Contact


Purpose: Stream a contact list to the client.

Overview: The consumer requests a collection of Fidus for a contact. The server

examines the Contact Designator for pre-condition adherence, and

streams a contact list to the client.



Alternative Courses


Line 2: The contact list specified by the Contact Designator does not exist. Throw

exception to the client.

1. The consumer requests a collection of Fidus for a Contact Designator.


request and examines the Contact Designator.

3. The server streams the tracker list specified by the Contact Designator to the client.

40

5.7 Delete Tracker


Purpose: Delete a tracker list from the server.

Overview: The consumer requests to delete a tracker. The server examines the

Tracker Designator for pre-condition adherence, and deletes the

tracker list.



Alternative Courses


Line 2: The tracker list specified by the Tracker Designator does not exist. No action.

1. The consumer requests to delete a tracker list specified by a Tracker Designator.


request and examines the Tracker Designator.

3. The server deletes the tracker list specified by the Tracker Designator.

4. The server also deletes each Fidu on the tracker list from the Fidu’s associated contact list.

41

5.8 Delete Contact


Purpose: Delete a contact list from the server.

Overview: The consumer requests to delete a contact. The server examines the

Contact Designator for pre-condition adherence, and deletes the

contact list.



Alternative Courses


Line 2: The contact list specified by the Contact Designator does not exist. No action.

1. The consumer requests to delete a contact list specified by a Contact Designator.


request and examines the Contact Designator.

3. The server deletes the contact list specified by the Contact Designator.

4. The server also deletes each Fidu on the contact list from the Fidu’s associated tracker list.

42

5.9 Get List of Trackers


Purpose: Stream a description of all tracker lists to the client.

Overview: The consumer requests a list of all trackers in the server.



Alternative Courses

None.

1. The consumer requests a list of all trackers in the server.


request. 3. The server creates a list of all

trackers and streams this list to the client.

43

5.10 Get List of Contacts


Purpose: Stream a description of all contact lists to the client.

Overview: The consumer requests a list of all contacts in the server



Alternative Courses

None.

1. The consumer requests a list of all contacts in the server.


request. 3. The server creates a list of

all contacts and streams this list to the client.

44

6 Requirements

6.1 Introduction

This Chapter describes the requirements of the server. Requirements are a description of

needs or desires for a product. The primary goal of a requirements document is to

identify what is really needed, in a form that clearly communicates to the client and to

development team members [Lar98].

6.2 Overview Statement

The purpose of the Sensor History Server is to provide a data archiving and retrieval

capability for data that is used in Target Motion Analysis as well as other submarine

combat control system applications.

6.3 Customers

The customers for this product are applications typically found in submarine combat

control systems.

6.4 Goals

The goal of this product is to develop an acoustic Sensor History Server that places no

architectural limits on the following items:

o The number of contacts that are stored in the server.

o The number of trackers that are stored in the server.

o The number of Fidus per tracker.

45

6.5 System Functions

System functions are what a system is supposed to do. System functions should be

categorized in order to prioritize them and identify those that might otherwise be taken

for granted [Lar98].

Table 6-1 System Function Categories

Function Category Meaning Evident Should perform, and the user should be cognizant that it is

performed. Hidden Should perform, but not be visible to users. This is true of many

underlying technical services. Frill Optional, adding it does not significantly affect cost or other

functions.

6.5.1 Fidu Ingestion The Sensor History Server shall ingest an individual Fidu. A Tracker Designator

and a Contact Designator shall designate the Fidu. The client application shall

specify the Tracker Designator and the Contact Designator.

Each Fidu shall have a valid time stamp. A valid time stamp is a time stamp that

is greater than zero.

Category: Evident

6.5.2 Fidu Collection Ingestion The Sensor History Server shall ingest a collection of Fidus. A Tracker

Designator and a Contact Designator shall designate each Fidu in the collection of

Fidus. The client application shall specify the Tracker Designator and the Contact

Designator.

46

Each Fidu shall have a valid time stamp. A valid time stamp is a time stamp that

is greater than zero.

Category: Evident

6.5.3 Tracker List Capacity The Sensor History Server shall provide a mechanism to set the tracker list

capacity. A tracker list is a list of Fidus that is identified by the same Tracker

Designator. The tracker list capacity is the number of tracker lists the server will

process. This tracker list capacity shall be user configurable.

Category: Evident

6.5.4 Tracker List Capacity Exception The Sensor History Server shall reject a Fidu that is designated by a Tracker

Designator where the ingestion of that Fidu would cause the creation of a tracker

list that would exceed the tracker list capacity.

The server shall inform the client of the Fidu rejection and specify the reason for

the rejection.

Category: Evident

6.5.5 Contact List Capacity The Sensor History Server shall provide a mechanism to set the contact list

capacity. A contact list is a list of Fidus that is designated by the same Contact

Designator. The contact list capacity is the number of contact lists the server will

process. This contact list capacity shall be user configurable.

Category: Evident

47

6.5.6 Contact List Capacity Exception The Sensor History Server shall reject a Fidu that is designated by a Contact

Designator where the ingestion of that Fidu would cause the creation of a contact

list that would exceed the contact list capacity.

The server shall inform the client of the Fidu rejection and specify the reason for

the rejection.

Category: Evident

6.5.7 Fidus Per Tracker List The Sensor History Server shall provide a mechanism to specify the number of

Fidus per tracker list. The initial default capacity of each Fidu list shall be user

configurable.

Note that placing a limit on the number of Fidus per tracker list effectively places

a limit on the number of Fidus per contact list. For example, if there is a limit on

the number of Fidus per tracker of 340, and there is one tracker assigned to a

given contact, then there is a limit on the number of Fidus for that contact of 340.

If there are two trackers assigned to a given contact, then there is a limit on the

number of Fidus for that contact of 680, etc.

Category: Evident

6.5.8 Fidu Waterfall The Sensor History Server shall waterfall Fidus when a tracker list has reached its

Fidu capacity (and a new Fidu is being added to the list). The Fidu capacity of the

tracker list is the number of Fidus it can hold.

48

Category: Hidden

6.5.9 Tracker List Delivery The Sensor History Server shall serve a tracker list. A Tracker Designator shall

identify the tracker list. The client application shall specify the Tracker

Designator.

Category: Evident

6.5.10 Nonexistent Tracker Lists The Sensor History Server shall reject requests for nonexistent tracker lists. The

server shall inform the client of the rejection and specify the reason for the

rejection.

Category: Evident

6.5.11 Contact List Delivery The Sensor History Server shall serve a contact list. A Contact Designator shall

identify the contact list. The client application shall specify the Contact

Designator.

Category: Evident

6.5.12 Nonexistent Contact Lists The Sensor History Server shall reject requests for nonexistent contact lists. The

server shall inform the client of the rejection and specify the reason for the

rejection.

Category: Evident

49

6.5.13 Tracker List Deletion The Sensor History Server shall delete a tracker list. A Tracker Designator shall

identify the tracker list. The client application shall supply the Tracker

Designator.

Category: Evident

6.5.14 Contact List Deletion The Sensor History Server shall delete a contact list. A Contact Designator shall

identify the contact list. The client application shall supply the Contact

Designator.

Category: Evident

6.5.15 List of Tracker Properties The Sensor History Server shall serve a list of tracker properties. Each property

in the list will provide relevant information about the tracker list it is describing.

Category: Evident

6.5.16 List of Contact Properties The Sensor History Server shall serve a list of contact properties. Each property

in the list will provide relevant information about the contact list it is describing.

Category: Evident

50

7 Implementation

7.1 Introduction

This Chapter describes the high level implementation of the server. Physical Design is

the way functional components of an application are distributed over source files.

Correctly partitioning functionality over source files increases maintainability and

reusability of the code base [HV99].

In designing the server, careful consideration was given to separating the application

business logic from the software components that enable network communication.

7.2 High Level Architecture

Figure 7-1 shows a high level architectural diagram. The server consists of two main

components, a CORBA Translation and Delegation layer and the Fidu List Manager.

CORBAIDL

Interfaces

Sensor History Server

Fidu List Manager

JavaInterfaces

JavaDelegationUsing JavaData Types

CORBATranslation and

Delegation Layer

HistoryProducerServant

HistoryConsumerServant

Figure 7-1 Block structure of the Sensor History Server.

51

The CORBA Translation and Delegation layer is an Object Adapter that is responsible

for the following:

• Translate incoming service requests from a CORBA IDL data type to a neutral data

type understood by the Fidu List Manager (FLM). Use of a neutral data type within

the FLM allows the FLM to plug into any Application Service Infrastructure and

serve lists of objects over that particular protocol. In this case the protocol is CORBA

IIOP (Internet Inter-ORB Protocol).

• Delegate the service request to the Fidu List Manager.

• Process any data returned from the FLM, translating necessary objects from the

neutral data type to the applicable CORBA IDL data type, followed by transmission

back to the client.

All client communication (producer and consumer) occurs through the CORBA IDL

interfaces.

The Fidu List Manager is the application component that contains all the business logic

of the server. The design requirements in Chapter 4 specifically pertain to the design of

the Fidu List Manager. This component is designed so it has no knowledge of the

Application Service Infrastructure6 it resides within.

This design achieves clean separation of concerns. One part of the application – the

delegation layer in a separate set of source files – deals with enabling the application for

remote access via CORBA. The other part of the application – the core logic in its own

set of source files – implements the application semantics [HV99].

This separation allows the Fidu List Manager to be “unplugged” from a CORBA

communication infrastructure and plugged into another distributed object model, such as

Java Remote Method Invocation (RMI).

6 In this document, the Application Service Infrastructure is the CORBA Distributed Object Model that handles the low level client / server networking.

52

7.3 Translation and Delegation Layer

Figure 7-2 shows the class diagram for the CORBA Translation and Delegation layer.

This layer consists of the following items:

• Automatically generated source code. This source code is generated by an IDL

compiler and specified by CORBA IDL interface definition files. This generated

code defines the services that remote objects will expose to distributed clients as well

as the plumbing to carry out network communication. For example, the IDL compiler

automatically generates the HistoryProducerPOA.

• Implementation classes that implement interfaces as specified by CORBA IDL

interface definition files. These classes implement the hooks that allow the

application business logic to plug into the CORBA infrastructure. The two main

implementation classes are the HistoryProducerServant and the

HistoryConsumerServant.

The HistoryProducerServant is a CORBA Object Adapter responsible for the

producer side use cases:

• Add Fidu

• Add Collection of Fidus

The HistoryConsumerServant is a CORBA Object Adapter responsible for the

consumer side use cases:

• Get Fidus for Tracker

• Get Fidus for Contact

• Delete Tracker

• Delete Contact

• Get List of Trackers

• Get List of Contacts

53

An additional class, Main, bootstraps the server. A composition relationship exists

between the HistoryProducerServant, the HistoryConsumerServant and

the Main class. An association relationship exists between the ListManager (§7.4),

the HistoryProducerServant and the HistoryConsumerServant.

T h e M a in c la s s b o o t s t ra p s t h e S e n s o r H is t o ry S e rve r .

H is t o r y P ro d u c e rP O A

_ t h is ( )

(f ro m S H P )

M a ino rb : O R Bc o rb a U t i l i t i e s : C o rb a U t i l i t i e sl i s t M a n a g e r : L i s t M a n a g e rn a m in g C o n t e x t : N a m in g C o n t e x tc a t e g o ry : C a t e g o ry

m a in ( )r u n ( )s e t u p L o g 4 jL o g g in g ( )s h o w U s a g e ( )c le a n U p ( )

H is t o r y C o n s u m e rS e rva n tl i s t M a n a g e r : L is t M a n a g e r

H is t o ry C o n s u m e rS e rva n t ( )g e t F id u s F o rT ra c k e r ( )g e t F id u s F o rC o n t a c t ( )d e le t e T ra c k e r ( )d e le t e C o n t a c t ( )g e t T ra c k e rL i s t ( )g e t C o n t a c t L i s t ( )

1

+ C o n s u m e r O b je c t A d a p t e r

1

H is t o ry P ro d u c e rS e rva n tl i s t M a n a g e r : L is t M a n a g e r

a d d C o l l e c t i o n O fF id u s ( )H is t o ry P ro d u c e rS e rva n t ( )a d d F id u ( )

1+ P r o d u c e r O b j e c t A d a p t e r

1

L is t M a n a g e r

a d d F id u ( )a d d C o l l e c t i o n O fF id u s ( )g e t F id u s F o rT ra c k e r ( )g e t F id u s F o rC o n t a c t ( )d e le t e T ra c k e r ( )d e le t e C o n t a c t ( )g e t T ra c k e rL i s t ( )g e t C o n t a c t L is t ( )c le a n U p ( )

( f ro m l i s t M a n a g e r)

< < In t e rf a c e > >

+ M a n a g e F id u L i s t s

+ M a n a g e F id u L is t s

H is t o r y C o n s u m e rP O A

_ th i s ( )

( f ro m S H C )

T h e F i d u L i s t M a n a g e r(a n im p l e m e n ta t io n o f t h e L is t M a n a g e r i n te r fa c e ) i s in s t a n t ia t e d in th e M a in c la s s .

F id u L is t M a n a g e r

< < fin a l> > t r a c k e rR e p o s i t o ry : H a s h m a p = n u l l< < fin a l> > c o n t a c t R e p o s i t o ry : H a s h m a p = n u l lt ra c k e rM a n a g e r : T ra c k e rM a n a g e r = n u l lc o n t a c t M a n a g e r : C o n t a c t M a n a g e r = n u l l

a d d F id u ( )a d d C o l le c t io n O fF id u s ( )g e t F id u s F o rT ra c k e r ( )g e t F id u s F o rC o n t a c t ( )d e le t e T ra c k e r ( )d e le t e C o n t a c t ( )g e t T ra c k e rL is t ( )g e t C o n t a c t L i s t ( )c le a n U p ( )

( f ro m l i st M a n a g e r )

Figure 7-2 Class diagram for the CORBA translation and delegation layer.

55

7.4 Fidu List Manager

Figure 7-3 shows the class diagram for the Fidu List Manager. The Fidu List Manager

consists of one fundamental interface and two classes. The ListManager interface

specifies the method signatures of all use cases. The FiduListManager is an

implementation of the ListManager interface. Node is a wrapper class that holds

Fidus. The FiduListManager stores Nodes, not Fidus. This allows the

FiduListManager to store any type of object that is wrapped in a Node, allowing

other data types to be easily stored within the FiduListManager.

ContactManager and TrackerManager are inner classes within the FiduListManager. The ContactManager aggregates a read-write lock and a contact list. There is a one-to-one relationship between ContactManagers and contact lists. Each contact list gets managed by its ContactManager. The ContactManager is responsible for protecting the contact list from simultaneous reader and writer access (as discussed in §4.3). ContactManager implements the Observer interface. This allows the ContactManager to register for notifications from the Fidus (Nodes) that are on the contact list that the ContactManager manages (as discussed in §4.2). The TrackerManager aggregates a read-write lock and a tracker list. There is a one-to-one relationship between TrackerManagers and tracker lists. Each tracker list gets managed by its TrackerManager. The TrackerManager is responsible for protecting the tracker list from simultaneous reader and writer access (as discussed in §4.3). TrackerManager implements the Observer interface. This allows the TrackerManager to register for notifications from the Fidus (Nodes) that are on the tracker list that the TrackerManager manages (as discussed in §4.2). Class Node wraps a Fidu by storing the Fidu in its fidu property. Node extends the Observable class, allowing it transmit state changes to the ContactManager and TrackerManager that is observing it. Class ContactRepository is a Hashmap that stores ContactManagers. Class TrackerRepository is a Hashmap that stores TrackerManagers.

56

ListManager

addFidu()addCollec tionOfFidus()getFidusForTracker()getFidusForContact()deleteTracker()deleteContact()getTrackerList()getContactLis t()cleanUp()

<<Interface>>

FiduListManager<<final>> trac kerRepository : Hashmap = null<<final>> contactRepository : Hashmap = nul ltrackerManager : TrackerManager = nullcontactManager : ContactManager = null

addFidu()addCollectionOfFidus()getFidusForTracker()getFidusForContact()deleteTracker()deleteContact()getTrackerList()getContactList()cleanUp()

Implements Observer

Im plements Observer

Extends Observable

ContactRepository

11

TrackerRepository

11

ContactManagercontact : java.util.ArrayListcontactLock : ReentrantWriterPreferenceReadWriteLockwriterCount : int = 0

getWriterCount()incrementWriterCount()decrementWriterCount()

0..*0..*

Contact

add(index : Integer, element : Object)add(element : Object)remove(element : Object)

11

TrackerManagert racker : java.util.ArrayListt rackerLock : Reent rantWrit erPreferenceReadWriteLockwriterCount : int = 0

getWriterCount()incrementWriterCount()decrem entWriterCount()

0..*0..*

Tracker

add(index : Integer, element : Object)add(element : Object)remove(element : Object)

11

Nodefidu : ObjectcontactNumber : shorttrackerDecimalCode : short

Node()delete()

1.. *1.. *1..*1..*

Figure 7-3 Class diagram for the Fidu List Manager.

57

7.5 System Configuration

System limits are set via a configuration file. The server reads this file at initialization

time. This allows the number of contacts, the number of trackers, and the number of

Fidus per tracker to be easily configured. These values are stored internally as integers,

thus can be as great as 231 – 1, or over 2 billion.

<fiduServer>

<maxNumberOfContacts>120</maxNumberOfContacts>

<maxNumberOfTrackers>120</maxNumberOfTrackers>

<maxNumberOfFidusPerTracker>340</maxNumberOfFidusPerTracker>

.

.

.

</fiduServer>

58

8 Interaction Diagrams

8.1 Introduction

This Chapter presents the interaction diagrams of the server. An interaction diagram

illustrates the message interactions between instances (and classes) in the class model

[Lar98]. A sequence diagram is one type of interaction diagram. A sequence diagram

displays object interactions arranged in a time sequence, proceeding from the top to the

bottom of the page (or pages).

8.2 Add Fidu

i. Action – Add a Fidu to the Sensor History Server. The producer initiates this action.

This is described by the following operations:

• Create the Fidu.

• Add the Fidu to the tracker list that is identified by the Tracker Designator.

• Add the Fidu to the contact list that is identified by the Contact Designator.

ii. Precondition – Each Fidu has two designators: 1) a Tracker Designator and 2) a

Contact Designator. The Tracker Designator designates the tracker list. The Contact

Designator designates the contact list. The Tracker Designator must be > 0. The

Contact Designator must be > 0.

The server has a tracker list capacity that is determined at startup time by reading a

configuration file. This tracker list capacity is the number of trackers that the server

can hold.

59

The server has a contact list capacity that is determined at startup time by reading a

configuration file. This contact list capacity is the number of contacts that the server

can hold.

The tracker list has a capacity that is determined at startup time by reading a

configuration file. This capacity is the number of Fidus that the tracker can hold.

iii. Operations

a. Get tracker list reference from the tracker list repository

• Lock the tracker list repository

• Get the designated tracker list reference from the tracker list repository.

• Unlock the tracker list repository.

b. Get contact list reference from the contact list repository

• Lock the contact list repository

• Get the designated contact list reference from the contact list repository.

• Unlock the contact list repository.

c. Lock the tracker list.

d. Waterfall the oldest Fidu on the tracker list.

Check to see if the tracker list has reached its capacity. If so, remove the Fidu from

the tracker list and the associated contact list.

e. Lock the contact list.

f. Add the Fidu to tracker list.

g. Add the Fidu to contact list.

h. Unlock the contact list.

i. Unlock the tracker list.

iv. Alternatives

• At step ii: The pre-condition is not met, the Tracker Designator is not > 0.

Action: Abort operation. Throw exception.

• At step ii: The pre-condition is not met, the Contact Designator is not > 0.


60

• At step a: The tracker list identified by the given Tracker Designator does not exist in

the tracker list repository.

Action: Create one. Add the tracker list reference to the tracker list repository.

Continue with step a.

• At step a: The tracker list repository has reached the user defined capacity.


• At step b: The contact list identified by the given Contact Designator does not exist in

the contact list repository.

Action: Create one. Add the contact list reference to the contact list repository.

Continue with step b.

• At step b: The contact list repository has reached the user defined capacity.


• At step c: Unable to lock the tracker list due to an InterruptedException.

Action: Abort operation.

• At step d: Unable to lock the contact list due to an InterruptedException.

Action: Print a log statement. If this ever occurs, investigate in more detail.

• At step e: Unable to lock the contact list due to an InterruptedException.

Action: Unlock the tracker list. Then abort operation.

61

listManager : FiduListManager

: TrackerManager

: ContactManager

: TrackerRepository

: ContactRepository

: Node : Node c ontac tDeletionQueue : (Queue)

: ContactManager

Node being deleted.

Node being added. This is passed in to the listManager.addFidu() method.

ContactManager being added to.

Contac tManager being de leted from.

The ContactManager being deleted from may be the same ContactManager being added to.

IWC happens while thelistManager has the Monitorfor the TrackerRepository

IWC happens while thelistManager has the Monitorfor the ContactRepository

writeLock.acquire()

[wraparound] deletedNode = t rac ker. remove()

incrementWriterCount( )

incrementW riterCount( )

t rackerManager = get (Object )

contactManager = get(Object)

Continued on next page...

Figure 8-1 Sequence diagram for the add Fidu use case.

62


: TrackerManager

: ContactManager

: TrackerRepository

: ContactRepository

: Node : Node contactDeletionQueue : (Queue)

: Cont actManager

If wrapping around, remove the oldest Fidu from the tracker list. Tell the oldest Fidu to delete itself.

Node being deleted.

Node being added.


ContactManager being deleted from.

[wraparound] delete( )

[wraparound] deleteObserver (trackerManager)

update (node)

writeLock.acquire ()

remove (node)

writeLock.release ()

[contact.size() == 0] put(Object)


Figure 8-1a Sequence diagram for the add Fidu use case (page 2 of 4).

63


: TrackerManager

: ContactManager

: TrackerRepository

: ContactRepository


: Cont actManager

Node being deleted.

Node being added.



add (Node)

add (Node)

writ eLock.acquire ()

decrementWriterCount()

addObserver (contactManager)

addObserver (trackerManager)


Figure 8-1b Sequence diagram for the add Fidu use case (page 3 of 4).

64


: TrackerManager

: ContactManager

: TrackerRepository

: ContactRepository


: Cont actManager

Node being deleted.

Node being added.



writeLock.release()

writeLock.release()

Figure 8-1c Sequence diagram for the add Fidu use case (page 4 of 4).

65


i. Action – Add a collection of Fidus to the Sensor History Server. The producer

initiates this action. This is described by the following operations.

• Create the collection of Fidus.

• Add the Fidu(s) to the tracker list(s) that are identified by the individual Tracker

Designators(s).

• Add the Fidu(s) to the contact list(s) that are identified by the individual Contact

Designator(s).

ii. Precondition – Each Fidu has two designators: 1) a Tracker Designator and 2) a

Contact Designator. The Tracker Designator designates the tracker list. The Contact

Designator designates the contact list. The Tracker Designator must be > 0. The

Contact Designator must be > 0.

The server has a tracker list capacity that is determined at startup time by reading a

configuration file. This tracker list capacity is the number of trackers that the server

can hold.

The server has a contact list capacity that is determined at startup time by reading a

configuration file. This contact list capacity is the number of contacts that the server

can hold.

The tracker list has a capacity that is determined at startup time by reading a

configuration file. This capacity is the number of Fidus that the tracker can hold.

iii. Operations – Invoke the Add Fidu (8.2) operation for each Fidu in the Fidu

collection.

66

iv. Alternatives – The alternatives in 8.2 are applicable here. Preserve all exceptions, and

pass back a collection of exceptions if necessary.

: Producer : FiduListManager

addCollectionOfFidus(Object[])

addFidu(Object)

For each Fidu in Object[], call addFidu(Object)

Gather any exceptions from addFidu(), wrap them in a ListManagerException, and throw it to the Producer

Figure 8-2 Sequence diagram for the add collection of Fidus use case.

67

8.4 Get Fidus For Tracker

i. Action – Stream a tracker list to the client. The client initiates this action.

ii. Precondition – A Tracker Designator identifies the tracker list. The Tracker

Designator must be > 0.

iii. Operations

a. Get the tracker list reference from the tracker list repository


• Get the designated tracker list reference from the tracker list repository

• Unlock the tracker list repository

b. Lock the tracker list

c. Clone the tracker list.

d. Unlock the tracker list

e. Stream the Fidus to the client

iv. Alternatives

• At step ii: The pre-condition is not met, the Tracker Designator is not > 0.


• At step a: The tracker list reference is not in the tracker list repository.

Action: Abort operation. Throw exception. An alternative would be to check that the

tracker list is in the tracker list repository before the tracker list repository is locked.

Note that the existence of the tracker list would have to be checked again once the

repository is locked.

• At step b: Unable to lock the tracker list due to an InterruptedException.


• At step e: An IOException occurs while streaming the tracker list to the client.

Action: Abort streaming operation.

68

: Cons umer listManager : FiduListManager

: TrackerRepository

: TrackerManager

getFidusForTracker(short)

trackerManager = get(Object)

readLock.acquire()

trackerClone = tracker.toArray()

readLock.release()

trackerClone is a copy of the tracker.

return trackerClone to the Consumer

Figure 8-3 Sequence diagram for the get Fidus for tracker use case.

69

8.5 Get Fidus For Contact

i. Action – Stream a contact list to the client. The client initiates this action.

ii. Precondition – A Contact Designator designates the contact list. The Contact


iii. Operations

a. Get a contact list reference from the contact list repository

• Lock the contact list repository

• Get the designated contact list reference from the contact list repository

• Unlock the contact list repository

b. Lock the contact list

c. Clone the contact list.

d. Unlock the contact list

e. Stream the Fidus to the client

iv. Alternatives

• At step ii: The pre-condition is not met, the Contact Designator is not > 0.


• At step a: The contact list reference is not in the contact list repository.

Action: Abort operation. Throw exception. An alternative would be to check that the

contact list is in the contact list repository before the contact list repository is locked.

Note that the existence of the contact list would have to be checked again once the

repository is locked.

• At step b: Unable to lock the contact list due to an InterruptedException.


• At step e: An IOException occurs while streaming the contact list to the client.

Action: Abort streaming operation.

70

: Consumer listManager : FiduListManager

: ContactManager

: Contac tRepository

getFidusForContact(short)

contactM anager = get (Object)

readLock.acquire()

contactClone = contact.toArray()

readLock.release()

contactClone is a copy of the contact.

return contactClone to the Consumer

Figure 8-4 Sequence diagram for the get Fidus for contact use case.

71

8.6 Delete Tracker

i. Action – Delete a tracker list from the Sensor History Server. The client initiates this

action. This implies that all Fidus on the tracker list are removed from their

corresponding contact lists.

ii. Precondition – A Tracker Designator identifies the tracker list. The Tracker


iii. Operations

a. Get the tracker list reference from the tracker list repository


• Get the designated tracker list reference from the tracker list repository.

• Unlock the tracker list repository.

b. Lock the tracker list.

c. Process the tracker list.

For each Fidu on the tracker list:

• Remove the Fidu from the tracker list.

• Remove the tracker list from the Fidus observer list.

• Call Fidu.delete(). This removes the Fidu from its contact list.

d. Send a request to delete the tracker list from the tracker repository.

Check the writer count for the tracker list. If it is zero, send a delete request to the

tracker deletion helper

e. Unlock the tracker list.

iv. Alternatives

• At step iii.a: The tracker list reference is not in the tracker list repository.

Action: Abort operation. An alternative would be to check that the tracker list is in

the tracker list repository before the tracker list repository is locked. Note that the

72

existence of the tracker list would have to be checked again once the repository is

locked.

• At step iii.b: Unable to lock the tracker list due to an InterruptedException.


73


: TrackerManager

: TrackerRepository

: Node : ContactManager

contactDeletionQueue : (Queue)

for each Fidu in the tracker list...


deletedNode = t rac ker. remove ()

trackerManager = get (Object)

delete( )

deleteObserver (trackerManager)

update (node)

remove (node)



Figure 8-5 Sequence diagram for the delete tracker use case.

74


: TrackerManager

: TrackerRepository


contactDeletionQueue : (Queue)

finished looping



[contact.size() == 0] put (Object)

Figure 8-5a Sequence diagram for the delete tracker use case (page 2 of 2).

75

8.7 Delete Contact

i. Action – Delete a contact list from the Sensor History Server. The client initiates this

action. This implies that all Fidus on the contact list are removed from their

corresponding tracker lists.

ii. Precondition – The Contact Designator designates the contact list. The Contact


iii. Operations

a. Get a contact list reference from the contact list repository

• Lock the contact list repository.

• Get the designated contact list reference from the contact list repository.

• Unlock the contact list repository.

b. Lock the contact list

c. Clone the contact list

The list iteration will occur on the cloned copy. The contact list is cloned to preserve

resource ordering. It is not possible to process the contact list in a manner similar to

8.6 without risking deadlock.

This is due to the fact that each Node.delete() will lock the tracker list that manages

that particular Node. This would violate the resource ordering principle for this

server. When a thread locks multiple resources (a tracker list and a contact list) the

tracker list is always locked before the contact list. Likewise, the contact list is

always unlocked before the tracker list.

d. Unlock the contact list

e. Process the contact list

For each Fidu on the cloned contact list:

• Call Fidu.delete(). This removes the Fidu from its contact list and its tracker list.

76

iv. Alternatives

• At step iii.a: The contact list reference is not in the contact list repository.

Action: Abort operation. An alternative would be to check that the contact list is in

the contact list repository before the contact list repository is locked. Note that the

existence of the contact list would have to be checked again once the repository is

locked.

• At step iii.b: Unable to lock the contact list due to an InterruptedException.


77


: Contac tManager

: ContactRepository


contactDeletionQueue :

: TrackerManager

trackerDeletionQueue :

for each Fidu in the contact list...

readLock.acquire ()

contactClone = contact.toArray ()

readLock.release()

contactM anager = get(Object)

delete( )

update (node)


remove (node) Continue on next page...

Figure 8-6 Sequence diagram for the delete contact use case.

78


: ContactManager

: ContactRepository


contactDeletionQueue :

: TrackerManager

trackerDeletionQueue :

finished looping


[contact.size() == 0] put(Object)

update (node)


remove (node)


[ tracker.size() == 0] put(Object)

Figure 8-6a Sequence diagram for the delete contact use case (page 2 of 2).

79

8.8 Get List of Trackers

i. Action – Get a collection of tracker property objects. Each tracker property object

describes a tracker list in the server.

ii. Precondition – None.

iii. Operations

a. Get a list of tracker list references from the tracker list repository

• Lock the tracker list repository.

• Get a collection of tracker list references from the tracker list repository.

• Unlock the tracker list repository

b. Process the list of tracker list references

For each tracker list:

• Lock the tracker list.

• Extract the most recent node from the list.

• Create a tracker properties object (describing the tracker).

• Add this tracker properties object to a collection of tracker properties objects.

• Unlock the tracker list.

c. Stream the list of tracker property objects to the client

iv. Alternatives

• At step iii.b: The size of the tracker list is zero. Since each tracker list is not locked

until after the tracker list repository is unlocked, it is possible for a delete tracker

request to occur between the unlocking of the tracker list repository and the locking

of each particular list.

Action: Skip the list.


Action: This will result in an abbreviated list being passed back to the client. Print a

log statement. If this ever occurs, investigate in more detail.

80


: TrackerRepository

trackerManagerList : java.util .Collection

listIterator : java.util.Iterator

: TrackerProps : TrackerManager

trackerPropsList : java.ut il.ArrayList

listIterator will iterate throughall trackerManagers in thetrackerManagerList

get last node from the trac ker

iterate through t rackerM anagers

listSize is the size of the trackerM anagerList

trackerManagerList = values( )

listIterator = iterator( )

has Nex t( )

trackerManager = next( )

readLock.acquire ()

node = get ()

new (lis tSize)


Figure 8-7 Sequence diagram for the get list of trackers use case.

81


: TrackerRepository

trackerManagerList : java.util .Collection


: TrackerProps : TrackerManager

trackerPropsList : java.ut il.ArrayList

if a delete request came in,the number of props objectsin the trackerPropsList may not be equal to listSize

end iterationthroughtrackerManagers

props = new ()

readLock.release ()

add (props)

trimToSize ()

Figure 8-7a Sequence diagram for the get list of trackers use case (page 2 of 2).

82

8.9 Get List of Contacts

i. Action – Get a collection of tracker property objects. Each tracker property object

describes a contact list in the server. The tracker property object has enough

information such that it can be used to report on contact lists.

ii. Precondition – None.

iii. Operations

a. Get a list of contact list references from the contact list repository

• Lock the contact list repository.

• Get a collection of contact list references from the contact list repository.

• Unlock the contact list repository

b. Process the list of contact list references

For each contact list:

• Lock the contact list.

• Extract the most recent node from the list.

• Create a tracker properties object (describing the contact).

• Add this tracker properties object to a collection of tracker properties objects.

• Unlock the contact list.

c. Stream the list of tracker property objects to the client

iv. Alternatives

• At step iii.b: The size of the contact list is zero. Since each contact list is not locked

until after the contact list repository is unlocked, it is possible for a delete contact

request to occur between the unlocking of the contact list repository and the locking

of each particular list.

Action: Skip the list.


83

Action: This will result in an abbreviated list being passed back to the client. Print a

log statement. If this ever occurs, investigate in more detail.

84


: ContactReposit ory

contac tManagerList : java.util .Collec tion

lis tIterator : java.util.Iterator

: TrackerProps : ContactManager

contactPropsList : java.util.ArrayList

lis tIterator will iterate throughall contactManagers in thecontactManagerList

ge t last node from t he contac t

iterate through contactManagers

li stSize is the s ize o f the contactManagerList

contactManagerList = values( )

listIterator = iterator( )

has Next( )

contactManager = next( )

props = new ()

readLock.acquire ()

node = get ()

new (li stSize)

Contin ued on nex t page ...

Figure 8-8 Sequence diagram for the get list of contacts use case.

85


: ContactRepository

contac tManagerList : java.util .Collec tion


: TrackerProps : ContactManager

contactPropsList : java.util.ArrayList

if a delete request came in,the number of props objectsin the contactPropsList may not be equal to listSize

end iterationthroughcontactManagers

readLock.release ()

add (props)

trimToSize ()

Figure 8-8a Sequence diagram for the get list of contacts use case (page 2 of 2).

86

9 Results

9.1 Introduction

This Chapter provides detailed performance metrics for the following use cases:

• Get Fidus for Tracker


Each use case is measured from the perspective of the queuing time in the server.

The notion of queuing time is explained below. The primary objective of these tests is to

measure how the server scales under increasing client load.

9.2 Background

A queuing notation is adopted to qualify and quantify server-side request processing.

Each of the above use cases is described as a queuing model.

Figure 9-1 shows a simple queuing model. Requests arrive at the server for processing.

If the server is not busy, the request will be processed immediately; otherwise the request

will join a queue and wait for processing. Each request always moves through the queue,

but as server utilization increases, some requests may be delayed.

87

ServerArrivals

Waiting Line(Queue)

Ts = Service Time

Tq = Queuing Time

Tw = waiting time

Departures

Figure 9-1 A simple queuing model.

In Figure 9-1, the queue is really the software constructs that enforce mutual exclusion,

that is, the software mechanisms that protect critical sections of code. For example, a

read-write lock on a tracker list acts as a queue. As long as there are no writers in the list,

a reader may immediately read the list. But if there is a writer, the reader will block on

the lock (be delayed in the queue) until the writer leaves the critical section of code.

Table 9-1 shows a subset of the items that are generally of interest in a queuing model

[Sta98]:

Table 9-1 General Queuing Parameters

Parameter Meaning Tw Mean time a request spends waiting for service Ts Mean service time for each request Tq Mean time a request spends in the system (queuing time)

All server measurements are taken either at the interface between the Fidu List Manager

and the Application Service Infrastructure (Figure 9-2) or within the list manager itself.

The queuing time Tq is measured at the boundary between the list manager and the

service infrastructure. The wait time Tw and service time Ts are measured within the list

manager. Although the Fidu List Manager is designed to plug into any service

infrastructure, CORBA is used here. It is important to realize that server measurement

times are not measured at the socket level, that is, at the lowest levels of the Server ORB

88

Core. Rather, they are measured at the interface between the list manager and the

CORBA Object Adapter layer. This is the point that the list manager “plugs into” the

Application Service Infrastructure.

Network

ORBInterface

TqClient Application

Client ORB Core

DIIStaticStub

ORBInterface

Fidu List Manager

Server ORB Core

Skeleton DSIObject

Adapter

Figure 9-2 Fidu List Manager and application service infrastructure boundary.

9.3 Lab Setup

Figure 9-3 shows the hardware suite for performance benchmarking. The server runs on

a Dell Precision 620 workstation with dual 1 GHz processors and 768 Mbytes of RAM.

No other user processes are running on the P620.

The producer and all clients (consumers) run on a dual 550 MHz Dell Precision 210

workstation with 512 Mbytes of RAM. No other user processes are running on the P210.

The network is 100 Mbits per second Ethernet.

89

EthernetEthernet

Precision 620 Precision 210

Router

SensorHistoryServer

Consumer

FiduProducer

Figure 9-3 Hardware suite for performance benchmarking.

9.4 Get Fidus for Tracker

The purpose of this test is as follows:

• Measure the queuing time of the Get Fidus for Tracker use case within the server

under increasing client load.

9.4.1 Test Methodology

Producers – The Fidu producer is run on the P210 workstation. Each second, the

producer creates and transmits 120 Fidus to the server. This is considered a high

producer load and will facilitate benchmarking under typical worst-case usage scenarios.

Consumers – Each test run consists of 4 or 5 phases7. For each successive phase, an

additional consumer process is invoked on the P210 workstation. Each consumer tries to

make 40 tracker requests per second from the server. Increasing the number of consumer

processes increases the load placed on the server. Each consumer runs for 60 minutes.

When multiple consumers are run, they are run simultaneously.

7 Under Windows 2000, the P210 workstation becomes CPU bound after the 4th client. Under SuSE 7.2, it is possible to run 5 clients before the system becomes CPU bound.

90

Table 9-2 Successive Phases for One Get Fidus for Tracker Benchmark Run

Phase Number of Consumers Duration (minutes)1 1 60 2 2 60 3 3 60 4 4 60 5 5 60

The processing characteristics of Windows versus Linux impacts the number of

simultaneous consumer processes that can reasonably run under each operating system.

Under Windows 2000, the system becomes CPU bound beyond the 4th consumer; the

maximum number of processes that can be reasonably run is 4. Under Linux, the system

becomes CPU bound beyond the 5th consumer; the maximum number of processes that

can be reasonably run under Linux is 5. Because of this, phase 5 is run under Linux only.

Another run time difference is seen in the number of server requests per second from

each consumer. As mentioned, each consumer tries to make 40 tracker requests per

second. As long as the computer is not CPU bound, this rate is essentially achievable

under Windows (the number turns out to be 39). Under Linux, however, the consumer

actually makes 23 tracker requests per second. As will be seen, two consumers will

generate 79 requests per second under Windows. Under Linux, two consumers will

generate 46 requests per second. No attempt was made to investigate this or tweak the

consumers such that the number of requests per second would be in lock step as

consumer load is increased across operating systems.

Figure 9-4 shows this use case from the perspective of a queuing model. The first queue

is the TrackerRepository that holds the target TrackerManager. The second

queue is the read-write lock of the target TrackerManager.

91

Server 1

Server 2

Server N

Arrivals

Q1(TrackerRepository)

Q2(TrackerManager 1)

Ts = Service Time

Tq = Queuing Time

Q2(TrackerManager N)

Tw = Wait Time Q1 + Q2

Departures

Departures

Departures

Figure 9-4 Queuing model view of the get Fidus for tracker use case.

The wait time (Tw) is the time it takes the request to get the TrackerManager from

the TrackerRepository and then get the read lock from the TrackerManager.

The service time (Ts) is the time it takes to copy the Fidus on the tracker list and prepare

the list for output. The queuing time (Tq) is the sum of Tw and Ts.

Section 9.4.2 presents the queuing time. This is the most important metric from the

server perspective. Section 9.4.3 and 9.4.4 present the wait time and service time,

respectively.

9.4.2 Queuing Time

This Section presents results for the queuing time for the Get Fidus For Tracker use case.

This will be followed by an analysis that shows the speed differential on a percentage

basis over the range of measured client load.

Figure 9-5 shows the queuing time for Windows 2000 versus SuSE 7.2 GNU/Linux.

Tq - Get Fidus for Tracker (Win2k Pro vs. SuSE 7.2)

y = 0.9084x + 169.34y = 1.3686x + 193.59

0.0

50.0

100.0

150.0

200.0

250.0

300.0

350.0

400.0

0 20 40 60 80 100 120 140 160

Requests / Second

Tq (m

icro

Seco

nds)

Linux:Windows:

Figure 9-5 Queuing time for the get Fidus for tracker use case.

93

Table 9-3 Queuing Time for the Get Fidus For Tracker Use Case for Win2k

Requests/Sec Tq (microseconds) Mean High Low

39 208.4 212.7 203.879 231.9 234.5 229.5114 281.1 292.7 276.3135 289.4 293.3 283.6

Table 9-4 Queuing Time for the Get Fidus For Tracker Use Case for SuSE 7.2

Requests/Sec Tq (microseconds) Mean High Low

23 228.8 231.3 225.946 253.5 258.6 248.769 276.7 277.5 275.490 334 350.5 328.5109 336.3 341.3 330.4

The overlap of measured client load falls between 39 requests per second (the low end of

Windows measurements) and 109 requests per second (the high end of Linux

measurements). No attempt at computing percentage difference in speed is made outside

of this interval since there is no data to back it.

At 39 requests per second, the corresponding queuing time for Linux can be computed as:

Tq Mean = 1.3686 * 39 + 193.59 = 247 microseconds.

The difference in speed of Windows Vs. Linux is 247 – 208.4 = 38.6 microseconds; 38.6

is 15.6 percent of 247.

• The speed differential at the low end of measurement overlap is 15.6 percent.

At 109 requests per second, the corresponding queuing time for Windows can be

computed as:

Tq Mean = 0.9084 * 109 + 169.34 = 268.4 microseconds.

The difference in speed of Windows Vs. Linux is 336.3 – 268.4 = 67.9 microseconds;

67.9 is 20.2 percent of 336.3.

• The speed differential at the high end of measurement overlap is 20.2 percent.

Windows is from 15.6 to 20.2 % faster in queuing time Tq.

94

9.4.3 Wait Time

Figure 9-6 shows the wait time for Windows 2000 versus SuSE 7.2 GNU/Linux.

Tw - Get Fidus for Tracker (Win2k Pro vs. SuSE 7.2)

y = 0.2592x + 64.836y = 0.4462x + 66.861

0.0

20.0

40.0

60.0

80.0

100.0

120.0

140.0

0 20 40 60 80 100 120 140 160

Requests / Second

Tw (m

icro

Seco

nds)

Linux:Windows:

Figure 9-6 Wait time for the get Fidus for tracker use case.

96

Table 9-5 Wait Time for the Get Fidus For Tracker Use Case for Win2k

Requests/Sec Tw (microseconds) Mean High Low

39 76.5 78.5 71.7 79 81.0 83.3 78.6 114 98.7 101.3 95.7 135 98.3 106.6 93.7

Table 9-6 Wait Time for the Get Fidus For Tracker Use Case for SuSE 7.2

Requests/Sec Tw (microseconds) Mean High Low

23 78.2 80.2 77.3 46 84.9 88.2 83.0 69 95.8 97.8 93.7 90 114.2 124.4 109.3109 111.6 115.7 108.8

At 39 requests per second, the corresponding wait time for Linux can be computed as:

Tw Mean = 0.4462 * 39 + 66.861 = 84.3 microseconds.

The difference in speed of Windows Vs. Linux is 84.3 – 76.5 = 7.8 microseconds; 7.8 is

9.3 percent of 84.3.


At 109 requests per second, the corresponding wait time for Windows can be computed

as:

Tw Mean = 0.2592 * 109 + 64.836 = 93.1 microseconds.

The difference in speed of Windows Vs. Linux is 111.6 – 93.1 = 18.5 microseconds; 18.5

is 16.6 percent of 111.6.


9.4.4 Service Time

Figure 9-7 shows the service time for Windows 2000 versus SuSE 7.2 GNU/Linux.

Windows is from 9.3 to 16.6 % faster in wait time Tw.

Ts - Get Fidus for Tracker (Win2k Pro vs. SuSE 7.2)

y = 0.6488x + 104.55y = 0.9229x + 126.69

0.0

50.0

100.0

150.0

200.0

250.0

0 20 40 60 80 100 120 140 160

Requests / Second

Ts (m

icro

Seco

nds)

Linux:Windows:

Figure 9-7 Service time for the get Fidus for tracker use case.

98

Table 9-7 Service Time for the Get Fidus for Tracker Use Case for Win2k

Requests/Sec Ts (microseconds) Mean High Low

39 131.9 134.3 128.379 150.9 153.4 146.9114 182.4 197.1 176.7135 191.1 196.4 183.8

Table 9-8 Service Time for the Get Fidus for Tracker Use Case for SuSE 7.2


23 150.6 152.5 147.946 168.5 175.1 160.469 180.9 181.7 179.790 219.9 226.2 215.4109 224.7 229.5 220.4

At 39 requests per second, the corresponding service time for Linux can be computed as:

Ts Mean = 0.9229 * 39 + 126.69 = 162.7 microseconds.


30.8 is 18.9 percent of 162.7.


At 109 requests per second, the corresponding service time for Windows can be

computed as:

Ts Mean = 0.6488 * 109 + 104.55 = 175.3 microseconds.


49.4 is 22.0 percent of 224.7.


9.4.5 Summary

Table 9-9 summarizes the queuing time Tq, wait time Tw and service time Ts results for

Windows 2000 and SuSE 7.2 GNU/Linux.

Windows is from 18.9 to 22.0 % faster in service time Ts.

99

Table 9-9 Get Fidus For Tracker Queuing Parameter Times

Tq (µSec) Tw (µSec) Ts (µSec) Server Load (Requests/Sec) Win2k SuSE7.2 Win2k SuSE7.2 Win2k SuSE7.2

39 208.4 247 76.5 84.3 131.9 162.7 109 268.4 336.3 93.1 111.6 175.3 224.7

On a percentage basis, the queuing time is 15.6 to 20.2 % faster on Windows.

All server measurements were taken either at the interface between the Fidu List

Manager and the Application Service Infrastructure or within the list manager itself.

Most of the difference in Tq is due to the relatively higher values for Ts. This is

indicative of the fundamental fact that memory allocation is faster under Windows 2000

than SuSE 7.2. See Chapter 10 for further details.


The purpose of this test is as follows:

• Measure the queuing time of the Add Collection of Fidus use case within the server

under increasing client load.

9.5.1 Test Methodology

Producer – The Fidu producer is run on the P210 workstation. Each second, the

producer creates and transmits 120 Fidus to the server. Again, this is considered a high

producer load and will facilitate benchmarking under typical worst-case usage scenarios.

Consumer – The methodology of the consumer is the same as §9.4.1, thus will not be

repeated. Of the queuing parameters listed in Table 9-1, only the queuing time (Tq) is

measured. This is due to the internal construction of the Fidu List Manager.

100

9.5.2 Queuing Time

Figure 9-8 shows the queuing time for Windows 2000 versus SuSE 7.2 GNU/Linux.

Tq - Add Collection of Fidus (Win2k Pro vs. SuSE 7.2)

y = 0.0345x + 3.3557y = 0.0389x + 3.0967

0

1

2

3

4

5

6

7

8

9

0 20 40 60 80 100 120 140 160

Requests / Second

Tq (m

illiS

econ

ds)

Linux:Windows:

Figure 9-8 Queuing time for the add collection of Fidus use case.

102

Table 9-10 Queuing Time for the Add Collection of Fidus Use Case for Win2k


39 4.45 4.60 4.40 79 6.53 6.70 6.30 114 7.28 7.40 7.10 135 7.85 8.10 7.60

Table 9-11 Queuing Time for the Add Collection of Fidus Use Case for SuSE 7.2


23 3.87 4.00 3.80 46 4.63 4.90 4.40 69 6.30 6.40 6.10 90 6.93 7.10 6.80 109 6.87 7.00 6.70

There is little overall difference in behavior for this use case between Widows and Linux.

9.6 Chapter Summary

Queuing time, wait time and service time are standard parameters that qualify and

quantify the manner in which a server processes client requests. Knowledge of these

parameters allows system architects to understand how a server scales under increasing

client load, and to determine if a given server architecture can meet the demands of its

clients.

Sensor History Server clients are categorized as producers and/or consumers. Producers

instantiate Fidus and feed them to the server. Consumers request lists of Fidus for

various data processing activities.

These parameters were measured and compared under the Windows 2000 Professional

and SuSE 7.2 GNU/Linux Professional operating systems.

The queuing time, wait time and service time for consumer service requests was

measured under increasing consumer load. The queuing time for producer service

requests was measured under increasing consumer load.

103

The most important parameter for understanding server behavior is the queuing time.

This is the time it takes a request to move through various queues within the server and

then receive service. The queuing time is the sum of the wait time and the service time.

The queuing time for consumer service requests is from 15.6 to 20.2 % faster under

Windows 2000 than SuSE 7.2 GNU/Linux, depending on consumer load.

The queuing time for producer service requests is essentially identical for both operating

systems.

104

10 Discussion

10.1 Introduction

This Chapter presents the fundamental reason the performance of this type of Java

application is superior under Windows 2000 Professional than SuSE 7.2 GNU/Linux

Professional. It concludes with a look towards future combat system designs with an

emphasis on self contained software components.

10.2 Memory Allocation

Memory allocation under Windows 2000 is fundamentally faster than Linux. A request

for a tracker list is a memory intensive operation. The size of a typical Fidu is 576 bytes.

A request for a tracker list with a capacity of 340 Fidus results in a memory allocation of

340 * 576 = 196 Kbytes to prepare the Fidus for network transport.

Table 10-1 steps through the instantiation of various sized blocks of Fidus. It starts with

the allocation of 340 Fidus, the historical size of a typical tracker list. It steps up and

ends with the allocation of 34000 Fidus. Win2k Advantage is the relative speed

advantage of Windows 2000. All times are in milliseconds.

These numbers are representative of the speed advantage Windows holds in the service

time analysis of §9.4.4. The steady decline in the Windows advantage as the number of

Fidus increase is left as an item of further research.

Table 10-1 Fidu Instantiation Times for Win2k vs. Linux

Number of Fidus Time (mS) Win2k Advantage (%) Win2k SuSE7.2

340 6.7 9 25.6 3400 126.8 162.1 21.8 8500 321.1 394.2 18.5

105

17000 857.9 1037.9 17.3 34000 1675 1983.4 15.5

Note the instantiation times are an order of magnitude greater than the typical service

time for processing a tracker list request. That is, Table 10-1 shows it takes either 6.7 or

9 milliseconds to instantiate 340 Fidus, depending on operating system. Table 9-7 and

Table 9-8 show service times on the order of 150 to 200 microseconds for Windows and

SuSE respectively. In both cases, memory for 340 Fidus is being allocated.

The difference is the allocation mechanism. For the example above, a test program

looped and called new Fidu() 340 times. When the server prepares a tracker list for

network transport, java.util.ArrayList.toArray() is called to duplicate the

tracker list.

The fundamental point however, is still valid. For the amounts of memory being

allocated, allocation is faster under Windows 2000 than under SuSE GNU/Linux. This is

true regardless of the allocation mechanism.

Fidu Instantiation (Win2k Pro vs SuSE 7.2)

y = 0.0489xy = 0.0582x

0

500

1000

1500

2000

2500

0 5000 10000 15000 20000 25000 30000 35000 40000

Number of Fidus

Tim

e (m

illiS

econ

ds)

Linux:Windows:

Figure 10-1 Fidu instantiation time for Win2k vs. SuSE 7.2.

107

10.3 Towards a Component Based Submarine Combat System

Software that is designed for submarine combat control systems should be adaptable in

order to remain useful during the long lifecycle typical of military systems. In particular,

adaptability is needed to facilitate the (re)configuration of combat systems dynamically to

support varying workloads or missions [SSM+01].

The Sensor History Server is designed with this adaptability in mind, as evidenced by the

following:

• The objective of this thesis, to design an architecture that places no limits on the

number of contacts or the number of trackers that are stored in the server, as well as

no limits on the number of Fidus that are stored per tracker.

This architecture enables the server to dynamically adapt to varying workloads.

System limits (numbers of contact, trackers, Fidus per tracker) are easily adjusted via

modifications to a simple configuration file. The server reads this file upon

initialization and sets its capacity accordingly. It is also possible to run the server

without any system configured (contact, tracker, Fidu) limits. In this case, it is the

amount of RAM configured for the JVM that ultimately determines the capacity of

the server.

• The physical design of the software, which separates application business logic from

the software components that enable network communication. The application

business logic is self-contained in the Fidu List manager. CORBA is the software

component that enables network communication. A Translation and Delegation

Layer decouples the Fidu List Manager from the CORBA communication

infrastructure. As discussed in Chapter 7, this separation of concerns allows the Fidu

List Manager to be unplugged from the CORBA communication infrastructure and

plugged into another distributed object model. Such a decision might be made during

a technology refresh of the combat system.

108

The functionality provided by this server is a fundamental component of every submarine

combat control system. The placement of all business logic in the Fidu List Manager

moves towards COTS based software components that can be pulled “off the shelf” and

plugged into adaptable combat system designs of the future.

109

11 Conclusions and Recommendations for Future Work

This thesis demonstrates the software architecture of a Sensor History Server that is free

of the constraints of legacy combat system implementations. This architecture allows the

server to adapt to the changing workload requirements likely during the long lifecycle

typical of military systems.

11.1 Viability of Java in a Submarine Combat System

The Java Virtual Machine is an example of Host Infrastructure Middleware that

encapsulates and enhances native operating system communication and concurrency

mechanisms to create portable and reusable network programming components

[SSR+00]. The use of a Java Virtual Machine abstracts away accidental incompatibilities

of individual operating systems, and helps eliminate many tedious, error prone, and non-

portable aspects of developing and maintaining networked applications via low level

operating system application programming interfaces, such as Sockets or Posix Threads.

This has the potential of reducing software development and evolution costs significantly

[SSM+01]. In particular, there is reasonable assurance that software developed under one

operating system will exhibit the same run-time characteristics under a different

operating system8.

Server benchmarking demonstrates tracker request processing times from 132 to 175

microseconds under Windows 2000 Professional, depending on system load. Tracker

request processing times vary from 151 to 225 microseconds under SuSE 7.2

GNU/Linux. In either case, these queuing times are acceptable for submarine combat

control Target Motion Analysis and geographic plotting applications. This demonstrates

the viability of the use of Java within the context of a submarine combat control system.

8 However, the world is not perfect. Appendix B: Uniformity of Time Step, details diverging behavior of the System.currentTimeMillis() call under Windows 2000 and SuSE GNU/Linux.

110

11.2 Generalizing Measurement Types

The data management architecture described herein has been applied to measurements

(Fidus) generated from passive sonar sensors only. However, the architecture of the

server is type neutral. More to the point, the architecture of the Fidu List Manager is type

neutral; the Fidu List Manager can serve any type of object, as discussed in Chapter 7.

This is accomplished by wrapping incoming objects in a Node. It is the Node that is

added to and requested from the Fidu List Manager.

Measurements from different types of sensors are collected and analyzed in a submarine

combat system, for example Sonar, Radar and Periscope. Constructing appropriate

interfaces to handle these measurement types will enable the server to serve these

measurements.

Figure 7-1 is repeated below to facilitate subsequent discussion.

CORBAIDL

Interfaces


Fidu List Manager

JavaInterfaces



Delegation Layer

HistoryProducerServant

HistoryConsumerServant

As discussed in §7.3, the CORBA Translation and Delegation layer is responsible for the

following:

111

• Translate incoming service requests from a CORBA IDL data type to a neutral data

type understood by the Fidu List Manager. Use of a neutral data type within the FLM

allows the FLM to plug into any Application Service Infrastructure and serve lists of

objects over that particular protocol.

• Delegate the service request to the Fidu List Manager.

• Process any data returned from the FLM, translating necessary objects from the

neutral data type to the applicable CORBA IDL data type, followed by transmission

back to the client.

This translation, or wrapping objects in a Node, occurs in the

HistoryProducerServant (for producers) or the HistoryConsumerServant

(for consumers). The following code snippet from the HistoryProducerServant

illustrates this:

/** * A CORBA Servant, implements the producer side interfaces as specified in * SensorHistoryProducer.idl. This class acts as an <i>Object Adapter</i> in * that the methods of this class merely pass incoming requests on to the * <code>ListManager</code>. * @version 1.17 * @author Frederick G. Burkley * @see fiduServer.listManager.ListManager */ public class HistoryProducerServant extends HistoryProducerPOA { /** * The <code>ListManager</code>. The recipient of incoming Filtered Input * Data Units (FIDUs). */ private ListManager listManager = null; // Additional variables and constructor omitted for brevity /** * Create a Filtered Input Data Unit (FIDU) in the <code>ListManager</code>. * This method forwards the FIDU to the <code>ListManager</code>. * @param fiduType The FIDU. * @throws // exceptions omitted for brevity */ public void addFidu (FiduType fiduType) throws // exceptions omitted for brevity { // need to wrap fidu so it can be treated generically by the list services Node node = new Node (fiduType, fiduType.baseFidu.contactNumber, fiduType.baseFidu.trackerDecimalCode);

112

try { listManager.addFidu (node); } catch // exceptions omitted for brevity { } } // Additional methods omitted for brevity }

The parameter to the addFidu() method of the HistoryProducerServant is of

type FiduType. This object type is defined in the CORBA IDL interface definition.

The FiduType object represents a measurement that is generated from a passive sonar

sensor. This object is wrapped in an object of type Node, then passed to the

addFidu() method of the listManager. This is where the Translation and

Delegation occurs. The incoming object of type FiduType is translated to an object of

type Node. The addFidu() method request of the HistoryProducerServant is

then delegated to the addFidu() method of the listManager. The listManager

is an instance of a FiduListManager.

Since it is a Node that is added to the listManager, the Node could wrap any type of

object. This design feature is what makes the server extensible. Adding additional

CORBA IDL interface definitions and relevant servants in the CORBA Translation and

Delegation layer will extend the server to process additional types of objects. Of

particular interest are measurements from Radar, Periscope and ESM sensors.

The following Section presents an architectural extension that allows the server to serve

objects from different types of sensors.

11.3 Extension Via Type Specific Producer and Consumer Servants

As discussed in §7.3, the HistoryProducerServant is a CORBA Object Adapter

responsible for the producer side use cases:

• Add Fidu

113


This is accomplished by implementing an interface as defined by the following CORBA

IDL snippet:

// Sensor History Producer module SHP { interface HistoryProducer { // // The History Server shall provide a CORBA interface that accepts a // collection of Fidus. // void addCollectionOfFidus (in SH::FiduSeq fidus) raises (LMT::ListManagerException) ; // // The History Server shall provide a CORBA interface that accepts a Fidu. // void addFidu (in SH::FiduType fidu) raises (BT::IllegalArgumentException, TrackerCapacityException, ContactCapacityException) ; }; };

Just as the SHP module defines a HistoryProducer interface whose purpose is to

facilitate transmission of objects of type FiduType between a Fidu producer and the

server, additional CORBA IDL modules could be defined whose purpose is to facilitate

transmission of additional object types from other producers.

For example, a CORBA IDL module named RHP (Radar History Producer) might be

defined as follows:

// Radar History Producer module RHP { interface RadarProducer { // // The History Server shall provide a CORBA interface that accepts a // collection of Radar measurements. // void addCollectionOfRadarMeasurements (in RH::RadarSeq radarMeasurements) raises () ; // exceptions omitted for brevity //

114

// The History Server shall provide a CORBA interface that accepts a Radar // measurement. // void addRadarMeasurement (in RH::RadarType radarMeasurement) raises () ; // exceptions omitted for brevity }; };

Given this IDL interface definition, a RadarProducerServant could be written that

performs a Translation and Delegation function for objects of type RadarType in the

same fashion that the HistoryProducerServant performs a Translation and

Delegation function for objects of type FiduType.

CORBAIDL

Interfaces


Fidu List Manager

JavaInterfaces



Delegation Layer

FiduProducerServant

FiduConsumerServantRadar

ProducerServantRadar

ConsumerServant

Figure 11-1 Block structure of a Sensor History Server with type specific servants.

A block structure of this architecture is presented in Figure 11-1. The corresponding

class diagram appears in Figure 11-2.

115

Processing of additional measurement types simply entails the definition of a

corresponding CORBA IDL module and implementation of a servant to handle the

translation and delegation.

Given this architectural extension, the names of the methods in the listManager

interface could be changed to reflect the general nature of the listManager. For

example, listManager.addFidu() could be changed to listManager.addReport().

The name of the implementing class could be changed from FiduListManager to

SensorListManager. This reflects the generalized nature of the “List Manager”. It

does not just manage Fidu lists, rather it manages lists of sensor reports.

T h e M a i n c l a s s b o o t s t r a p s t h e S e n s o r H i s t o r y S e r v e r .

F i d u P r o d u c e r P O A

_ t h i s ()

( f r o m F H P )

F i d u C o n s u m e r P O A

_ t h i s ()

( f r o m F H C )

T h e S e n s o r L i s t M a n a g e r( a n im p le m e n t a t i o n o f t h e L i s t M a n a g e r in t e r fa c e ) i s i n s t a n t i a t e d i n t h e M a i n c l a s s .

S e n s o r L i s t M a n a g e r

< < f i n a l > > s e n s o r R e p o s i t o r y : H a s h m a p = n u l l< < f i n a l > > c o n t a c t R e p o s i t o r y : H a s h m a p = n u l ls e n s o r M a n a g e r : S e n s o r M a n a g e r = n u l lc o n t a c t M a n a g e r : C o n t a c t M a n a g e r = n u l l

a d d R e p o r t ( )a d d C o l l e c t i o n O f R e p o r t s ( )g e t R e p o r t s F o r S e n s o r ( )g e t R e p o r t s F o r C o n t a c t ( )d e l e t e S e n s o r ( )d e l e t e C o n t a c t ( )g e t S e n s o r L i s t ( )g e t C o n t a c t L i s t ( )c l e a n U p ( )

( f r o m l i s t M a n a g e r )

R a d a r P r o d u c e r P O A

_ t h i s ( )

( f r o m R H P )

R a d a r C o n s u m e r P O A

_ t h i s ( )

( f r o m R H C )

L i s t M a n a g e r

a d d R e p o r t ( )a d d C o l l e c t i o n O f R e p o r t s ( )g e t R e p o r t s F o r S e n s o r ( )g e t R e p o r t s F o r C o n t a c t ( )d e l e t e S e n s o r ( )d e l e t e C o n t a c t ( )g e t S e n s o r L i s t ( )g e t C o n t a c t L i s t ( )c l e a n U p ( )

( f r o m l i s t M a n a g e r )

< < I n t e r f a c e > >

F i d u C o n s u m e r S e r v a n tl i s t M a n a g e r : L i s t M a n a g e r

F i d u C o n s u m e r S e r v a n t ( )g e t F i d u s F o r T r a c k e r ( )g e t F i d u s F o r C o n t a c t ( )d e l e t e T r a c k e r ( )d e l e t e C o n t a c t ( )g e t T r a c k e r L i s t ( )g e t C o n t a c t L i s t ( ) + M a n a g e L i s t s

F i d u P r o d u c e r S e r v a n tl i s t M a n a g e r : L i s t M a n a g e r

a d d C o l l e c t i o n O f F i d u s ( )F i d u P r o d u c e r S e r v a n t ( )a d d F i d u ( )

+ M a n a g e L i s t s

R a d a r P r o d u c e r S e r v a n t

a d d C o l l e c t i o n O f R a d a r R e p o r t s ( )R a d a r P r o d u c e r S e r v a n t ( )a d d R a d a r R e p o r t ( )

M a i no r b : O R Bc o r b a U t i l i t i e s : C o r b a U t i l i t i e sl i s t M a n a g e r : L i s t M a n a g e rn a m i n g C o n t e x t : N a m i n g C o n t e x tc a t e g o r y : C a t e g o r y

m a i n ( )r u n ( )s e t u p L o g 4 j L o g g i n g ( )s h o w U s a g e ( )c l e a n U p ( )

1

+ F i d u C o n s u m e r O b j e c t A d a p t e r

1

1

+ F i d u P r o d u c e r O b j e c t A d a p t e r

1

11+ R a d a r P r o d u c e r O b j e c t A d a p t e r

R a d a r C o n s u m e r S e r v a n t

R a d a r C o n s u m e r S e r v a n t ( )g e t R a d a r R e p o r t s F o r C o n t a c t ( )d e l e t e R a d a r R e p o r t s F o r C o n t a c t ( )

11+ R a d a r C o n s u m e r O b j e c t A d a p t e r

R a d a r P r o d u c e r O b j e c t A d a p t e r



Figure 11-2 Class diagram of a Sensor History Server with type specific servants.

117

11.4 Event Mechanism

An event mechanism is a well suited to this type of server. TMA applications

periodically update their measurement sets; typically, an application will update it’s Fidu

list (or lists) every 20 seconds. This allows the application to include the most recent

data in it’s processing.

The current implementation of the server has no notion of an event mechanism. When an

application wants a periodic Fidu update, it has to request a full tracker list or contact list.

This is inefficient across the board: in terms of server processing, client processing and

network bandwidth.

Implementing an event mechanism allows a client to receive notification of new Fidus.

This gives the client the mechanism to request periodic list updates from the server.

These list updates would be limited to the newly arrived Fidus at the server, rather than

requests for full tracker lists or contact lists. This approach would yield substantial

increases in efficiency.

118

References

[And00] Gregory R. Andrews: Foundations of Multithreaded, Parallel and Distributed

Programming, Addison-Wesley, 2000.

[Ben90] M. Ben-Ari: Principles of Concurrent and Distributed Programming, Prentice

Hall, 1990.

[GoF95] E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns – Elements of

Reusable Object-Oriented Software, Addison-Wesley, 1995.

[HV99] Henning M., S. Vinoski: Advanced CORBA Programming with C++,

Addison-Wesley, 1999.

[Lar98] C. Larman: Applying UML and Patterns, Prentice Hall, 1998.

[Lea99] D. Lea: Concurrent Programming in Java: Design Principles and Patterns,

2nd Edition, Addison-Wesley, 1999.

[Lew95] B. Lewis: Threads Primer: A Guide to Multithreaded Programming, Prentice

Hall, 1995.

[NavPers 16167] Standards and Curriculum Division, Training, Bureau of Naval

Personnel: The Fleet Type Submarine Online Submarine Sonar Operator’s

Manual, http://www.maritime.org/fleetsub/sonar/.

[OW99] S. Oaks, H. Wong: Java Threads, 2nd Edition Java 2, O’Reilly, 1999.

[Pow02] J. Powell Jr.: The Case For COTS, COTS Journal, vol. 4, no. 5, pp. 65-68,

May 2002.

119

[SSM+01] D. Schmidt, R. Schantz, M. Masters, J. Cross, D. Sharp, L. DiPalma: Towards

Adaptive and Reflective Middleware for Network-Centric Combat Systems,

CrossTalk, vol. 14, no. 11, PP. 10-16, November 2001.

[SSR+00] D. Schmidt, M. Stal, H. Rohnert, F. Buschmann: Pattern-Oriented Software

Architecture, Volume 2: Patterns for Concurrent and Networked Objects,

John Wiley & Sons, 2000.

[Sta98] W. Stallings: Operating Systems: Internals and Design Principles, 3rd Edition,

Prentice Hall, 1998.

[Sta01] W. Stallings: Operating Systems: Internals and Design Principles, 4th Edition,

Prentice Hall, 2001.

[Ste93] W. R. Stevens: Advanced Programming in the UNIX Environment, Addison-

Wesley, 1993.

[Ste98] W. R. Stevens: UNIX Network Programming, Volume 1: Networking APIs:

Sockets and XTI, 2nd Edition, Prentice Hall, 1998.

[Ste99] W. R. Stevens: UNIX Network Programming, Volume 2: Interprocess

Communications, 2nd Edition, Prentice Hall, 1999.

[Tan95] A. S. Tanenbaum: Distributed Operating Systems, Prentice Hall, 1995.

120

Appendix A: Glossary of Terms

Spherical An arrangement of hydrophones in a spherical pattern. This pattern

Array facilitates the determination of the arrival angle of a sound wave.

CORBA The Common Object Request Broker Architecture. A specification by the

Object Management Group for distributed object communication.

COTS Commercial Off The Shelf. General purpose hardware or software

components which are assembled into larger systems.

Deadlock A concurrency hazard that occurs when multiple threads attempt to

acquire multiple locks and become blocked indefinitely in a circular wait

state.

Fidu Filtered Input Data Unit. Averaged measurements from an acoustic sensor

aboard a submarine.

Hydrophone A device that transforms sound waves into electrical signals.

IDL The CORBA Interface Definition Language. An interface specification

language whose purpose is to define services that objects will expose to

distributed clients.

TMA Target Motion Analysis. A technique used to estimate the range, course

and speed of a contact (target) from a set of measured bearings and

frequencies.

Tracker An algorithm that processes electrical signals output from a hydrophone

array and estimates the bearing to the noise source.

121

Tracker An identifier indicating the tracker that produced a bearing.

Designator

Contact An identifier indicating the contact that a tracker is tracking.

Designator

122

Appendix B: Uniformity of Time Step

A fundamental requirement of any performance analysis is uniformity of measurement

tools. A meaningful comparison of the delay time across a queue or the round trip time

of a client request necessitates the same fidelity of time step.

The following table shows the fidelity of java.lang.System.currentTimeMillis() for the

Windows 2000 Professional and SuSE Linux 7.2 Professional operating systems. Since

the time step is not the same for both cases, System.currentTimeMillis() is an inadequate

tool for delay time comparisons between Windows 2000 and SuSE Linux.

Method / Operating System Windows 2000 SMP SuSE Linux 7.2 SMP System.currentTimeMillis() 15 or 16 milliseconds 1 millisecond

Additionally, the time step of System.currentTimeMillis() is 10 milliseconds on uni-

processor Windows 2000 Professional system.

A search of the Internet revealed a native package by Maciej Puzio ([email protected])

that solves this problem. The SystemX package calls the Win32

QueryPerformanceCounter function, thus achieving time step fidelity of 1 millisecond.

The following table shows the fidelity of java.lang.SystemX.currentTimeMillis() for

Windows 2000 Professional. Since the time step is 1 millisecond,

SystemX.currentTimeMillis() is an adequate tool for delay time measurements on

Windows.

Method / Operating System Windows 2000 SMP SuSE Linux 7.2 SMP System.currentTimeMillis() 15 or 16 milliseconds 1 millisecond

SystemX.currentTimeMillis() 1 millisecond Not available

123

System.currentTimeMillis() was used for performance metrics on SuSE Linux 7.2.

SystemX.currentTimeMillis() was used for performance metrics on Windows 2000

Professional.

124

Appendix C: Investigation of System.currentTimeMillis()

Prior to the adoption of Maciej Puzio’s SystemX.currentTimeMillis(), data anomalies

were an occasional but predictable occurrence (with Sun’s System.currentTimeMillis()).

This was observed under Windows only.

System.currentTimeMillis() will occasionally return descending times. That is given the

following code snippet:

long lastTime = System.currentTimeMillis (); // some method call long thisTime = System.currentTimeMillis (); long elapsedTime = thisTime – lastTime;

ElapsedTime would occasionally be less than zero. A small test program demonstrates

this. This problem occurs on SMP hardware only. The same test program has run on

uni-processor hardware and the problem does not occur.

The test code appears below.

import java.util.Enumeration; import java.util.Vector; /** * Test to see if System.currentTimeMillis() breaks. */ public class CurrentTimeMillisTest implements Runnable { /** want to allocate heap to get some garbage collection. */ private class TestObj { Vector v; /** */ private TestObj () { v = new Vector (100); for (int j=0; j<v.size (); j++) { v.addElement ("Element " + j); }

125

} } /** */ public CurrentTimeMillisTest () { } /** * check System.currentTimeMillis() */ public void run () { try { long lastTime = System.currentTimeMillis (); long thisTime; while (true) { // allocate many objects TestObj obj[] = new TestObj[1000]; for (int i=0; i<obj.length; i++) { obj[i] = new TestObj (); } thisTime = System.currentTimeMillis (); if (thisTime - lastTime < 0) { System.err.println ("ERROR: thisTime=" + thisTime + " lastTime=" + lastTime + " timeWarp=" + (thisTime-lastTime)); } lastTime = thisTime; Thread.currentThread ().sleep (5); } } catch (InterruptedException ignore) { } } /** bootstrap */ public static void main (String[] args) { final Vector threadList = new Vector (); Thread t = null; Runnable ctmTest = new CurrentTimeMillisTest (); for (int i=0; i<100; i++) { t = new Thread (ctmTest); threadList.add (t); t.start ();

126

} // add shutdown hook Runtime runtime = Runtime.getRuntime (); runtime.addShutdownHook (new Thread () { Thread t; public void run () { System.out.println ("Enter shutdown hook..."); Enumeration enum = threadList.elements (); while (enum.hasMoreElements ()) { t = (Thread)enum.nextElement (); System.out.println ("Interrupting " + t.getName ()); t.interrupt (); try { System.out.println ("Trying to Join " + t.getName ()); t.join (); System.out.println ("Joining " + t.getName ()); } catch (InterruptedException ie) { ie.printStackTrace (); } } } }); } }

Documents

An Acoustic Sensor History Server for a Submarine Combat Control