opuscula orbis

CORBA and Grizzly

High performance is one of our most important goals for our CORBA implementation.  There are two measures of performance for the ORB that matter to us:

• How long does it take a single request to complete (latency)?
• How many requests can be processed simultaneously (throughput)?

Both are important, and we have benchmarks in both areas.

A number of parts of the ORB request processing code have a siginicant effect on performance. The two areas of greatest interest at present are marshaling and transport for requests across a LAN. I've filed a number of issues (952, 953, 954, 956, 958, 959, 960, 961, 962, 963) on marshaling performance, and done some other work in that area as well.  That is something that I'll discuss further another time.

Transport performance is the main focus of this discussion. The ORB currently uses an NIO-based non-blocking transport. We have done a lot of optimization work on the ORB transport, but for a number of reasons, we will be moving almost exclusively to Grizzly:

1. Grizzly has very good performance already.
2. Grizzly has a very active user community, which helps to ensure a high-quality implementation.
3. We want implement features in GlassFish like port unification and resource management that either require, or are greatly aided by running all communcations on a single transport implementation.
4. IIOP is a very different protocol than HTTP. By using Grizzly for IIOP we help to ensure that Grizzly is more broadly applicable.
   

The only case were we will not use Grizzly will be for handling socket factory code that users may plug into the ORB.  The SocketFactory allows user code to create the Socket or ServerSocket that the ORB uses for requests that target a particular IOR.  The ORB uses a simple thread-per-Socket transport to handle this case, when the Socket is not actually backed by a SocketChannel. 

One of the ORB team members (Harsha) has been working on integrating CORBA with Grizzly for some time now. As you would expect, this affects only the ORB transport, but the complexities of the IIOP protocol create some interesting challenges.  In particular, IIOP can interleave multiple fragmented messages on a single TCP connection.  This means that we need to get IIOP messages out of the transport into the ORB protocol handlers quickly, and then allow further processing of other message to take place in Grizzly.  We do this with an implementation of the Grizzly ProtocolParser, which Harsha will describe separately in more detail. Another challenge is that IIOP treats the client and the server in very nearly the same manner. Both CORBA clients and servers need to be ready to accept almost any protocol message at any time, and respond appropriately.  This is very different from the typical HTTP client/server interaction, and this difference has caused some tension between the Grizzly and CORBA implementations.

The ORB is now running on the latest Grizzly 1.7.0.  It currently passes all CORBA unit tests, but we have not yet run the CORBA SQE tests.  We still have some final details to finish, but we will push the changes to the public GlassFish-CORBA project fairly soon (probably mid-January, as the holidays are fast upon us).

Future Work

This is a major step forward for the ORB transport.  There are two further areas that we wish to address:

1. The ORB supports the CSIv2 protocol, which extends IIOP (using tagged components and service contexts) to support secure IIOP over SSL. The current implementation uses a socket factory which is limits the SSL implementation to SSLSocket/SSLServerSocket, which are not very scalable. We'd like to migrate the CSIv2 implementation to Grizzly, which already has good SSLEngine support.
2. The current connection management in the ORB is deeply flawed and needs to be replaced. I wrote the connection cache code (which Oleksiy has integrated into Grizzly 1.5) first for the SOAP/TCP project, with the intention to use the same connection cache in CORBA.  We will, but we haven't had time to get there yet.

We plan to get these two features integrated into GlassFish v3 sometime next year.