Hi,
No, not using server API, just transport directly. I didn't look at
Grizzly buffer because i) Ideally i want it compatible with
InputStream ii) I didn't think Buffer had any mechanism to receive
notification when there is more data to read, so not sure how you'd
implement non-blocking read with Buffer.
Dan
On Tue, Jun 16, 2015 at 5:41 PM, Oleksiy Stashok
<oleksiy.stashok_at_oracle.com> wrote:
> 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
>
>