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