Toluu

Mytec

Glassfish V3: Asynchronous HTTP responsesDecember 9 2008

We've completed integration of the latest Grizzly 1.9.0 binaries to Glassfish v3.

One of the most interesting features, which now become available in GFv3, is asynchronous HTTP responses. Recently I described, how this feature could be used with the standalone Grizzly 1.9.0. Now it is also applicable for GFv3.

To enable asynchronous HTTP responses in GFv3, we need to add following line to the domain.xml (/domain/configs/config/java-config):

<jvm-options>-Dcom.sun.grizzly.http.asyncwrite.enabled=true</jvm-options>

It's also possible to change the size of ByteBuffer pool, used for cloning ByteBuffers before asynchronous write (details). Again we can do this by adding domain.xml (/domain/configs/config/java-config) property:

<jvm-options>-Dcom.sun.grizzly.http.asyncwrite.maxBufferPoolSize=NEW_SIZE</jvm-options>

PS: This feature has been added after GFv3 Prelude release, so is currently available on GFv3 trunk only. 

Simple Grizzly 2.0December 4 2008

From time to time I see mails from people, who are looking forward to use Grizzly 2.0, but don't know where to start from. Currently we don't have much documentation on that and mainly I have to point people to unit tests code to give them some idea about Grizzly 2.0

Here I'll try to show the very simple scenario, how Grizzly 2.0 could be used. I will not show FilterChains, CallbackHandlers... nothing. I will show how Grizzly 2.0 could be used instead of plain Sockets. So, even if you have just basic understanding how Java Sockets work - you'll understand how Grizzly 2.0 could be used instead.

Why use Grizzly 2.0 instead of Sockets?

1. Grizzly 2.0 provides very simple API, based on Future,

Grizzly 1.9: ExecutorService as common thread pool interfaceDecember 4 2008

Yesterday we've released Grizzly 1.9

One of the biggest releases we had so far. Here is the announce from Jean-Francois with the complete list, what was added to the new release.

Here I'll provide more details on new Grizzly1.9 thread pool API (actually there is nothing new for those, who uses java.util.concurrent objects). Since version 1.9 we stop to support Pipeline API and move to more standard and known ExecutorService.

So, now developer should not write thread pool wrapper, based on Pipeline, in order to use custom Thread pool implementation, but directly use own ExecutorService implementation, which will be responsible for worker threads lifecycle.

ExecutorService, as thread pool API, simplifies Grizzly integration process with existing platforms/frameworks, which may have own thread pools (based on ExecutorServices) and now ar

Grizzly 1.9.0: Asynchronous HTTP responsesDecember 2 2008

In Grizzly 1.9.0, which will be released very soon, we've implemented new feature for HTTP module.

Now it is possible to send HTTP responses asynchronously without blocking a worker thread.  What does it mean and which advantages we get?

In earlier Grizzly versions, when we sent HTTP response, a current thread was blocked until whole the response will be written on network. This is fine, when response is relatively small and server is not overloaded with processing HTTP requests.

But in case, when server is under load and is not able to write HTTP response fast... We block on thread and wait, when OS will become ready to write next chunk of data on network, so write operation becomes a bottleneck for our server scalability.

In Grizzly 1.9 it is possible to leverage the advantages, proposed by Grizzly asynchronous write queue. So now, if channel can not write more data on wire, instead of blocking on a thread, we add the HTTP response message to a write queue. Asynchronous write queue will be processed, once OS will signal, that channel is available for writing.

The asynchronous mode for HTTP responses is turned off by default. So here are ways, how it could be turned on:

1) Programmatically, using SelectorThread

SelectorThread selectorThread = new SelectorThread();
selectorThread.setPort(PORT);

Grizzly 2.0: SSL supportDecember 2 2008

Recently we've added SSL support for Grizzly 2.0

Unlike Grizzly 1.x, Grizzly 2.0 doesn't have special transport, called SSL or TLS. The SSL support is implemented using new Transformer API we've introduced, which could be used either standalone or within FilterChain.

Here is brief description of classes:

SSLEncoderTransformer: encodes plaintext input Buffer into TLS/SSL encoded output Buffer.
SSLDecoderTransformer: decodes TLS/SSL encoded Buffer into plaintext data Buffer.
SSLCodec: incapsulates encoder and decoder transformers together with SSL configuration.

As I mentioned, it is possible to use SSL both in standalone and within FilterChain.

1) Standalone

In standalone mode, developer should implicitly initialize SSL connection by executing SSL handshake. Then it's possible to use Connection I/O methods: read/write to send or receive data.

Connection connection = null;

// Initiate the SSLCodec
SSLCodec sslCodec = new SSLCodec(createSSLContext());

TCPNIOTransport transport = TransportFactory.instance().createTCPTransport();
try {
transport.bind(PORT);
transport.start();

// Connect client