Oracle Blog

Enterprise Java and CORBA

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:

Grizzly has very good performance already.

Grizzly has a very active user community, which helps to ensure a high-quality implementation.

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.

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:

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.

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.