Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method for uniquely identifying event records and guaranteeing their delivery to remote targets

IP.com Disclosure Number: IPCOM000190313D
Original Publication Date: 2009-Nov-23
Included in the Prior Art Database: 2009-Nov-23
Document File: 3 page(s) / 32K

Publishing Venue

IBM

Abstract

This article describes the unique way of identifying the events, storing them to the secondary storage and processing them efficiently for delivery.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 3

Method for uniquely identifying event records and guaranteeing their delivery to remote targets

Disclosed is the method for uniquely identifying the events, storing them to the secondary storage and processing them efficiently for delivery in event model. Event model refers to a client interested in a particular event subscribes to the running Server on a particular managed system. A resource monitor as part of Server or a module that is shipped with Server on a particular system monitors the resource as requested by client. Whenever event is generated, server evaluates the event, verifies if it meets the requirements imposed by the client and delivers matched events. When client creates the subscription for the event, it specifies the evaluation criteria and destination to which the event must be sent. Destination or listener may be the client who creates the subscription or may be different.

Listener wants to receive all events it requested (or client might have requested on behalf of this) without loosing them. It is possible that because of network outages events cannot be delivered. Server detects this scenario and attempts delivery retry of events. It is possible that many events are generated and are lined up for delivery to the same listener. Server must guarantee that all events generated from resource monitor will be delivered in same order to the listener and events shall not be lost. An event object does not have any unique identifier to exactly identify the particular event. Because of primary memory constraint, server can not hold all events in the memory. A better solution is required where a server stores the event objects in secondary store and sends to the listener which also solves the problem of loosing indications during server crash. Delivery retry of the event by Server is controlled a user configured parameter which defines how many times an event can be retried for delivery before discarding it.

Proposed solution

Because event objects does not have any unique identifier, there is a need to have mechanism to generate unique identifiers for the event objects. Even if the event objects have unique identifier a better mechanism is needed to access the objects from secondary store. There might be many destinations Server that are trying to deliver the events. If there are 'n' destinations not all destinations may be reachable. Proposed solution is based on destination which can be either hostname or IP address.

Algorithm

Two variables are defined to hold identifier to be named for next event object and event object being attempted to deliver by the server

CurrentIdentifier = 1 or <any other initial value RetryIdentifier = 1 or

1

Page 2 of 3

Assigning unique identifier


1. New event object received by server.
2. Normalize the event object to the secondary store using name DestinationName

_$( CurrentIdentifier). Can be stored as file or any database.

3. set CurrentIdentifie...