REPOSITORY REDUNDANCY IMPLEMENTATION OF A SYSTEM WHICH INCREMENTALLY UPDATES CLIENTS WITH EVENTS THAT OCCURRED VIA A CLOUD-ENABLED PLATFORM

• US 20130304694A1
• Filed: 05/06/2013
• Published: 11/14/2013
• Est. Priority Date: 05/04/2012
• Status: Active Grant

• Current Assignee: Box Incorporated
• Original Assignee: Box Incorporated
• Inventors: Barreto, Tomas, Mackenzie, David, Mand, Arshdeep, Spielberg, Miles
• Granted Patent: US 9,396,216 B2
• Time in Patent Office: Days
• US Class Current: 707/608
• CPC Class Codes: G06F 11/14 Error detection or correction of the data by redundancy in operation G06F11/16 takes precedence
• CPC Class Codes: G06F 11/1471 involving logging of persistent data for recovery
• CPC Class Codes: G06F 11/2023 Failover techniques
• CPC Class Codes: G06F 11/2048 where the redundant components share neither address space nor persistent storage
• CPC Class Codes: G06F 11/2097 maintaining the standby controller/processing unit updated initialisation or re-synchronisation thereof G06F11/1658 and subgroups
• CPC Class Codes: G06F 16/1734 Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs
• CPC Class Codes: G06F 16/178 Techniques for file synchronisation in file systems
• CPC Class Codes: G06F 16/27 Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Abstract

Techniques are disclosed for implementing repository redundancy in a system which incrementally updates remote clients with events that occurred in a cloud-enabled platform. In one embodiment, a method comprises comparing a local timestamp of an event with a remote timestamp of the event. The event is to be stored in a queue in a repository cluster to be read by a remote client. The method further comprises updating the local timestamp of the event if the comparing indicates that the remote timestamp is more recent than the local timestamp. Among other advantages, embodiments disclosed herein ensure that no event in an action log is missed or skipped by any of remote clients in a distributed action log framework system during a switchover from an active but failed server to a backup server, and require zero or minimal down time during the switchover, thereby providing robustness and serviceability to such system.

Claims

1. A system, comprising:

an action log table for storing a plurality of entries, each entry corresponding to one of the events, wherein the entries are written by one or more user applications of the cloud-based environment;

a dispatcher coupled to the table to selectively issue the entries to a plurality of processor modules based on a type or an identity of a user associated with a respective processor module;

a data repository coupled to the processor modules for storing the entries that are issued to the processor modules after processing, wherein the data repository comprises a distributed database structure,

wherein the dispatcher includes a controller to determine whether the entries are occurring faster than a speed at which the dispatcher and processors can handle them based on a response time of the processor module.

2. A method for repository redundancy in a system which incrementally updates remote clients with events that occurred in a cloud-enabled platform, each remote client being associated with a collaborator, the method comprising:

comparing a local timestamp of an event with a remote timestamp of the event, wherein the event is to be stored in a queue in a repository cluster to be read by a remote client; and

updating the local timestamp of the event if the comparing indicates that the remote timestamp is more recent than the local timestamp.

3. The method of claim 2, wherein the local timestamp is updated based on a current time of the system.

4. The method of claim 2, wherein the local timestamp and the remote timestamp are stored as an action log entry that corresponds to the event, and wherein the action log entry further includes an identifier that uniquely identifies the event.

5. The method of claim 2, further comprising:

clearing the remote timestamp (i) after the updating, or (ii) if the local timestamp is more recent than the remote timestamp.

6. The method of claim 2, further comprising:

clearing the remote timestamp, if the remote timestamp is not empty and not equal to the local timestamp.

7. The method of claim 2, wherein the updating is also performed if the local timestamp is empty.

8. The method of claim 2, wherein the updating is performed when the system is operating in an active mode.

9. The method of claim 8, further comprising:

when the system is operating in a passive mode, copying a remote timestamp associated with an active remote system into the local timestamp.

10. The method of claim 9, wherein the copying is performed if (i) the local timestamp is empty, and if (ii) the remote timestamp associated with the active remote system is valid.

11. The method of claim 10, wherein the remote timestamp associated with the active remote system is valid if (i) it is the only timestamp that has a value, or if (ii) all remote timestamps are equal to each other.

12. The method of claim 2, wherein the local timestamp represents at what time the event occurred as recorded by the system, and wherein the remote timestamp represents at what time the event occurred as recorded by another system that is remote from the system.

13. The method of claim 2, wherein the repository cluster is distributed.

14. The method of claim 2, wherein the queue is read by the remote client by using a query specific to a client type or a user'"'"'s identity of the remote client.

15. The method of claim 14, wherein the client type includes an enterprise action log of the cloud-enabled collaboration platform.

16. The method of claim 2, wherein the repository cluster includes a relational database.

17. The method of claim 2, wherein the repository cluster includes non-relational databases.

18. The method of claim 2, wherein the repository cluster is write-optimized or optimized for sequential reads.

19. The method of claim 2, wherein the repository cluster comprises an HBase cluster.

20. The method of claim 2, wherein the event is written to the repository cluster as a part of a batch of recently occurred events to be written to queues for multiple collaborators.

21. A method for repository redundancy in a system which incrementally updates remote clients with events that occurred in a cloud-enabled platform, each remote client being associated with a collaborator, the method comprising:

comparing a first local timestamp of a first event in an action log with a first remote timestamp of the first event, wherein the action log includes log entries in a data repository for the events that occurred in the cloud-enabled platform; and

if the comparing indicates that the first remote timestamp is more recent than the first local timestamp, generating a second event in the action log,

wherein the second event includes a second local timestamp that is updated based on a current time of the system.

22. The method of claim 21, wherein the second event has a same identifier as the first event, and wherein the second local timestamp of the second event has a value that represents the current time of the system.

23. The method of claim 21, wherein the second event includes a second remote timestamp that is empty.

24. The method of claim 21, wherein the generating is also performed when the first local timestamp is empty.

25. The method of claim 21, wherein the generating is performed when the system is in an active mode.

26. The method of claim 25, further comprising:

when the system is in a passive mode, copying a remote timestamp associated with an active remote system into the first local timestamp.

27. The method of claim 26, wherein the copying is performed if (i) the first local timestamp is empty, and if (ii) the remote timestamp associated with the active remote system is valid.

28. The method of claim 27, wherein the remote timestamp associated with the active remote system is valid if (i) it is the only timestamp that has a value, or if (ii) all remote timestamps are equal to each other.

29. A system for incrementally updating remote clients with events that occurred in a cloud-based environment, the system comprising:

a processor; and

a memory coupled to the processor and storing a plurality of instructions which, when executed by the processor, cause the processor to;

process events from an action log, the action log having log entries in a data repository for the events that occurred in the cloud-based environment, each log entry including an identifier, a local timestamp, and one or more remote timestamps for an event;

wherein the local timestamp is associated with the system, and wherein the one or more remote timestamps are each associated with one remote system.

30. The system of claim 29, wherein the processor is further caused to:

compare a local timestamp of the event with a remote timestamp of the event; and

update the local timestamp of the event based on a current time of the system if the comparison indicates that the remote timestamp is more recent than the local timestamp.

31. The system of claim 29, wherein the processor is to perform the updating if the local timestamp is empty.

32. The system of claim 29, wherein the processor is to perform the updating if the local timestamp is empty.

33. The system of claim 29, wherein the processor is to perform the updating when the system is in an active mode.

34. The system of claim 33, wherein, when the system is in a passive mode, the processor is further caused to:

copy a remote timestamp associated with an active remote dispatcher into the local timestamp.

35. The system of claim 34, wherein the processor is to perform the copying if (i) the local timestamp is empty, and if (ii) the remote timestamp associated with the active remote system is valid.

36. The system of claim 35, wherein the remote timestamp associated with the active remote system is valid if (i) it is the only timestamp that has a value, or if (ii) all remote timestamps are equal to each other.

37. The system of claim 29, wherein the processor is further caused to:

clear the remote timestamp (i) after the update, or (ii) if the local timestamp is more recent than the remote timestamp.

38. The system of claim 29, wherein the processor is further caused to:

clear the remote timestamp, if the remote timestamp is not empty and not equal to the local timestamp.

39. A system for incrementally updating remote clients with events that occurred in a cloud-based environment, the system comprising:

a processor; and

a memory coupled to the processor and storing a plurality of instructions which, when executed by the processor, cause the processor to;

dispatch events from an action log, the action log having log entries in a data repository for the events that occurred in the cloud-based environment, each log entry including an identifier, a local timestamp, and one or more remote timestamps for an event;

when the system is operating in an active mode, (i) compare a local timestamp of the event with a remote timestamp of the event, and (ii) update the local timestamp of the event based on a current time of the system if the comparison indicates that the remote timestamp is more recent than the local timestamp; and

when the system is operating in a passive mode, (i) copy a remote timestamp associated with an active remote system into the local timestamp.

40. A system having a plurality of data centers for incrementally updating remote clients with events that occurred in a cloud-based environment, the system comprising:

a first data center having a first repository to store a plurality of log entries, wherein the log entries represent the events that occurred in the cloud-based environment, and wherein each log entry includes an identifier, a local timestamp, and one or more remote timestamps for an event;

a second data center having a second repository to store the plurality of events; and

a control module coupled to the data centers to select one data center to act as an active data center upon detecting failure of one or more of the data centers,

wherein the first data center, when operating as the active center, is to;

(i) compare a local timestamp of an event with a remote timestamp of the event, and (ii) update the local timestamp of the event based on a current time of the first data center if the comparison indicates that the remote timestamp is more recent than the local timestamp,

and wherein the second data center, when operating as a passive center, is to;

(i) copy a remote timestamp associated with the active center into the local timestamp.

41. The system of claim 40, further comprising a third data center having a second repository to store the plurality of events, wherein the third data center operates as another passive center.

42. A machine-readable medium storage medium having stored thereon instructions which, when executed by a processor, causes the processor to:

compare a local timestamp of an event with a remote timestamp of the event, wherein the event is to be stored in a queue in a repository cluster to be read by a remote client; and

update the local timestamp of the event if the comparing indicates that the remote timestamp is more recent than the local timestamp.

43. The medium of claim 42, wherein the local timestamp is updated based on a current time of a system that comprises the processor.