Abstract: A cloud computing system includes computing nodes that execute a shared application and/or service accessible by client computing devices over a network. A resilience multiplexer is configured to: receive signals (e.g., from a cloud controller, registry service, error handler, and/or failover service) indicative of potential problems with components of the system and/or network; identify a rule to be executed to determine how to respond to the potential problem, based on attributes of the received signal including which component generated it and what information is included in/otherwise associated with it, and other network-related data; execute the identified rule to determine whether a failover is or might be needed; if a failover is needed, selectively trigger a failover sequence; and if a failover only might be needed, initiate a resilience mode. In resilience mode, information regarding the potential problem is communicated to other components, without immediately initiating a failover sequence.

Abstract: A cloud computing system includes computing nodes that execute a shared application and/or service accessible by client computing devices over a network. A resilience multiplexer is configured to: receive signals (e.g., from a cloud controller, registry service, error handler, and/or failover service) indicative of potential problems with components of the system and/or network; identify a rule to be executed to determine how to respond to the potential problem, based on attributes of the received signal including which component generated it and what information is included in / otherwise associated with it, and other network-related data; execute the identified rule to determine whether a failover is or might be needed; if a failover is needed, selectively trigger a failover sequence; and if a failover only might be needed, initiate a resilience mode. In resilience mode, information regarding the potential problem is communicated to other components, without immediately initiating a failover sequence.

Abstract: Certain example embodiments relate to techniques for dynamic resource use limitations in a cloud computing environment. A service request from a user is received, in connection with a first application process of the application processes executing in the environment. A resource strategy based on the received service request is generated in connection with the first application process. The resource strategy specifies at least one resource shared by the application processes and an amount of the at least one resource for use by the first application process to subsequently perform a service requested. In connection with a resource controller process different from the first application process, a determination is made regarding whether the generated resource strategy is feasible. Either the service is performed (e.g., when the resource strategy is feasible), or the resource strategy is revised and re-submitted to the resource controller process (e.g., when the resource strategy is infeasible).

Abstract: A system for dynamic document retention, in a multi-owner environment that includes a document management system, registers, in a retention service, plural different document owners for a same document. The system receives a different owner-defined document retention policy for the document from each of the document owners, and registers, in a plug-in registry, the policies. In response to a scheduler or a document owner, the system triggers an update of a document retention policy, adds/deletes a document owner from the document, and/or deletes the document when there are no remaining document owners. The document management system includes a retention service that tracks the owners of the same document(s), the plug-in registry that tracks the different document retention policies of the different document owners, and an optional scheduler. The event-based retention policies can be responsive to events occurring internal to or external to the document management system.

Abstract: Certain example embodiments relate to techniques for recovering registry information and recreating the entire registry for all available tenants in a scalable, multi-tenant distributed environment, while also potentially looking into all of the running services where the most up-to-date data could exist. Dynamic real-time or substantially real-time recreation of connections between a web application and the latest instance of a tenant in such an environment (e.g., following a failure of one of the databases holding the tenant data, a corruption of the registry entry pointing to the tenant, and/or the like) is made possibly by, for instance, comparing the timestamps of the last written entities in order to examine the most current data and “re-bundle” the last master/replication instances, e.g., for restores in an environment where a rolling failover procedure is implemented.

Abstract: Certain example embodiments relate to techniques for dynamic resource use limitations in a cloud computing environment. A service request from a user is received, in connection with a first application process of the application processes executing in the environment. A resource strategy based on the received service request is generated in connection with the first application process. The resource strategy specifies at least one resource shared by the application processes and an amount of the at least one resource for use by the first application process to subsequently perform a service requested. In connection with a resource controller process different from the first application process, a determination is made regarding whether the generated resource strategy is feasible. Either the service is performed (e.g., when the resource strategy is feasible), or the resource strategy is revised and re-submitted to the resource controller process (e.g., when the resource strategy is infeasible).

Abstract: Certain example embodiments relate to techniques for dynamically bootstrapping repositories or databases for newly created tenants at runtime in scalable, distributed multi-tenant environments. Repositories are maintained for respective application-tenant combinations. If there is an existing repository for the application and tenant combination involved in an incoming request, the request is responded to using that existing repository. However, if this is not the case, a new repository is created dynamically and at runtime. Bootstrapping is triggered dynamically the first time a client application tries to access the newly created tenant at runtime. This approach advantageously is flexible when it comes to enabling tenant- and application-specific repositories with optional search index mapping (e.g., for searching and/or other purposes).

Abstract: A system for dynamic document retention, in a multi-owner environment that includes a document management system, registers, in a retention service, plural different document owners for a same document. The system receives a different owner-defined document retention policy for the document from each of the document owners, and registers, in a plug-in registry, the policies. In response to a scheduler or a document owner, the system triggers an update of a document retention policy, adds/deletes a document owner from the document, and/or deletes the document when there are no remaining document owners. The document management system includes a retention service that tracks the owners of the same document(s), the plug-in registry that tracks the different document retention policies of the different document owners, and an optional scheduler. The event-based retention policies can be responsive to events occurring internal to or external to the document management system.

Abstract: Certain example embodiments relate to techniques for recovering registry information and recreating the entire registry for all available tenants in a scalable, multi-tenant distributed environment, while also potentially looking into all of the running services where the most up-to-date data could exist. Dynamic real-time or substantially real-time recreation of connections between a web application and the latest instance of a tenant in such an environment (e.g., following a failure of one of the databases holding the tenant data, a corruption of the registry entry pointing to the tenant, and/or the like) is made possibly by, for instance, comparing the timestamps of the last written entities in order to examine the most current data and “re-bundle” the last master/replication instances, e.g., for restores in an environment where a rolling failover procedure is implemented.

Abstract: Certain example embodiments relate to techniques for dynamically bootstrapping repositories or databases for newly created tenants at runtime in scalable, distributed multi-tenant environments. Repositories are maintained for respective application-tenant combinations. If there is an existing repository for the application and tenant combination involved in an incoming request, the request is responded to using that existing repository. However, if this is not the case, a new repository is created dynamically and at runtime. Bootstrapping is triggered dynamically the first time a client application tries to access the newly created tenant at runtime. This approach advantageously is flexible when it comes to enabling tenant- and application-specific repositories with optional search index mapping (e.g., for searching and/or other purposes).