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
>>>>>
>>>>>
>