Hi Dan,
On 16.06.15 19:14, Daniel Feist wrote:
> 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
Well, InputStream was designed to be blocking, so not sure it's right
approach if you want to be 100% non-blocking.
> 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.
That's right, but your Filter is getting notified with HttpContent every
time there is new Buffer to read, so you can feed your output with this
Buffer.
If you want - you can share your code so I could be more specific.
Thanks.
WBR,
Alexey.
>
> 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
>>