Browse Prior Art Database

Managing and Operating on Server States from a Stateless Distributed Application

IP.com Disclosure Number: IPCOM000019775D
Original Publication Date: 2003-Sep-29
Included in the Prior Art Database: 2003-Sep-29
Document File: 2 page(s) / 51K

Publishing Venue

IBM

Abstract

Our goal is to determine an overall "global" state for several subcomponent servers. Then we can let the user perform global operations that depend on that state. The difficulty is that we have a stateless system in the portlets that manage the servers, so we don't know what the last request to the servers was. We also allow users to interact with the servers via a command line, or through multiple portlets at the same time, so there could be things going on that we don't have control of from the portlet. Therefore we need to be able to determine the global state from the current states of the servers alone.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 49% of the total text.

Page 1 of 2

Managing and Operating on Server States from a Stateless Distributed Application

Here is the state transition diagram for the IBM Intelligent Notification Server (INS):

     INS is composed of several different types of subcomponent servers, and there may be multiple instances of some of the servers. Our goal was to determine an overall global state for the INS subcomponent servers. Once we have that we can let the user perform global operations that depend on that state. For example, you can start all of the servers if they're stopped, or pause them if they're running. It doesn't make sense to pause servers that are stopped. Also, we don't want users to do things at the level of individual servers because there are many rules about the order you have to start/stop the servers. (Throughout this article, when we refer to start/stop, we mean all of the server operations including pause/configure/initialize/force-stop as well).

     The difficulty is that we have a stateless system in the portlets that manage the servers, so we don't know what the last request to the servers was. We also allow users to interact with the servers via a command line, or through multiple portlets at the same time, so there could be things going on that we don't have control of from the portlet. Therefore we need to be able to determine the global state from the current states of the servers alone.

     We took all of the possible combinations of server states and summarized them into a small set of global states. INS is a distributed system, so we have to be able to deal with cases where some of the servers cannot be reached to get their current state, as well as servers that are in an unexpected/illegal state. There are also transition states to deal with, some of which can indicate that the servers may be in more than one global state if they are taken out of context (for example, the servers may be "configuring" because they are "starting" or because they are "re-configuring").

     The administration server that the INS Manage Servers portlet uses does not maintain server states between requests. The portlet requests the server states every time it needs to display them. When the administration server returns the server states, it also returns an overall global server state (see below for how that state is determined). The portlet maps that global state to a set of operations that are legal from

1

[This page contains 1 picture or other non-text object]

Page 2 of 2

that state, and presents those options to the user. When the user requests an operation from the portlet, it forwards the request to the administration server. The administration server can ignore illegal requests, and processes legal ones (to handle concurrency issues). An illegal request is likely because a portlet instance could be operating on stale server status information. For example, a user could display server status, take a break, and upon return instigate an action on the server based on the old se...