Asynchronous management of movable components

Techniques for asynchronous management of physical components are disclosed. A request to perform an operation in a tape library, including a physical task to be performed by a component, is received. Based on the request, a message handler is initialized. The message handler executes in an execution thread. State data associated with the component is retrieved from persistent storage. Using the state data, a code object representing the component is instantiated. Using the message handler and the code object, instructions are transmitted to the component to perform the physical task. A process, executing in a different execution thread, receives a message from the component indicating completion of the physical task. Based on the message, another message handler is initialized that updates persistent storage associated with the component.

TECHNICAL FIELD

The present disclosure relates to movable components. In particular, the present disclosure relates to managing movable components.

BACKGROUND

Many different types of mechanical systems include components that are configured to move within the system. For example, in a tape library system (discussed in further detail below), one or more robot arms may be configured to operate along a particular rail. Other examples of components that may be configured to move within a system include doors (which may open and close), storage slots (which may accept and eject storage media), or any other type of component with movable physical parts. Some components may require manual manipulation (i.e., by a human operator) to be moved. Other components may be movable under control of one or more computer processors.

In computer systems, a process may be performed synchronously or asynchronously. In synchronous processing, an execution thread persists throughout the process, from start to finish. All tasks that make up the process are considered a single unit, which either fails or succeeds in its entirety. That is, the persistent execution thread fails and therefore the entire process fails. If the execution thread (the “primary thread”) communicates with another execution thread (a “secondary thread”), the primary thread must wait for a response from the secondary thread before continuing the process.

For example, consider a synchronous process for preparing breakfast cereal, with the individual preparing the breakfast cereal conceptualized as the primary execution thread. The primary thread may prepare the breakfast cereal by performing the following tasks, in sequence: taking a cereal box from a cupboard; taking a milk jug from the refrigerator; taking a bowl from a drawer; taking a spoon from another drawer; pouring cereal from the box into the bowl; pouring milk from the jug into the bowl; placing the spoon into the bowl; returning the cereal box to the cupboard; and returning the milk to the refrigerator. The primary thread may enlist a secondary thread to perform one or more of these steps. For example, the primary thread may ask a secondary thread to fetch the spoon. However, the primary thread cannot perform other tasks while it waits for the secondary thread to complete its task(s). In addition, if any of the tasks fails (for example, if the primary thread spills the milk or the secondary thread fails to locate a spoon), then the entire process fails; the breakfast cereal is not prepared.

In asynchronous processing, two or more tasks within a process are completed independently of each other. For example, one execution thread may perform a subset of the tasks and another execution thread may perform another subset of the tasks. If one execution thread delegates a task to another execution thread, the delegating thread may continue executing even as the delegate performs its task. In the breakfast cereal example above, one thread may pour the milk at the same time that another thread returns the box of cereal to the cupboard. In addition, if an execution thread fails, the process may be able to continue using other execution threads. In the breakfast cereal example above, if one thread fails while attempting to obtain the milk jug, another thread may be able to remedy from the failure. Yet another thread may be able to perform another task (e.g., obtaining a spoon) while the failure is being remedied. In other words, in asynchronous processing, the entire process may not be required to succeed or fail as a unit. Thus, asynchronous processing may improve system reliability by allowing a process to continue even if a particular execution thread fails. Alternatively or in addition, asynchronous processing may allow for faster processing, due to parallelism of multiple execution threads.

DETAILED DESCRIPTION

1. GENERAL OVERVIEW

2. ARCHITECTURAL OVERVIEW AND EXAMPLES

3. SYSTEM MANAGER AND SUBSYSTEMS

4. EXAMPLE DATABASE SCHEMA

5. ASYNCHRONOUS MANAGEMENT OF MOVABLE COMPONENTS

6. MESSAGE HANDLER LIFECYCLE

9. HARDWARE OVERVIEW

10. COMPUTER NETWORKS AND CLOUD NETWORKS

1. General Overview

One or more embodiments, a physical component in a tape library is moved using an asynchronous management process. A request to perform an operation in the tape library is received. The operation includes a physical task to be performed by the physical component. Based on the request, a message handler is initialized. The message handler is executing in an execution thread. State data associated with the physical component is retrieved from persistent storage. Using the state data, a code object representing the physical component is instantiated. Using the message handler and the code object, instructions are transmitted to the physical component to perform the physical task. A process, executing in a different execution thread than the message handler, receives a message from the physical component indicating completion of the physical task. Based on the message, another message handler is initialized that updates persistent storage associated with the physical component. In an embodiment, if a physical component transmits a message indicating a failure of a physical task, a message handler is initialized that performs a remedial action associated with the failure.

2. Architectural Overview and Examples

FIG. 1Aillustrates a system100in accordance with one or more embodiments. As illustrated inFIG. 1A, system100includes a module102that includes a component104and a corresponding controller108. The system100also includes a system manager112and a system client114. In one or more embodiments, the system100may include more or fewer components than the components illustrated inFIG. 1A. The components illustrated inFIG. 1Amay be local to or remote from each other. The components illustrated inFIG. 1Amay be implemented in software and/or hardware. Each component may be distributed over multiple applications and/or machines. Multiple components may be combined into one application and/or machine. Operations described with respect to one component may instead be performed by another component. Additional embodiments and/or examples relating to computer networks are described below in Section10, titled “Computer Networks and Cloud Networks.”

In one embodiment, the module102is a physical unit that includes (i.e., physically within or via a physical connection) at least one component104. The component104is a physical device, the operation of which is adjustable by a servomechanism (not shown). For example, the module102may be a vending machine, an industrial machine (e.g., operating in a production line, farm, or warehouse), a printer (e.g., an ink printer, laser printer, or 3-dimensional printer), a medical or scientific device (e.g., an automated pill sorter or substrate mixer), a vehicle (e.g., a railway car or self-driving automobile), an entertainment device (e.g., an amusement park ride or arcade machine), a household device (e.g., a vacuum cleaner or kitchen appliance), a digital storage device (e.g., a hard drive or storage library), a network switch, or any other kind of physical unit in which the operation of a component104is adjustable by a servomechanism. Those skilled in the art will appreciate that the foregoing list is not exhaustive and is provided merely by way of example.

WhileFIG. 1Aillustrates only one component104, the module102may include more than one component. For example, as discussed below, a storage library may include multiple robotic arms handling the storage devices managed by the storage library. Many different types of modules that include multiple components exist. Further, the module104may be combined with other modules (not shown), and/or the module104may be a combination of multiple sub-modules. For example, a storage library may include more than one inter-compatible storage library modules.

In one embodiment, the controller108is a digital device that helps control operation of the component104. Specifically, the controller108may be configured to apply electrical signals to the component104, to control the velocity, position, direction, and/or other operational properties of the component104. If the module102includes multiple components, each component may be associated with a separate controller. Alternatively or in addition, multiple components may be associated with the same controller, and/or a single component may be associated with multiple controllers.

In one embodiment, the controller108is configured to perform servomechanism operations for the component104. Specifically, the controller108may be configured to receive feedback associated with the component104and, based on the feedback, adjust operation of the component104. The controller108may adjust operation of the component104by applying new electrical signals to the component104and/or modifying electrical signals that are already being applied to the component104.

In one embodiment, the controller108is directly coupled to the component104in a manner that causes the controller108to physically move with the component104. For example, a controller for a robotic arm may be directly connected to the arm itself, so that when the arm moves, the controller is carried along with it. Alternatively, the controller108may be remotely coupled to the component104(e.g., through a network cable) so that the controller108does not move with the component104.

In one embodiment, the system manager112is configured to manage operation of the module102. Specifically, the system manager112may issue instructions to the controller108, which in turn controls operation of the component104based on those instructions. For example, in storage library where the component104is a robotic arm, the system manager112may issue instructions to the controller108to remove a particular storage device. Based on those instructions, the controller108may apply electrical signals to the component104(i.e., the robotic arm in this example) so that the component104moves to the location of the storage device in the module102and removes the storage device. While the system manager112is shown inFIG. 1Aas being separate from the module102, the system manager112may itself be a component of the module102. For example, if the module102is a storage library, the system manager112may be a server housed in the storage library enclosure. In one embodiment, the system manager112and is configured to perform asynchronous management of components (e.g., component104) in the module102. Asynchronous management of components is discussed in further detail below.

In one embodiment, the system manager112receives instructions from a system client114. Specifically, the system client114may be a computing device operating separately from the module102and system manager112, for which the module102provides services. The system client112may be a web server or host, such as a server providing cloud-based services for multiple tenants (not shown). Accordingly, the system client114may have clients of its own, corresponding to the various tenants. In this example, the module102is part of the underlying infrastructure providing cloud-based services for the tenants. Cloud networks are discussed in further detail below. Alternatively or in addition, a system client114may be a tenant system or some other type of end user of the module102. Further, the system100may include multiple system managers, and/or the system100may include multiple system clients communicatively coupled with each system manager.

FIG. 1Bis a block diagram illustrating a module102in accordance with one embodiment. Specifically,FIG. 1Billustrates an abstracted cross-section of a module102in accordance with one embodiment. The module102includes multiple cells120on which components (not shown inFIG. 1B) of the module102are configured to operate. In general, referring toFIG. 1B, the term “cells” may refer to a set of similar physical locations in the module102. For example, if the module102is a vending machine, the cells120may be so-called “columns” corresponding to particular product selections. If the module102is a storage library, the cells120may be slots into which storage media (e.g., drives, disks, cartridges, etc.) are inserted. If the module102is a network switch, the cells120may be physical ports into which cables are inserted. The cells120may not be all of the same type. For example, in a storage library, some of the cells120may be general-purpose storage cells accepting different types of storage media, while others of the cells120may be specific types of storage cells accepting only a particular type of storage media, such as tape cartridges. Many different types of modules exist having different kinds of cells.

In one embodiment, the module102includes components in addition to cells or other than cells. In general, the module102may include many different types of electronic components, such as a power supply, network connection, sensors, display, storage device, service port, and/or any other type of appropriate electronic component depending on the specific type of module102.

For example,FIG. 1Cis a block diagram illustrating a module102in accordance with one embodiment. As illustrated inFIG. 1C, the module102includes two components104,106operating along a top rail124and a bottom rail126. As used here, the terms “top” and “bottom” are used to differentiate between the rails and may not accurately denote the vertical configuration of the top rail124and bottom rail126relative to each other. For example, the top rail124and bottom rail126may be on a same horizontal plane as each other, withFIG. 1Crepresenting an overhead view of the module102. Many different physical rail configurations may be used. Further, the module102may not include any rails, may include more than two rails, or may include only a single rail.

In one embodiment, component104has a hand128and component106has a hand130. The hands128,130are physical mechanisms used to manipulate other components and/or items in the module102. For example, the hands128,130may be used to manipulate items placed in cells in the module102, such as the cells120illustrated inFIG. 1B. In one embodiment, the components104,106are configured to follow one axis (e.g., horizontally) along the top rail124and bottom rail126, while the hands128,130are configured to follow another axis (e.g., vertically) along the components104,106. In this manner, the hands128,130may be able to reach many different locations within the module102. Further, if the module102has more than one rail, a component may have more than one motor (not shown), with each motor affecting movement of the component along the corresponding rail. In an embodiment, rails in multiple modules and/or sub-modules may be connected, allowing one or more components to move between the modules and/or sub-modules. For example, in a tape library system, robot arms may be able to move from one tape library module to another tape library module, along one or more interconnected rails.

In one embodiment, each of the components104,106has a corresponding controller108,110. Each controller is configured to apply electrical signals to its corresponding component, to control movement of the component within the module102. As illustrated inFIG. 1C, each controller108,110may be directly connected to its corresponding component104,106, so that when the component travels along the top rail124and bottom rail126, the corresponding controller moves along with it. Alternatively, one or more of the controllers108,110may be remotely connected to its corresponding component, so the controller does not move with the component.

FIG. 1Dis a block diagram illustrating a controller108in accordance with one or more embodiments. The controller108is configured to control the operation of a component (not shown) in a module (not shown). The controller108may be a logic board, server, or any other type of computing structure or device suitable to perform controller operations described herein.

In one embodiment, the controller108includes one or more processors. As illustrated inFIG. 1D, the controller108includes two processors; processor146and processor148. Each processor146,148operates using a corresponding instruction set. Specifically, processor146uses instruction set150, and processor148uses instruction set152. The processors146,148may be of the same type or may be of different types. For example, processor146may use a general purpose instruction set150and processor148may use a specialized instruction set152. In one embodiment, the specialized instruction set152includes floating point operations that allow processor148to perform mathematical functions for a servomechanism more rapidly than processor146would be able to perform those same mathematical functions using the general purpose instruction set150. For example, a general-purpose processor may be an Advanced RISC Machines (ARM) processor based on the Reduced Instruction Set Computer (RISC) design and the other processor may be a Digital Signal Processing (DSP) processor optimized for digital signal processing including floating point operations. Specifically, the DSP processor may be optimized for measuring, filtering, and/or compressing digital or analog signals, which may involve performing complex mathematical calculations. Performing those calculations quickly may help avoid performance concerns associated with latency and/or offload mathematical calculations from the general purpose processor. The DSP processor may also include fewer transistors and/or use less power than the general-purpose processor. In one embodiment, a general-purpose processor executes instructions relating to high-level commands and general system operations, while a specialized processor handles complex mathematical functions.

In one embodiment, the controller108also includes one or more non-transitory computer readable media, such as memory140and/or some other type of medium, for storing instructions and/or data used by the one or more processors146,148to perform servomechanism operations. The one or more computer readable media may include executable instructions corresponding to one or more operating systems used by the processor(s), such as a LINUX operating system and/or a reduced kernel of an operating system.

In one embodiment, the controller108receives feedback about the operation of the component. The feedback may be used as input to servomechanism operations. For example, the controller108may receive feedback from one or more off-board sensors132. As used here, the term “off-board” means that an off-board sensor132is communicatively coupled with the controller108but is not part of the controller108itself. For example, the off-board sensor132may be a sensor physically attached or communicating with the component, such as a thermometer, tachometer, tilt sensor, current sensor, or any other kind of sensor configured to receive feedback about the operation of the component and provide the feedback to the controller108.

Alternatively or in addition, the controller108may include one or more on-board sensors138. As used here, the term “on-board” means that the on-board sensor138is part of the controller108itself. For example, if the controller108is a logic board, the on-board sensor138may be attached to the same logic board. The on-board sensor138may be a thermometer, tachometer, tilt sensor, current sensor, or any other kind of sensor configured to receive feedback about the operation of the component.

In one embodiment, the controller108is configured to apply electrical signals to the component, to modify the component's operation. For example, the controller108may include a motor driver144configured to transmit electrical signals to a motor134that causes the component to move. The particular electrical signals transmitted from the motor driver144to the motor134may help determine how the component moves (i.e., direction, speed, etc.). Further, the component may include more than one motor134, and a combination of electrical signals to the various motors may help determine how the component moves. A motor driver144may be configured to transmit electrical signals to a single motor134, or to multiple motors. For a component with more than one motor (for example, a component operating along more than one rail), more than one motor driver may be used.

In an embodiment, the controller108uses a motor134and off-board sensor132to perform servomechanism functions as follows. One or more processes executed by the controller108apply a voltage and/or current to a motor134. An off-board sensor132(e.g., an encoder) provides feedback about the actual motion of the motor134. The controller108uses the feedback to adjust the voltage and/or current applied to the motor134. Adjusting the voltage and/or current in response to the feedback allows the controller108to achieve (or more closely approximate) the desired motion of the component being moved by the motor134.

In one embodiment, the controller108is configured to control and receive feedback from various parts of the component, some of which may not be related to servomechanism operations. For example, the controller108may be configured to transmit electrical signals to, and receive electrical signals from, a bar code scanner136. The bar code scanner136may be configured to read bar codes of items manipulated by the component within a module. For example, a hand128as illustrated inFIG. 1Cmay include a bar code reader. The bar code reader may be used to identify items stored in cells120as illustrated inFIG. 1B.

FIG. 1Eis an illustration of a tape library system154in accordance with one embodiment. In this example, the tape library system154includes two modules: module156and module158. The modules are connected along a vertical edge to form a single, modular unit. An upper rail164and lower rail166run the horizontal length of the tape library system154, allowing a component162to access storage cells160. Each of the storage cells160may be configured to accept tape drives and/or other storage media, as discussed above. InFIG. 1E, the storage cells160run the length of the tape library system154in both the front and back. The component162is a robot arm connected to the upper rail164and lower rail166, allowing the component162to move along the rail under power of one or more motors. The component162also includes a robot hand, which moves vertically along the robot arm to access storage cells160at different heights in the tape library system154. In one embodiment, the tape library system154includes more than one robot arm (not shown).

3. System Manager and Subsystems

FIG. 2illustrates a system200in accordance with one or more embodiments. As illustrated inFIG. 2, the system200includes a system manager202with a system interface204, a state database214, and one or more subsystems, such as a scheduling subsystem208, component subsystem210, and data access subsystem212. Each subsystem may have multiple subcomponents. In one or more embodiments, the system200may include more or fewer components than the components illustrated inFIG. 2. The components illustrated inFIG. 2may be local to or remote from each other. The components illustrated inFIG. 2may be implemented in software and/or hardware. Each component may be distributed over multiple applications and/or machines. Multiple components may be combined into one application and/or machine. Operations described with respect to one component may instead be performed by another component. Additional embodiments and/or examples relating to computer networks are described below in Section10, titled “Computer Networks and Cloud Networks.”

In an embodiment, the system manager202is configured to perform asynchronous management of physical components. Specifically, the system manager202may correspond to the system manager112illustrated inFIG. 1Aand may perform asynchronous management of one or more components in a module102as illustrated inFIG. 1A. Asynchronous management of physical components is discussed in further detail below.

In an embodiment, the system manager202is part of a distributed system. Specifically, one or more of the subsystems described below may be implemented using multiple execution threads, which may be executing on different processors. Two or more of the processors may be located in different computer systems. For example, the system manager202and/or components thereof may be implemented as a computing cluster that includes multiple computer systems, each having one or more processors executing therein. In particular, a computing cluster may be used to distribute parts of an asynchronous management process across multiple processors executing in multiple computer systems. Two or more different message handlers, described below, may execute in two or more different execution threads. Thus, a computing cluster may help provide for increased processing power and/or system redundancy associated with asynchronous processing.

In an embodiment, the subsystems of the system manager202use message handlers to manage one or more tasks associated with operations. For the purposes of this discussion, a “task” is part of an operation and not the operation in its entirety. In other words, an operation involves multiple tasks to be performed as part of the operation. For example, an operation may involve tasks that must be performed in a particular order, tasks that may be performed concurrently, or a combination thereof. A message handler is a unit of instructions that execute in an execution thread to perform a particular task as part of an operation. In addition, a message handler may invoke additional message handlers to perform subtasks of a task.

In an embodiment, the sequence of events leading from a message handler being asked to perform a task to when it terminates may be referred to as its “lifecycle.” A message handler may have a lifecycle that lasts as long as necessary to receive a message and perform a task based on the message. A message handler may be created and added to a pool of message handlers in a ready state, waiting to process a message. Messages may be received in a queue and assigned to appropriate message handlers. When a message is assigned to a message handler, the message handler performs a task based on the message and then is terminated. For example, a message handler may be implemented as a Java Message-Driven Bean (“MDB”) using the Java Platform, Enterprise Edition (“Java EE”). The system manager202may include an Enterprise JavaBeans™ (“EJB”) server that supplies one or more EJB containers. One or more named Java Messaging Service (“JMS”) queues in an EJB container may receive messages and assign them to the appropriate MDB's. In addition to MDB's, session EJB's and/or entity EJB's may be used.

In an embodiment, the system manager202includes a system interface204, through which the system manager202receives requests for operations. The system interface204may be any type of interface through which the system manager202receives requests from one or more system clients, such as the system client114illustrated inFIG. 1A. For example, the system interface204may be a representational state transfer (“REST”) interface. Those skilled in the art will appreciate that there are many different types of interface that a client may use to communicate requests to a system. In an embodiment, the system interface204is configured to authenticate requests, to ensure that only authorized client(s) are permitted to requests operations to be managed by the system manager202.

In an embodiment, an operation may involve one or more physical tasks to be performed by one or more components. For example, in a tape library system, the system interface204may receive requests to manipulate tape cartridges. Manipulating a tape cartridge requires a robot arm to perform one or more physical tasks, such as moving to a particular location in tape library system and using its hand to manipulate the tape cartridge. Moving to a location and manipulating the cartridge may be considered different physical tasks. In an embodiment, a request to perform an operation, received via the system interface204, is a relatively high-level request and the system manager202determines which physical task(s) are needed to satisfy the request. A physical task may involve multiple subtasks.

In an embodiment, the system manager202includes a scheduling subsystem208. The scheduling subsystem208is configured to determine an order in which to perform the operations (e.g., operations requested via the system interface204). The scheduling subsystem208may also be responsible for maintaining the state of resources in the system and allocating those resources to tasks. Resources allocated by the scheduling subsystem208may include any type of resource implemented in hardware and/or software, including physical components, as described herein. The scheduling subsystem208may use a reservation-based approach for managing requests and allocating resources. Reservation-based approaches are described in further detail in U.S. patent application Ser. No. 15/665,344, titled “Reservation-Based Management of Movable Components,” referenced above. In an embodiment, the scheduling subsystem208uses message handlers to manage tasks asynchronously, as described in further detail below. The scheduling subsystem208may track the status of an operation using state data in a state database214. Specifically, message handlers operating in the scheduling subsystem208may store and retrieve state data in the state database214via a data access subsystem212of the system manager202.

In an embodiment, the scheduling subsystem208uses different types of message handlers to handle different types of tasks. For example, scheduling message handlers218may receive messages when operations and/or tasks are requested or when operations and/or tasks are completed. Specifically, a scheduling message handler218may examine the state of the system and a queue of pending operations and/or tasks, to determine whether the necessary resources are available. The scheduling message handler218may implement a reservation-based approach as discussed above. If the necessary resources are available, then the scheduling message handler218may send a message to a runner message handler220and then terminate. Runner message handlers220may be responsible for initiating the processing of an operation or task. Initiating the processing of an operation or task may involve, for example, dividing an operation into tasks, dividing a task into subtasks, and/or transmitting requests to components to perform physical tasks. Runner message handlers220may also be able to mark an operation or task to be cancelled, query the status of an operation or task, determine whether an operation or task needs resources, etc. Upon initiating the processing of an operation, a runner message handler220may terminate. Component response message handlers222may receive messages from components and pass the messages to one or more appropriate scheduling message handlers218for further processing. Upon passing a message to an appropriate scheduling message handler218, a component message handler222may terminate.

In an embodiment, in addition to scheduling message handlers218, runner message handlers220, and/or component response message handlers222, the scheduling subsystem208includes other message handlers and/or other types of instructions for managing the flow of operations and/or tasks. For example, in a Java EE framework, an MDB may allocate work to a stateless session bean. As another example, the system manager202may be implemented using object-oriented techniques. Components of the system manager202may use various classes, instantiate objects of those classes, then invoke methods in those objects. For example, the scheduling subsystem208may maintain classes that correspond to different types of tasks and that are instantiated as task objects216, as part of performing those tasks. In a tape library system, different classes may correspond to physical tasks performed by robots, such as “move to a specific position,” “fetch a data cartridge from a location,” and “put a data cartridge to a location.” Each type of task may implement a superclass providing abstract or general task functionality. For example, the superclass may include one or more methods for allocating resources needed by tasks. A method may invoke other classes and/or message handlers. In an embodiment, the system manager202manages the state of objects, including task objects216and/or objects that represent physical components as described below, using state data in the state database214. Many different configurations of message handlers, object classes, and/or other types of instructions may be used.

In an embodiment, the system manager202includes a component subsystem210. The component subsystem210provides an interface for the system manager202to communicate with physical components (not shown inFIG. 2). Specifically, component request message handlers224may handle requests to the component subsystem210. The component request message handlers224may manage physical components using component objects228, where instructions implemented by each component object228are translated to instructions, corresponding to physical tasks, to be sent to the associated physical component(s). To instantiate a component object228, the component subsystem210may retrieve the state of the corresponding component from the state database214, via the data access subsystem212.

For example, in a tape library system, the component subsystem210may represent a physical robot as an instance of a robot class. Methods of the robot class may correspond to physical tasks to be performed by the robot. When a “move” method of a robot object is invoked, the component subsystem210may transmit instructions to the associated robot to move in a manner indicated by arguments supplied to the method. When a physical task completes, the component subsystem210may transmit a message to the scheduling subsystem208. The message may indicate whether the physical task succeeded or failed. The message may be received in a message queue and dispatched to a message handler, such as a component response message handler222as described above.

As discussed above, in an embodiment, the system manager202includes a data access subsystem212. The data access subsystem212may be used by other subsystems of the system manager202to store and retrieve data in a state database214. For example, the state database214may store state data indicating the states of particular operations and/or tasks within operations. As another example, the state database may store data indicating the states of particular physical components. Many different types of state data may be stored in the state database214. An example of a database schema for storing state data is discussed below.

In one embodiment, the state database214is any type of storage unit and/or device (e.g., a file system, database, collection of tables, or any other storage mechanism) for storing data. Further, the state database214may include multiple different storage units and/or devices. The multiple different storage units and/or devices may or may not be of the same type or located at the same physical site. Further, the state database214may be implemented or may execute on the same computing system as one or more other components illustrated inFIG. 2. Alternatively or additionally, the state database214may be implemented or executed on a computing system separate from one or more components illustrated inFIG. 2. The state database214may be communicatively coupled to other components illustrated inFIG. 2via a direct connection or via a network.

In one embodiment, elements of the system200, such as the system interface204, system manager202, scheduling subsystem208, component subsystem210, data access subsystem213, and/or state database214, are implemented on one or more digital devices. The term “digital device” generally refers to any hardware device that includes a processor. A digital device may refer to a physical device executing an application or a virtual machine. Examples of digital devices include a computer, a tablet, a laptop, a desktop, a netbook, a server, a web server, a network policy server, a proxy server, a generic machine, a function-specific hardware device, a hardware router, a hardware switch, a hardware firewall, a hardware firewall, a hardware network address translator (NAT), a hardware load balancer, a mainframe, a television, a content receiver, a set-top box, a printer, a mobile handset, a smartphone, a personal digital assistant (“PDA”), a wireless receiver and/or transmitter, a base station, a communication management device, a router, a switch, a controller, an access point, and/or a client device.

4. Example Database Schema

FIG. 3illustrates an example of a database schema300in accordance with an embodiment. A database schema300may include more or fewer components than those illustrated inFIG. 3. For example the database schema300illustrated inFIG. 3may be a subset of a larger database schema. Alternatively or in addition, components of a database schema may be related to each other in different ways than the example illustrated inFIG. 3. The database schema300illustrated inFIG. 3and discussed here is provided for exemplary purposes only and should not be construed as limiting one or more embodiments.

In the example illustrated inFIG. 3, the database schema300is for a database used to manage state data for a tape library system. As used here, the word “job” refers to an operation, task, or subtask, and the word “device” refers to a physical component in the tape library system. As illustrated in the database schema300, a particular JOB may have zero or more JOB_PARAMETERs, zero or more child JOBs (e.g., subtasks) and zero or more allocable RESOURCEs. Three different types of resources are shown here: DEVICE_RESOURCEs, RAIL_SEGMENT_RESOURCEs; and CELL_RESOURCEs. Other types of resources may be used. A particular RAIL_SEGMENT_RESOURCE includes a start location of a rail segment, measured in this example in mils (thousands of an inch) and an end location of the rail segment, also measured in mils. A particular DEVICE corresponds to a physical component in the tape library system, such as a tape drive, a robot, a controller card, or any other type of physical component. A particular CELL is a physical location where a cartridge may be placed, and is located within a particular DEVICE, such as a magazine. A particular DEVICE may have zero or more CELLs.

5. Asynchronous Management of Movable Devices

In one embodiment, movable physical components are managed using one or more asynchronous processes. Specifically, to perform an operation, asynchronous message handlers may be used.FIGS. 4A and 4Billustrate an example set of operations for asynchronous management of movable components in accordance with one or more embodiments. One or more operations illustrated inFIGS. 4A and 4Bmay be modified, rearranged, or omitted all together. Accordingly, the particular sequence of operations illustrated inFIGS. 4A and 4Bshould not be construed as limiting the scope of one or more embodiments. Further, in the following discussion, a system manager is referred to as performing various functions. Specifically, the system manager may use various subsystems as described above. However, in an embodiment, one or more of the operations described below are instead performed by one or more other system components. For example, one or more operations may be performed by a controller card.

In an embodiment, the system controller receives a request to perform an operation (Operation402). The request may correspond to a relatively high-level request, such as a request to move a tape to a particular tape drive. The system manager may be responsible for breaking the operation into multiple tasks.

In an embodiment, the system controller initializes a message handler based on the request (Operation404). Initializing the message handler may involve creating the message handler. For example, in an object-oriented framework, a message handler may be created by instantiating an object based on a message handler class. Alternatively, a message handler may already have been created (e.g., instantiated) and may be waiting in a ready state. Initializing the message handler may involve invoking functionality of the message handler. For example, initializing the message handler may involve calling a method of the message handler to bring it out of a ready state.

For example, the system controller may dispatch the message to a scheduling message handler as described above. One or more of the operations described below may be performed by this message handler, executing in an execution thread. Alternatively or in addition, the message handler may invoke another message handler and/or another type of instructions to perform operations. For example, the message handler may invoke another message handler and then terminate. The message handler may invoke multiple message handlers corresponding to multiple subtasks. Examples of message handlers and other types instructions, in accordance with one or more embodiments, are described above and below.

In an embodiment, the system manager determines whether the resource(s) needed to perform the operation are available (Operation406). If one or more resources needed are not available, then the system manager queues the request (Operation408). The operation may resume when the necessary resources become available.

In an embodiment, the system manager retrieves state data associated with a physical component (Operation410). Specifically, the state data may be associated with a physical component that the system manager will attempt to use to perform a physical task as part of the operation. The system manager may instantiate an object representing the physical component (Operation412).

In an embodiment, the system manager transmits instructions to the physical component to perform a physical task (Operation414). Specifically, the system manager may use an object representing the physical component (e.g. as discussed with reference to Operation412) to transmit the instructions to the physical component. For example, the system manager may invoke a method of the object, which is translated into instructions transmitted to the physical component. In an embodiment, the instructions are transmitted using a message handler. For example, a message handler may call a method of an object representing the physical component. The message handler may be a different message handler than the one discussed above with respect to Operation404. For example, the message handler initialized in Operation404may be a scheduling message handler, and the message handler used to transmit instructions to the physical component may be a component request message handler, as discussed above. When multiple message handlers are involved in an operation, the message handlers may execute in the same execution thread or in different execution threads.

In an embodiment, the system manager receives a message from the physical component (416) to which the instructions were transmitted in Operation414. The message may indicate that the physical task completed successfully. Alternatively, the message may indicate that the physical task failed to complete successfully. In an embodiment, when instructions are transmitted to a component, the system manager starts a timer, indicating a maximum allowable time for the physical task to complete. A monitoring process determines whether a message has been received from the physical component before the timer expires. If the timer expires before a message is received from the component, the monitoring process may transmit a message indicating an error condition.

In an embodiment, the system manager initializes a message handler based on the message from the component (Operation418). Alternatively the system manager may initialize a message handler based on a message from a monitoring service, as described above. For example, the system manager may initialize a component response message handler, as discussed above. In an embodiment, the system manager determines whether the task was successful (Operation240). Determining whether the task was successful may involve processing the message, by the message handler, to determine whether the contents of the message indicate success or failure.

In an embodiment, if the task was not successful, then the system manager may take remedial action (Operation424). Taking remedial action may involve reattempting the physical task. The physical task may be reattempted using the same physical component or a different physical component. For example, in a tape library system with two or more robots, if one robot fails to complete a task, the system manager may transmit instructions to another robot to reattempt the task. Alternatively or in addition, taking remedial action may involve attempting to restart or reset a physical component to an operable state. Restarting or resetting a physical component may be performed using message handlers, as described above. Specifically, a request to restart or reset a physical component may be treated by a high priority request by the scheduling subsystem. For example, operations and/or tasks may be assigned priorities on a numerical scale, with 1 being low priority and 10 being high priority. While a typical task may be assigned a medium (e.g., 5) or low priority, resetting or restarting a component may be assigned a high priority.

In an embodiment, if the task is successful, then the system manager updates state data (Operation422). Specifically, the system manager may update state data associated with an operation, state data associated with a task, state data associated with a component, or any combination thereof. The system manager may update state data associated with an operation, task, and/or subtask at various times. States that may be used include, for example: cancelled, completed, completed with error, needs resources, running, running and waiting for component response, running and waiting for subtask, runnable, or any other type of state representing the status of an operation, task, and/or subtask.

6. Message Handler Lifecycle

In an embodiment, one or more of the operations describe above with respect toFIG. 4may be performed using message handlers. If a message handler fails, the system manager may attempt to take remedial action using a different message handler.FIG. 5illustrates an example set of operations corresponding to a message handler lifecycle in accordance with one or more embodiments. One or more operations illustrated inFIG. 5may be modified, rearranged, or omitted all together. Accordingly, the particular sequence of operations illustrated inFIG. 5should not be construed as limiting the scope of one or more embodiments.

In an embodiment, a message handler is initialized (Operation502) based on a message. For example, a message may be received in a message queue and dispatched to the message handler. As discussed above, initializing the message handler may involve creating (e.g., instantiating) the message handler. Alternatively, initializing the message handler may involve moving the message handler from a ready state to a message-handling state.

In an embodiment, the message handler attempts to perform a task based on the message (Operation504). Specifically, the message handler may execute instructions corresponding to handle the message according to business logic implemented in the message handler. All of the instructions may be part of the message handler itself. Alternatively, the message handler may invoke other instructions to handle the message. The instructions may involve transmitting a message to be handled by a different message handler.

In an embodiment, a determination is made whether the message handler failed (Operation506). The determination may be made by the system manager. Specifically, the system manager may monitor the statuses of message handlers and determine whether an execution thread, corresponding to a message handler, terminates unexpectedly or with an error condition. For example, in an object-oriented framework, a message handler may throw an exception.

In an embodiment, if the message handler has failed, then the system manager rolls back changes made by the message handler (Operation510). Rolling back changes may involve not committing changes to a state database. Alternatively or in addition, rolling back changes may involve reverting one or more records in a state database to an earlier state. The system manager may then initialize a different message handler (returning to Operation502). Specifically, the system manager may initialize a new message handler to handle the same message that the previous message handler failed to handle successfully. The new message handler may be executing in a different thread than the previous message handler. For example, the previous message handler may have been executing in a thread on a particular processor, and that processor may have crashed, been taken offline, or otherwise failed. The new message handler may be executing in a different thread, on a different processor that was not impacted by the failure. Thus, reattempting the task using a new message handler may provide redundancy and allow the system manager to quickly recover from a failure without terminating the entire operation associated with the task.

In an embodiment, if the message handler has not failed, then the message handler terminates normally (Operation508). Specifically, the message handler may terminate once it has completed the particular task that was dispatched to it.

FIGS. 6A and 6Billustrates an example of asynchronous management of movable components in accordance with one embodiment. In this example,FIG. 6Aillustrates a simplified processing flow600, executed by a system manager, corresponding to an operation in a tape library system.FIG. 6Billustrates state data602associated with the operation. The state data is organized according to a database schema similar to the example of a database schema described above. The following discussion ofFIGS. 6A and 6Bis provided for exemplary purposes only and should not be construed as limiting one or more embodiments.

InFIG. 6A, different types of communication are represented using different types of lines. A heavy solid line represents a message to be handled by a message handler. A thin dashed line represents a method invocation. A heavy dashed line represents a network communication. Many different types of communication may be used and the specific types of communications illustrated inFIG. 6Ashould not be construed as limiting one or more embodiments. Further, in this example, the term “job” may refer to an operation, task, or subtask, and the term “device” corresponds to a physical component. For ease of reference, in this example, the term “message handler” is abbreviated as “MH.”

In this example, referring first toFIG. 6A, an operation starts with a request from a system client604to a system interface606, over a network connection. The request may be received via a graphical user interface (GUI), Small Computer System Interface (SCSI) connection, web service (e.g., a REST interface), or any other type of system interface606. Specifically, in this example, the request is to move a cartridge in the tape library system. The request invokes a moveCartridge method in the system interface606, which creates a top-level job and stores the top-level job in the state database. The moveCartridge method also transmits a message to the scheduling queue608to try to start the job.

When the message is processed in the scheduling queue608, a scheduling MH610is initialized to handle the message. The scheduling MH610determines which resources are needed to complete the job. In addition, the scheduling MH610queries the state database to obtain a list of any other jobs that require those resources. The list is ordered by job priority and, within each priority level, by time (first in, first out). For each job in the list, the scheduling MH610calls the job's allocateResources method. Specifically, each type of job (such as top-level move614, fetch618, and put616) inherits the allocateResources method from an abstract task612. For a particular job, if the allocateResources method returns false, the job remains in the backlog. If the allocateResources method returns true, the job can be performed using the allocated resources. The scheduling MH610updates the job to a runnable state and sends a message to the runner queue622.

When a message in the runner queue622is processed, a runner MH624is initialized. The runner MH624determines the type of message and the job to which the message applies. The runner MH624queries the state database for state data associated with the job and instantiates an object representing the job. The runner MH624then calls a startJob method of the job object. For a top-level move614, the startJob method will instantiate a fetch618. The startJob method stores the fetch job in the state database and sends a message to the scheduling queue to schedule the new job (i.e., the fetch, which is a subtask or child task of the top-level move).

The scheduling process repeats for the fetch. When the allocateResources method is called, the fetch618selects a robot and allocates both the robot and a rail segment needed to move the robot. When a runner message is processed for the fetch, a fetch job's startJob method will send a message for the robot to perform the fetch (i.e., the physical task of fetching the cartridge) to the component request queue626. The fetch job also updates the state database to indicate that it is waiting for a response from the robot, and to indicate that the robot's state is “fetching.”

When the message is processed in the component request queue626, a component request MH628is initialized. Based on the message, the component request MH628transmits instructions to the component630(i.e., the robot), via an internal network, to perform the physical task of fetching the cartridge. In an embodiment, using a component request queue626and component request MH628means that if a rollback is needed for the job as a whole, the message to the component request queue626is also rolled back and no instructions are transmitted to the component630.

The robot performs the physical task of fetching the cartridge. When the task is complete, the robot sends a response to a component web service632. The component web service632creates a message based on the response and transmits the message to the runner queue622. When the message is processed in the runner queue622, a runner MH624is initialized. The runner MH624initialized here is different than the one initialized previously, which may have terminated by this time. Based on the message, the runner MH624queries the state database to obtain state data associated with the fetch job, and instantiates a fetch object. The fetch object instantiated here is different from the fetch object instantiated above. The runner MH624calls the deviceResponse method of the fetch object, passing in the response received from the robot. Because the task completed successfully, the fetch object updates the state database to reflect that the fetch is complete and that the robot is inactive. The fetch object transmits a message to the runner queue624, indicating to the top-level move that the fetch is complete.

When the message is processed in the runner queue624, a runner MH624is initialized. The runner MH624instantiates a top-level move object, using state data from the state database. The runner MH624calls a childComplete method of the top-level move object. The top-level move object then creates a new “put” job, stores the corresponding state data in the state database, and sends a message to the scheduling queue608to handle the put job. The process described above with respect to the fetch job is then repeated, mutatis mutandis, for the put job. When the put job is complete, the move operation as a whole is complete.

FIG. 6Billustrates an example of state data602, corresponding to the example operations described above. Through the course of this example, three jobs are created in the JOB table: a TOP_LEVEL_MOVE, a FETCH, and a PUT. In the JOB_PARAMETERs table, the TOP_LEVEL_MOVE has two parameters: a SOURCE and a DESTINATION. These parameters correspond to the IDs of cells in the tape library system, recorded in the CELL table. In the RESOURCE table, these cells are allocated to the top-level move. A rail segment is not allocated for the top-level move. The FETCH has one parameter: the source cell from which to fetch the cartridge. This cell is allocated to the FETCH in the RESOURCE table, along with a robot and a rail segment. In an embodiment, a child task is allowed to allocate resources that are already allocated to its parent operation or task. However, allocation of resources in the RESOURCE table prevents the same resource from being allocated for a different operation.FIG. 6Brepresents a state where the FETCH has already completed, as shown in the RESOURCE_STATE column of the RESOURCE table. Alternatively, a resource record may be deleted from the RESOURCE table when a task is complete.FIG. 6Bsimilarly shows parameters and resources corresponding to the PUT, and a state (ALLOCATED) of those resources.

In an embodiment, storing state data in a state database helps facilitate asynchronous management of movable components. Specifically, message handlers may use the state database to store and retrieve state data associated with operations, components, and/or other resources in the system. Thus, each message handler may be able to determine the current state and act on that state, even though the message handlers may be executing in different threads, on different processors, and even in different computer systems. For example, a state database may help facilitate asynchronous management of movable components using a computing cluster.

9. Hardware Overview

Computer system700further includes a read only memory (ROM)708or other static storage device coupled to bus702for storing static information and instructions for processor704. A storage device710, such as a magnetic disk or optical disk, is provided and coupled to bus702for storing information and instructions.

10. Computer Networks and Cloud Networks