Abstract: A method for using available server threads to process resources and reduce the overall time of performing XA interactions in two-phase commit protocol implemented by the transaction manager. A TM processing XA interactions dispatches interaction commands for multiple resources to a thread manager, which dispatches the commands to idle server threads. In one embodiment, the TM attempts to dispatch all but one of the interaction commands to separate threads. The primary thread then processes the remaining resource command. Any commands relating to dispatch requests that were unable to be dispatched to separate threads due to unavailability are processed by the primary thread. Once the primary server has processed its interaction commands and received a signal indicating the threads receiving dispatch requests have completed their respective processing of dispatched commands, the next group of commands is processed in a similar manner.

Abstract: A SIP server can be distributed over a cluster network and handle the processing of various SIP communications. A Diameter protocol web application can be deployed on the engine tier of the SIP server for enabling communication between the SIP server and an HSS. A profile service API can be provided that allows applications running on the SIP server to access user profile data stored on the HSS. The applications can also be allowed to subscribe to notifications about changes to the user profile data on the HSS. An Sh interface provider can be deployed on the SIP server for generating and responding to Diameter command codes. SIP servlets can access the user profile data in the form of an XML document.

Abstract: The Session Initiation Protocol (SIP) server can be comprised of an engine tier and a state tier distributed on a cluster network environment. The engine tier can send, receive and process various messages. The state tier can maintain in-memory state data associated with various SIP sessions. Various applications can be running on the engine tier. A new version of an application can be deployed alongside the old version, simultaneously running on the SIP server. Incoming messages for new calls can be directed by the SIP server to the new version of the application. Incoming messages for previously established calls can be directed to the old version of the application. Once the old version is finished processing calls, it can be undeployed.

Abstract: The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network environment. The engine tier can send, receive and process various messages. The state tier can maintain in-memory state data associated with various SIP sessions. A near cache can be residing on the engine tier in order to maintain a local copy of a portion of the state data contained in the state tier. Various engines in the engine tier can determine whether the near cache contains a current version of the state needed to process a message before retrieving the state data from the state tier. Accessing the state from the near cache can save on various latency costs such as serialization, transport and deserialization of state to and from the state tier. Furthermore, the near cache and JVM can be tuned to further improve performance of the SIP server.

Abstract: The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network environment. The engine tier can send, receive and process various messages. The state tier can maintain in-memory state data associated with various SIP sessions. The SIP server can support converged HTTP and SIP modes of communication. An application session can be established for allowing the association of an HTTP session with a SIP session such that data can be exchanged between them. This association can be broken and reestablished with new application sessions such that various SIP and HTTP clients can join and leave new sessions. An API can be provided to enable various associations and method calls for the application session.

Abstract: Systems and methods are provided for improving latency during message processing in a network environment via the use of SIP server architecture. The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network. The engine tier can send and receive messages and execute various processes. The state tier can maintain in-memory state data associated with various SIP sessions. The state tier can store various long lived data objects and the engine tier can contain short lived data objects. The state data can be maintained in partitions comprised of state replicas. When processing messages, the engine can pull state data objects from the state tier, use the objects and push them back to the state tier after processing is complete. If one state replica is unavailable, such as during garbage collection, the engine can retrieve the objects from another replica in the partition.

Abstract: In an embodiment, a system for managing communications sessions is provided. The system embodiment includes a connection to a packet network that receives incoming calls. A stateful tier manages communications sessions established for the at least one incoming call. A stateless tier comprising one or more applications provides service(s) to the communications sessions in the stateful tier. One or more servers allocate and/or manage resources corresponding to the communications sessions established for the incoming calls in the stateful tier. The servers maintain the applications in the stateless tier for providing services to the communications sessions in the stateful tier.

Abstract: The SIP server deployment can be comprised of an engine tier that provides high throughput processing and a state tier that maintains SIP state data in a set of partitions and replicas. Two sites of SIP server deployments can be configured, each being remotely located with respect to the other. A primary site can process various SIP transactions and communications and upon determining a transaction boundary, replicate the state data associated with the transaction being processed, to a secondary site. Engines in the primary site can generate hints for the state replicas which can be in turn responsible for replicating the SIP session state. The replicas can choose to follow or disregard the generated hints. Upon failure of the primary site, calls can be routed from the failed primary site to the secondary site for processing. Similarly, upon recovery, the calls can be re-routed back to the primary site.

Abstract: A system and a method for dynamic or as-needed activation of Remote Method Invocation (RMI) layer remote objects in response to a client request. Object activation allows the system to clean up or delete currently unused remote objects, and then reactivate them when a client actually needs them. An object implementation can first be created in response to a client request. The client receives a remote reference (remote ref) and an activation identifier (activation id) identifying that particular implementation. The implementation can subsequently be cleaned up or deleted during garbage collection so as to save server resources, or alternatively the object can be reused if the system is set up to maintain a pool of objects. When the client requests the same object at a later point in time, the system activates an object based on the activation ID previously received from the server.

Abstract: Systems and methods are provided for improving latency during message processing in a network environment via the use of SIP server architecture. The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network. The engine tier can send and receive messages and execute various processes. The state tier can maintain in-memory state data associated with various SIP sessions. The state tier can store various long lived data objects and the engine tier can contain short lived data objects. The state data can be maintained in partitions comprised of state replicas. When processing messages, the engine can pull state data objects from the state tier, use the objects and push them back to the state tier after processing is complete. If one state replica is unavailable, such as during garbage collection, the engine can retrieve the objects from another replica in the partition.

Abstract: A system and method for application server with overload protection. A system, for example a server or a cluster, is designed to generate a message, and/or reject further work, whenever the server becomes overloaded. It does this in a processor-efficient manner so as not to place even more strain on the already burdened server. The rejection message or action is customizable. In accordance with an embodiment, the system determines where the request would appear in a priority queue, and rejects those further down the queue. It does this quickly and with minimal processing time by determining to which workload manager the request is going to be delivered.

Abstract: A method for using available server threads to process resources and reduce the overall time of performing XA interactions in two-phase commit protocol implemented by the transaction manager. A TM processing XA interactions dispatches interaction commands for multiple resources to a thread manager, which dispatches the commands to idle server threads. In one embodiment, the TM attempts to dispatch all but one of the interaction commands to separate threads. The primary thread then processes the remaining resource command. Any commands relating to dispatch requests that were unable to be dispatched to separate threads due to unavailability are processed by the primary thread. Once the primary server has processed its interaction commands and received a signal indicating the threads receiving dispatch requests have completed their respective processing of dispatched commands, the next group of commands is processed in a similar manner.

Abstract: The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network. Engine nodes in the engine tier can process SIP messages and can read/write state information from/to the state tier. State tier can maintain state information in a set of partitions of one or more replicas which contain duplicate information. The engine nodes can be adapted to detect and report replica failures and the replicas can in turn be adapted to detect and report engine node failures. Replicas can detect faults with an engine node if the engine node fails to poll the replica for a specified period of time and can then report the failure. The engine node can detect failures of a replica when reading or writing state information and can report the failure to another replica, which can be responsible for updating the partition view to exclude dead replicas.

Abstract: A method for using available server threads to process resources and reduce the overall time of performing XA interactions in two-phase commit protocol implemented by the transaction manager. A TM processing XA interactions dispatches interaction commands for multiple resources to a thread manager, which dispatches the commands to idle server threads. In one embodiment, the TM attempts to dispatch all but one of the interaction commands to separate threads. The primary thread then processes the remaining resource command. Any commands relating to dispatch requests that were unable to be dispatched to separate threads due to unavailability are processed by the primary thread. Once the primary server has processed its interaction commands and received a signal indicating the threads receiving dispatch requests have completed their respective processing of dispatched commands, the next group of commands is processed in a similar manner.

Abstract: A system and a method for scheduling disk writes for use with an application server, transactional system, or other server. The disk scheduler and method is independent of the underlying operating system and the disk hardware. This allows it to be used without porting to the various settings in which application server might be deployed. In some embodiments, a high-performance, transactional filestore is also provided to minimize the latency of small, synchronous writes to disk. The implementation uses a log-structured file system combined with disk scheduling. By relaxing the requirement that log records be physically contiguous, every modification to the disk can be scheduled.

Abstract: The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network environment. The engine tier can send, receive and process various messages. The state tier can maintain in-memory state data associated with various SIP sessions. A near cache can be residing on the engine tier in order to maintain a local copy of a portion of the state data contained in the state tier. Various engines in the engine tier can determine whether the near cache contains a current version of the state needed to process a message before retrieving the state data from the state tier. Accessing the state from the near cache can save on various latency costs such as serialization, transport and deserialization of state to and from the state tier. Furthermore, the near cache and JVM can be tuned to further improve performance of the SIP server.

Abstract: The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network environment. The engine tier can send, receive and process various messages. The state tier can maintain in-memory state data associated with various SIP sessions. The SIP server can support converged HTTP and SIP modes of communication. An application session can be established for allowing the association of an HTTP session with a SIP session such that data can be exchanged between them. This association can be broken and reestablished with new application sessions such that various SIP and HTTP clients can join and leave new sessions. An API can be provided to enable various associations and method calls for the application session.

Abstract: The SIP server deployment can be comprised of an engine tier that provides high throughput processing and a state tier that maintains SIP state data in a set of partitions and replicas. Two sites of SIP server deployments can be configured, each being remotely located with respect to the other. A primary site can process various SIP transactions and communications and upon determining a transaction boundary, replicate the state data associated with the transaction being processed, to a secondary site. Engines in the primary site can generate hints for the state replicas which can be in turn responsible for replicating the SIP session state. The replicas can choose to follow or disregard the generated hints. Upon failure of the primary site, calls can be routed from the failed primary site to the secondary site for processing. Similarly, upon recovery, the calls can be re-routed back to the primary site.

Abstract: The SIP server can be comprised of an engine tier and a state tier distributed on a cluster network. Engine nodes in the engine tier can process SIP messages and can read/write state information from/to the state tier. State tier can maintain state information in a set of partitions of one or more replicas which contain duplicate information. The engine nodes can be adapted to detect and report replica failures and the replicas can in turn be adapted to detect and report engine node failures. Replicas can detect faults with an engine node if the engine node fails to poll the replica for a specified period of time and can then report the failure. The engine node can detect failures of a replica when reading or writing state information and can report the failure to another replica, which can be responsible for updating the partition view to exclude dead replicas.

Abstract: A SIP server can be distributed over a cluster network and handle the processing of various SIP communications. A Diameter protocol web application can be deployed on the engine tier of the SIP server for enabling communication between the SIP server and an HSS. A profile service API can be provided that allows applications running on the SIP server to access user profile data stored on the HSS. The applications can also be allowed to subscribe to notifications about changes to the user profile data on the HSS. An Sh interface provider can be deployed on the SIP server for generating and responding to Diameter command codes. SIP servlets can access the user profile data in the form of an XML document.