> - 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.
Right, AHC uses different abstractions, for non-blocking AHC feeding you can use NonBlockingFeeder.
Please take a look at the sample
https://github.com/AsyncHttpClient/async-http-client/blob/1.9.x/src/test/java/com/ning/http/client/async/grizzly/GrizzlyFeedableBodyGeneratorTest.java#L210
>
> - 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.
Yes, this body part is not related to chunking or multipart, it's just a body part Grizzly was able to read from network.
Not sure why you'd like to put this into NIOInputStreamImpl, do you want to buffer the response?
> - 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?
Hmm, potentially we can implement some utility to convert NIOInputStream input to NIOOutputStream output. But in your case let's figure out if you really need this.
Thanks.
WBR,
Alexey.
On 19.06.15 19:18, Daniel Feist wrote:
> Yes NIOInputStreamImpl, sorry.
>
> BTW, any thoughts on the other outbound/AHC pieces of this I mentioned
> in my first email?
>
> Dan
>
> On Fri, Jun 19, 2015 at 6:14 PM, Oleksiy Stashok
> <oleksiy.stashok_at_oracle.com> wrote:
>> Hi Dan,
>>
>> you mean NIOInputStreamImpl implementation is not public, because
>> NIOInputStream is public at least in 2.3.x.
>>
>> WBR,
>> Alexey.
>>
>>
>> On 17.06.15 21:51, Daniel Feist wrote:
>>> 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
>>>>>>