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

• US 20140337491A1
• Filed: 05/08/2013
• Published: 11/13/2014
• Est. Priority Date: 05/08/2013
• Status: Abandoned Application

• Current Assignee: Box Incorporated
• Original Assignee: Box Incorporated
• Inventors: Barreto, Tomas, Mackenzie, David, Mand, Arshdeep, Spielberg, Miles
• Application Number:
  US13/890,172
• Publication Number:
  US 20140337491A1
• Time in Patent Office: Days
• US Class Current: 709/221
• CPC Class Codes: G06F 16/182 Distributed file systems

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 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.

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

3. The method of claim 1, 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.

4. The method of claim 1, further comprising:

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

5. The method of claim 1, further comprising:

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

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

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

8. The method of claim 7, 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.

9. The method of claim 8, 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.

10. The method of claim 9, 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.

11. The method of claim 1, 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.

12. The method of claim 1, wherein the repository cluster is distributed.

13. The method of claim 1, 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.

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

15. The method of claim 1, wherein the repository cluster includes a relational database.

16. The method of claim 1, wherein the repository cluster includes non-relational databases.

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

18. The method of claim 1, wherein the repository cluster comprises an HBase cluster.

19. The method of claim 1, 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.

20. 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.

21. The method of claim 20, 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.

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

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

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

25. The method of claim 24, 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.

26. The method of claim 25, 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.

27. The method of claim 26, 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.

28. 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.

29. The system of claim 28, 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.

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

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

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

33. The system of claim 32, 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.

34. The system of claim 33, 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.

35. The system of claim 34, 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.

36. The system of claim 28, 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.

37. The system of claim 28, 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.

38. 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.

39. 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.

40. The system of claim 39, 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.

41. 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.

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