Abstract: Message prioritization may be provided. First, a message may be received and a priority level may be calculated for the message. If the message is not rejected for having a priority lower than a predetermined threshold, the message may be placed in a first priority queue. Next, the message may be de-queued from the first priority queue based upon the calculated priority level for the message. Distribution group recipients corresponding to the message may then be expanded and the priority level for the message may be re-calculated based upon the expanded distribution group recipients. Next, the message may be placed in a second priority queue. The message may then be de-queued from the second priority queue based upon the re-calculated priority level for the message and delivered.

Abstract: Allocation of computing threads can include receiving a registration of a workload, the registration including a workload classification and a workload priority; monitoring statuses of a plurality of resources; identifying, by a computing device, a thread of a resource from the plurality of resources, the thread being programmed to execute a task associated with the workload; evaluating, by the computing device, the workload classification and the workload priority of the workload with workload classifications and workload priorities of other workloads requesting the thread; and allocating the thread to one of the workloads based on evaluation of the workload classification and the workload priority.

Abstract: Message prioritization may be provided. First, a message may be received and a priority level may be calculated for the message. If the message is not rejected for having a priority lower than a predetermined threshold, the message may be placed in a first priority queue. Next, the message may be de-queued from the first priority queue based upon the calculated priority level for the message. Distribution group recipients corresponding to the message may then be expanded and the priority level for the message may be re-calculated based upon the expanded distribution group recipients. Next, the message may be placed in a second priority queue. The message may then be de-queued from the second priority queue based upon the re-calculated priority level for the message and delivered.

Abstract: Allocation of computing threads can include receiving a registration of a workload, the registration including a workload classification and a workload priority; monitoring statuses of a plurality of resources; identifying, by a computing device, a thread of a resource from the plurality of resources, the thread being programmed to execute a task associated with the workload; evaluating, by the computing device, the workload classification and the workload priority of the workload with workload classifications and workload priorities of other workloads requesting the thread; and allocating the thread to one of the workloads based on evaluation of the workload classification and the workload priority.

Abstract: A current request for a server to perform work for a user profile can be received and processed at the server. It can be determined whether server usage by the profile exhibits a sufficient trend toward a threshold value to warrant performing traffic shaping for the user profile. If so, then a delay time can be calculated based on, or as a function of, server resources used in processing the current request, and a response to the current request can be delayed by the delay time.

Abstract: A computer-implemented method for allocating threads includes: receiving a registration of a workload, the registration including a workload classification and a workload priority; monitoring statuses of a plurality of resources; identifying, by a computing device, a thread of a resource from the plurality of resources, the thread being programmed to execute a task associated with the workload; evaluating, by the computing device, the workload classification and the workload priority of the workload with workload classifications and workload priorities of other workloads requesting the thread; and allocating the thread to one of the workloads based on evaluation of the workload classification and the workload priority.

Abstract: A current request for a server to perform work for a user profile can be received and processed at the server. It can be determined whether server usage by the profile exhibits a sufficient trend toward a threshold value to warrant performing traffic shaping for the user profile. If so, then a delay time can be calculated based on, or as a function of, server resources used in processing the current request, and a response to the current request can be delayed by the delay time.

Abstract: A method is presented for using a distributed source control system with a centralized source control system. A first set of files is obtained from a source control repository and stored on a first electronic computing device. The first set of files comprises all or part of a code base in the centralized source control system. A request is received for at least part of the code base from a second electronic computing device in a distributed source control system. As a result of the request, at least a part of the first set of files is sent to the second electronic computing device. A change set for the first set of files is received from the second electronic computing device. The change set is processed to be in a format compatible with the source control repository. The change set is submitted to the source control repository.

Abstract: Conditional deferred queuing may be provided. Upon receiving a message, one or more throttle conditions associated with the message may be identified. A lock associated with the throttle condition may be created on the message until the throttle condition is satisfied. Then, the lock on the message may be removed and the message may be delivered.

Abstract: Architecture for efficiently ensuring that data is stored to the desired destination datastore such as for replication processes. A copy of data (e.g., messages) sent to a datastore for storage is stored at an alternate location until a received signal indicates that the storage and replication was successful. As soon as the feedback signal is received, the copy is removed from the alternate location, and hence, improves input/output (I/O) and storage patterns. The feedback mechanism can also be used for monitoring the status of data transport associated with log shipping, for example, and taking the appropriate actions when storage (e.g., replication) is not being performed properly.

Abstract: Techniques to normalize names for name-based speech recognition grammars are described. Some embodiments are particularly directed to techniques to normalize names for name-based speech recognition grammars more efficiently by caching, and on a per-culture basis. A technique may comprise receiving a name for normalization, during name processing for a name-based speech grammar generating process. A normalization cache may be examined to determine if the name is already in the cache in a normalized form. When the name is not already in the cache, the name may be normalized and added to the cache. When the name is in the cache, the normalization result may be retrieved and passed to the next processing step. Other embodiments are described and claimed.

Abstract: Architecture that facilitates transport high availability for messaging services by providing the ability of a receiving entity (e.g., receiving message transfer agent (MTA)) to detect if a sending entity (e.g., sending MTA or client) is a legacy sending entity. When the receiving entity detects that the sending entity is a legacy system, by advertising transport high availability capability to the sending entity, if the sending entity does not opt-in to this capability, the receiving entity keeps the sending entity client “on hold”, that is, waiting for an acknowledgement (ACK) until the receiving entity delivers the message to the next hops (immediate destinations). This approach maintains at least two copies of the message until the message is successfully delivered (to the next hop(s)). Hence, if the legacy sending entity or the receiving entity fails, the message is still delivered successfully.

Abstract: Real-time diagnostics may be provided. A plurality of data feeds may be aggregated from at least one of a plurality of nodes. Upon determining that at least one element of at least one of the data feeds meets a trigger condition, an action associated with the trigger condition may be executed.

Abstract: Techniques to normalize names for name-based speech recognition grammars are described. Some embodiments are particularly directed to techniques to normalize names for name-based speech recognition grammars more efficiently by caching, and on a per-culture basis. A technique may comprise receiving a name for normalization, during name processing for a name-based speech grammar generating process. A normalization cache may be examined to determine if the name is already in the cache in a normalized form. When the name is not already in the cache, the name may be normalized and added to the cache. When the name is in the cache, the normalization result may be retrieved and passed to the next processing step. Other embodiments are described and claimed.

Abstract: A current request for a server to perform work for a user profile can be received and processed at the server. It can be determined whether server usage by the profile exhibits a sufficient trend toward a threshold value to warrant performing traffic shaping for the user profile. If so, then a delay time can be calculated based on, or as a function of, server resources used in processing the current request, and a response to the current request can be delayed by the delay time.

Abstract: A root cause for a failed attempted delivery of a message is attempted to be determined before sending a non-delivery report (NDR) for the failed message. When a message fails without a known cause, the root cause is determined using the context of the message. For a given context, the root cause may be determined by a single failure or it may be determined by the relative number of failed messages delivery are deferred from being delivered, as is generation of the corresponding same context. While determining the root cause of the problem, any messages failing NDR(s), to allow time for corrective action to occur. If the problem is resolved within a predetermined time period, the deferred messages are delivered without having to issue NDR(s).

Abstract: A method is presented for using a distributed source control system with a centralized source control system. A first set of files is obtained from a source control repository and stored on a first electronic computing device. The first set of files comprises all or part of a code base in the centralized source control system. A request is received for at least part of the code base from a second electronic computing device in a distributed source control system. As a result of the request, at least a part of the first set of files is sent to the second electronic computing device. A change set for the first set of files is received from the second electronic computing device. The change set is processed to be in a format compatible with the source control repository. The change set is submitted to the source control repository.

Abstract: A computer-implemented method for allocating threads includes: receiving a registration of a workload, the registration including a workload classification and a workload priority; monitoring statuses of a plurality of resources; identifying, by a computing device, a thread of a resource from the plurality of resources, the thread being programmed to execute a task associated with the workload; evaluating, by the computing device, the workload classification and the workload priority of the workload with workload classifications and workload priorities of other workloads requesting the thread; and allocating the thread to one of the workloads based on evaluation of the workload classification and the workload priority.

Abstract: Business to business secure mail may be provided. Consistent with embodiments of the invention, a protected message may be received. The recipient may request a token from a trust broker, submit the token to an authorization server associated with the sender, receive a user license from the authorization server; and decrypt the protected message using the user license. The protected message may restrict actions that may be taken by the recipient, such as forwarding to other users.

Abstract: Architecture that facilitates transport high availability for messaging services by providing the ability of a receiving entity (e.g., receiving message transfer agent (MTA)) to detect if a sending entity (e.g., sending MTA or client) is a legacy sending entity. When the receiving entity detects that the sending entity is a legacy system, by advertising transport high availability capability to the sending entity, if the sending entity does not opt-in to this capability, the receiving entity keeps the sending entity client “on hold”, that is, waiting for an acknowledgement (ACK) until the receiving entity delivers the message to the next hops (immediate destinations). This approach maintains at least two copies of the message until the message is successfully delivered (to the next hop(s)). Hence, if the legacy sending entity or the receiving entity fails, the message is still delivered successfully.