Event Queuing and Distribution System

• US 20120278473A1
• Filed: 04/27/2011
• Published: 11/01/2012
• Est. Priority Date: 04/27/2011
• Status: Active Grant

• Current Assignee: Rackspace US Incorporated (Apollo Global Management, Inc.)
• Original Assignee: Rackspace US Incorporated (Apollo Global Management, Inc.)
• Inventors: Griffiths, Kurt Evan
• Granted Patent: US 8,751,639 B2
• Time in Patent Office: Days
• US Class Current: 709/224
• CPC Class Codes: G06F 16/182 Distributed file systems
• CPC Class Codes: G06F 2209/548 Queue
• CPC Class Codes: G06F 9/542 Event management; Broadcasting; Multicasting; Notifications
• CPC Class Codes: H04L 67/141 Setup of application sessions admission control or resource allocation in data switching networks H04L47/70

Abstract

A REST-based event distribution system is described, with particular applicability to the distribution of distributed filesystem notifications over a high-latency best-effort network such as the Internet. In one embodiment, event channels are mapped to URL spaces and created and distributed through the use of HTTP POST and GET requests. The system is optimized for short polling by clients; an event history is maintained to buffer messages and maintain the idempotence of requests. In another embodiment, the events are registered as a SIP event pack allowing for the distribution of filesystem events.

Claims

1. An event distribution system, the system comprising:

a server configured to respond to event requests via a synchronous client-server protocol, the server further including;

a backing store configured to store an event associated with a first channel identifier and to allow subsequent retrieval of the event using the same channel identifier;

a communications module operable to receive event requests and send responses;

an event filtering system operable to evaluate, modify, and block event requests and responses; and

an event manager coordinating the use of the backing store, communications module, and event filtering system;

wherein the event requests represent interactions with a distributed filesystem storage system.

2. The event distribution system of claim 1, wherein the synchronous client-server protocol is one of HTTP, HTTPS, and SIP;

wherein the channel identifier is a URI; and

wherein the event requests are formatted as one of HTTP POST, HTTP PUT, HTTP GET, and SIP NOTIFY.

3. The event distribution system of claim 1, wherein the event manager uses the event filtering system to block the recording of substantially identical requests in the backing store.

4. The event distribution system of claim 1, wherein the event manager uses the event filtering system to block the sending of substantially identical responses via the communications module.

5. The event distribution system of claim 1, wherein the event manager uses the event filtering system to identify a set of essential parameters that characterize a request, the parameters including the channel identifier;

and wherein every request including substantially identical parameters returns a substantially identical response via the communications module.

6. The event distribution system of claim 5, wherein the set of essential parameters includes a temporal range;

and wherein a request with substantially identical parameters includes a request made within the defined temporal range.

7. A method comprising:

receiving at a server an event publishing request, the event publishing request including an event publishing verb and a first subject, wherein the verb describes the requested publishing action, and wherein the first subject includes a first event, the event further including a first channel identifier, a first resource identifier and a first associated action;

receiving a first event notification request, the first event notification request including the first channel identifier;

performing at the server a first filtering operation to obtain a first filtering result;

if indicated by the first filtering result, sending a first response, the first response including a representation of the first event, the representation of the first event including the first resource identifier and a representation of the first associated action;

receiving a second event notification request, the second event notification request including the first channel identifier;

performing at the server a second filtering operation to obtain a second filtering result;

if indicated by the second filtering result, sending a second response including a representation of the first event, wherein the representation of the first event in the second response is substantially identical to the first response;

wherein the resource identifier is representative of a filesystem object, and the first associated action describes an interaction with the filesystem object.

8. The method of claim 7, wherein the event publishing request is transmitted using one of HTTP and HTTPS, wherein the event publishing verb is one of POST and PUT, and wherein one of the first and second event notification request are formatted as an HTTP POST and HTTP GET.

9. The method of claim 7, wherein the event publishing request is transmitted using SIP, and wherein either event publishing verb or one of the first and second event notification requests are include a SIP NOTIFY.

10. The method of claim 7, wherein the channel identifier is a URI.

11. The method of claim 7, wherein the first filtering operation includes identifying at the server that the event publishing request and the first event notification request come from a common source;

and preventing the sending of the first event notification request using the first filtering result.

12. The method of claim 7, wherein the second filtering operation includes identifying that a specified amount of time has passed;

and preventing the sending of the second event notification request using the second filtering result.

13. The method of claim 7, wherein the representation of the first event is encoded in a format selected from the group consisting of a Javascript array, JSON, BSON, XML, HTML, and plain text.

14. The method of claim 7, wherein the first and second notification requests originate from a common source;

wherein the second filtering operation includes identifying at the server that the first event notification request and the second notification request come from the common source; and

preventing the sending of a substantially identical second response using the second filtering result.

15. The method of claim 14, further comprising:

between the first and second notification requests, receiving a third event notification request from a second source, the third subject including the first channel identifier;

wherein the second filtering operation includes identifying at the server that the first event notification request and the third notification request are directed to a common channel identifier and do not come from a common source; and

changing the second event notification request using the second filtering result to notify the first source of the second source.

16. A non-transient computer readable medium containing executable instructions, which

when executed on a processor:

receive at a server a request formatted according to a client-server protocol, the request addressed to a channel identifier and including a set of parameters;

evaluate the parameters to determine a response, wherein;

in a first possible response, the parameters are interpreted to define a new event, and the executable instructions are operable to store a representation of the event parameters on a computer-readable medium and return a response indicating successful storage of the event;

in a second possible response, the parameters are interpreted to refer to an existing event, and the executable instructions are operable to load a representation of the existing event, and include a representation of the event in a response;

in a third possible response, the parameters are interpreted to refer to an nonexisting event, and the executable instructions are operable to send an empty response;

wherein the event parameters are name a filesystem object and an action associated with the named filesystem object.

17. The executable instructions of claim 16, which when executed on a processor, are further operable to:

in the first possible response, associate an event ID with the new event, store the event ID with the representation of the event parameters, and wherein the response includes the event ID.

18. The executable instructions of claim 16, which when executed on a processor, are further operable to:

in a fourth possible response, the parameters are interpreted to refer to a range of possible events, and the executable instructions are operable to load a representation any existing stored events matching the range of possible events, and include a representation of the events in a response.

19. The executable instructions of claim 16, which when executed on a processor, are further operable to:

identify set of events older than a set time, and the executable instructions are operable to delete the representation any existing stored events older than the set time.

20. The executable instructions of claim 16, which when executed on a processor, are further operable do one of cache a responses, layer responsive components, and present uniform interface for remote communication.