Bea Systems, Inc.

Oracle International Corporation

Google Inc.

Anno Langen

Rao Nasir Khan

Dean Bernard Jacobs

Ioannis Cosmadopoulos

Reto Kramer

Adam Messinger

John D Beatty

Jayant Madhavan

Alon Yitzchak Halevy

David W Connelly

Hector Gonzalez

Naresh Revanuru

Alexander J Somogyi

Vinod Mehra

Manoj Cheenath

Jaroslaw Jerzy Wilkiewicz

Andrin Von Richenberg

Prasad Peddada

William John Gallagher

Andrin Von Rechenberg

Aspects of the invention provide a service for data management and integration across a wide range of applications. Clustered computers may be arranged in a cloud-type configuration for storing and handling large amounts of user data under the control of a front-end management server. Communities of distributed users may collaborate on the data across multiple enterprises. Very large tabular data files are uploaded to the storage facilities. The data files are maintained as tables, and a composite table of related information is created and maintained in response to user queries. Different ways of visualizing the data are provided. Depending on the amount of information that can be displayed, features in a spatial index may the thinned for presentation. Spatial and structured queries are processing and results are intersected to obtain information for display.

Scalable rendering of large spatial databases

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.

Parallel transaction execution with a thread pool

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.

Diameter protocol and SH interface support for SIP server architecture

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.

Hitless application upgrade for SIP server architecture

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.

Engine near cache for reducing latency in a telecommunications environment

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.

SIP and HTTP convergence in network computing environments

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.

SIP server architecture for improving latency during message processing

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.

System and method for managing communications sessions in a network

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.

System and method for protecting against failure through geo-redundancy in a SIP server

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.

System and method for dynamic remote object activation

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.

System and method for application server with overload protection

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.

SIP server architecture fault tolerance and failover

A system and method for application server with self-tuned threading model. A server queue is used as a priority scheme, including a number of entries therein associated with received requests, and which allows the entries to have expressed priorities or share values, instead of simply the number of threads. Flexibility is retained to express the threads in raw numbers whenever this might be desired, or to express constraints on the number of threads to be made available.

Growing community of inventors

Berkeley, CA, United States of America

Anno Langen