users@grizzly.java.net

Non-Blocking Read/Write in Proxy

From: Daniel Feist <dfeist_at_gmail.com>
Date: Fri, 12 Jun 2015 10:36:16 +0100

Hi,

So i've got a non-blocking proxy running great with inbound (Grizzly)
-> outbound (ahc ->grizzly) but thats only half the story. Why?
because although no threads are blocking while waiting for a response
from the target service, I/O is still blocking because what i'm
passing from inbound->outbound is an InputStream. This is maybe not
that important with fast network and small http bodies, but with
slower networks and large bodies I believe it becomes very important.

I've had a go at implementing non-blocking read/write but hit a few
challenges and have a few questions.

- IN:REQUEST: Grizzly has the NIOInputStreamImpl which would do the
job on the inbound side, but I have the following issue. This class
is both in the server module (not much of an issue) and not public (an
issue), so can't easily be used. This is unideal but easy to work
around, my bigger problems are with outbound.

- OUT:REQUEST: I've seen the BodyGenerator and PayloadGenerator
abstractions in AHC, but from what I can see there isn't an
implementation that recognises if the the body is a
org.glassfish.grizzly.InputSource in order to perform NIO. Is this
correct? It assume it would simply be necessary implement these
interfaces. That said, there are currently no open extensions points
from what I can see.

- OUT:RESPONSE: I was stuck with this one, until after testing I
realised that onBodyPartReceived in AHC AsyncCompletionHandler is
called for every grizzly read() operation and not just for multipart
or chunked messages. I'm unsure if thats the goal of the method or if
it works with netty, but with grizzly it does. I assume I'd need to
create an instance of NIOInputStreamImpl when i receive the first
buffer within the handle implementation and return it, and then notify
listeners when with further invocations of onBodyPartReceived, I
haven't quite got my head round it or tried implementing it yet
though.

- IN:RESPONSE: I haven't looked at this yet other than considering if
grizzly should consume NIOInputStreamImpl for response or if I'd need
to convert NIOInputStreamImpl to OutputSink etc. Any thoughts?

thanks,

Dan