Hi Daniel,
do you use HttpServer API on the server side, or implement it as plain
Transport <-> SSLFilter (if needed) <-> HttpServerFilter (codec)
FilterChain?
I don't think you have to use InputBuffer or OutputSink as data holder
to pass from server to client. Why not use Grizzly Buffer?
WBR,
Alexey.
On 12.06.15 11:36, Daniel Feist wrote:
> 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