"Grizzly 1.7.0 presents"... Part I: Asynchronous write queues

Finanlly Grizzly 1.7.0 is released and we have implemented feature, which was asked long time ago: Asyncronous write queues.

Before it was possible to use async. NIO nature in Grizzly, but developer needed to implement and control such queue himself. Or as alternative write operation could be done in blocking manner: OutputWriter.flushChannel(...).

With newly implemented Async. write queue it's possible to register ByteBuffer for writing and get notification via a callback listener, when ByteBuffer will be written. Also it's possible together with ByteBuffer register some custom ByteBuffer Processor, which will be called before writing ByteBuffer, and will be able to process/change/encrypt ByteBuffer data before writing it on a wire. Grizzly itself uses ByteBuffer Processor for SSL Async. write queue implementation.

Async. write queue API is represented by the interface com.sun.grizzly.async.AsyncQueueWritable.

Grizzly client side connector handlers: TCPConnectorHandler, UDPConnectorHandler, SSLConnectorHandler, implement AsyncQueueWritable interface. However it's possible to use Async. write queue functionality inside ProtocolFilter - Context.getAsyncQueueWritable().

What are the features Async. write queue API proposes?

1) public void writeToAsyncQueue(ByteBuffer buffer) throws IOException;

Just register buffer on a write queue. Completion notification is not needed.

2) public void writeToAsyncQueue(ByteBuffer buffer, AsyncWriteCallbackHandler callbackHandler) throws IOException;

Registers buffer on a write queue, and provides callback handler, which will be notified on buffer write completion, or if any error will happen during buffer write operation.

3) public void writeToAsyncQueue(ByteBuffer buffer, AsyncWriteCallbackHandler callbackHandler, AsyncQueueDataProcessor writePreProcessor) throws IOException;

Does the same as (2), but also registers buffer associated writePreProcessor, which will be called, for buffer, when it comes its turn to be written. WritePreProcessor can change buffer content, can substitute buffer with different one. I found this feature useful, when implemented SSL async. write queue support. So I'm registering buffer with raw data, and SSLWritePreProcessor, which is called before buffer is going to be written and encrypts buffer's content according to SSL requirements.

4) public void writeToAsyncQueue(ByteBuffer buffer, AsyncWriteCallbackHandler callbackHandler, AsyncQueueDataProcessor writePreProcessor, boolean isCloneByteBuffer) throws IOException;

Method extends functionality of (3), by adding possibility to clone source buffer before adding it to a queue, so actually buffer clone will be added to a queue. "Cloning" could be useful for situations, when we don't want to care much about memory management. So it's possible to call this method with clone set to "true", and continue to work with the passed buffer (clear it, modify...) on next step.

But for better memory management, I would suggest to not use cloning, and release allocated buffer using AsyncWriteCallbackHandler.

There are other operations, provided with API, which are similar to (1)-(4), but has one more parameter: SocketAddress dstAddress. These operations are not supported for TCP, SSL transports, as they always implemented using connected channels, but with UDP transport, where channel could be not connected, it's possible to set destination address, where buffer will be sent.

\*If queue is empty, all write operations first try to write buffer directly to the destination channel on the same thread.

 
Looking forward to hear feedback, so we will be able to fix/improve our current implementation :)
Next time I'll try to describe Grizzly Asynchronous  read queue feature...

Comments:

Hi
I am trying to use this feature. I am driving the server (TCP) using the following driver:

class Client {
..
final static String msg = "Hello Client how are things!!!";
TCPIOClient client = new TCPIOClient(HOST, PORT);
for (int i = 0; i < 1000; ++i) {
System.out.println("i = " + i);
client.send(msg.getBytes());
// byte[] response = new byte[msg.getBytes().length + "<>".getBytes().length];
client.receive(response);
System.out.println("Response is " + new String(response));
}

The server hangs after returning the 5th message...

Is using TCPIOClient (form grizzly source) ok with this? The initial messages are coming fine so I think it should not be a problem.

-- thx atul

Posted by atul khot on March 04, 2008 at 03:04 AM CET #

That's strange.
Can you please fill the issue at
https://grizzly.dev.java.net. And attach complete client and server sources.

Thanks.

Posted by oleksiys on March 26, 2008 at 04:39 AM CET #

Hi,

Did you ever post the async read atricle?

>>Next time I'll try to describe
>>Grizzly Asynchronous read queue
>>feature...

Kind Regards
Pete

Posted by Pete on October 13, 2008 at 02:16 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

oleksiys

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today