I was thinking of using an extension of InputStream (like
NIOInputStream) because I want to be able to support non-blocking,
while being backwards compatible with older components that only
understand InputStream
My filter gets notified on each read yes, but I want an object
instance that represents the input body which I can pass on to other
components. This object should be compatible with InputStream but
also allow for org.glassfish.grizzly.ReadHandler's to be registered.
NIOInputStream is actually exactly what I need and I have it
integrated it, the primary issue I have with it is it's not public, so
currently i'm having to overwrite it's implementation locally. Any
reason we can't make this public and potentially move it to
http-framework module potentially also?
Dan
On Wed, Jun 17, 2015 at 8:02 PM, Oleksiy Stashok
<oleksiy.stashok_at_oracle.com> wrote:
> 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
>>>
>>>
>