Abstract: Object store management operations within compute-centric object stores are provided herein. An exemplary method may include transforming an object storage dump into an object store table by a table generator container, wherein the object storage dump includes at least objects within an object store that are marked for deletion, transmitting records for objects from the object store table to reducer containers, such that each reducer container receives object records for at least one object, the object records comprising all object records for the at least one object, generating a set of cleanup tasks by the reducer containers, and executing the cleanup tasks by a cleanup agents.

Abstract: Systems and methods for providing a compute-centric object store. An exemplary method may include receiving a request to perform a compute operation on at least a portion of an object store from a first user, the request identifying parameters of the compute operation, assigning virtual operating system containers to the objects of the object store from a pool of virtual operating system containers. The virtual operating system containers may perform the compute operation on the objects according to the identified parameters of the request. The method may also include clearing the virtual operating system containers and returning the virtual operating system containers to the pool.

Abstract: Each LDIF entry of a directory tree is read, split to a domain of LDIF fragments (corresponding to backend servers) and written to each LDIF fragment. The split may be accomplished through a hash function, establishing, for that iteration of LDIF entry, a write file. The LDIF entry is appended to the write file. A subsequent LDIF entry is read. A corresponding LDIF fragment is determined, which need not be different from the LDIF fragment to which the first LDIF entry was written. The current LDIF entry is written to the currently selected write file. The process continues until all LDIF entries are exhausted from the directory tree. LDIF fragments are each copied to distinct backend servers, where, each LDIF fragment may be loaded into a distributed directory data structure.

Abstract: A system and method for autonomically maintaining group referential integrity across a distributed directory. When a server receives an operation request from a client regarding an entry in the distributed directory, the server sends a request to the particular server containing the entry to be modified that instructs the server to modify the entry, but without performing a referential integrity check. The server then determines whether the request returned successfully. If so, the server sends a request to each server in the network to perform the requested operation on all group references for the entry, but without actually performing the requested operation on the entry itself. If all of these requests return successfully, the server notifies the requesting client that the requested operation has been performed.

Abstract: A processor which cooperates with directory servers to handle requests for values of dynamic attributes which would otherwise present a real-time processing challenge to the directory server due to the server's dependence on the data normally being static in nature. Special schema syntax identifiers are used to identify dynamic attributes which then are not stored directly in the directory, but whose values are resolved at the time a read request is made for those attributes. This approach eliminates the need to store the dynamic information in the directory, and allows user-supplied modules to perform the resolution of the dynamic attributes in a real-time manner, including not only retrieving a value from a dynamic data source, but optionally performing calculations or manipulations on the data as well. One embodiment of the invention cooperates with Lightweight Directory Access Protocol (“LDAP”) directory servers.

Abstract: A method is presented for processing data in a multithreaded application to alleviate impaired or substandard performance conditions. Work items that are pending processing by the multithreaded application are placed into a data structure. The work items are processed by a plurality of threads within the multithreaded application in accordance with a first algorithm, e.g., first-in first-out (FIFO). A thread within the multithreaded application is configured apart from the plurality of threads such that it processes work items in accordance with a second algorithm that differs from the first algorithm, thereby avoiding the impairing condition. For example, the thread may process a pending work item only if it has a particular characteristic. The thread restricts its own processing of work items by intermittently evaluating workflow conditions for the plurality of threads; if the workflow conditions improve or are unimpaired, then the thread does not process any work items.