[undertow-dev] Reading request body parsed/buffered by RequestBufferingHandler

[Girish Sharma]

Got it, thanks!

I implemented and tested out all three approaches and found that the
RequestBufferingHandler is the most efficient (even if it consumes 2-3%
higher CPU usage than the request receiver approach).

Regards.


On Wed, Jul 4, 2018 at 5:05 AM Stuart Douglas <sdouglas at redhat.com> wrote:

>
>
> On Tue, Jul 3, 2018 at 8:15 PM Girish Sharma <scrapmachines at gmail.com>
> wrote:
>
>> Hi Stuart,
>>
>> Thanks for getting back to me. I have some comments below:
>>
>> You just read it as normal
>>>
>>  I am assuming that by normal, you mean the
>>
>> exchange.startBlocking() + (InputStream stream =
>> exchange.getInputStream())
>>
>> approach to read the input stream? But then what benefit we get here as
>> compared to not using the RequestBufferingHandler and directly using this
>> approach? Is the following loop (typically used in reading input stream)
>> going to be much more efficient?:
>>
>
> Say you have a slow mobile client that takes 2s to upload its request.
> Without the request buffering handler the worker thread will be blocked for
> 2s. If you have lots of these slow clients you could exhaust the worker
> thread pool, causing request to queue and generally decreasing performance.
> If you use the request buffering handler the worker thread will not start
> work until after the data has been read, so it does not block on IO.
>
> Stuart
>
>
>
>>
>> while ((line = bufferedReader.readLine()) != null) {
>>     stringBuffer.append(line);
>> }
>>
>> Regards
>>
>>
>> On Tue, Jul 3, 2018 at 6:34 AM Stuart Douglas <sdouglas at redhat.com>
>> wrote:
>>
>>> You just read it as normal. The advantage is that if you are going to
>>> dispatch to a worker thread then the dispatch does not happen until the
>>> request has been read, thus reducing the amount of time a worker spends
>>> processing the request. Essentially this allows you to take advantage of
>>> non-blocking IO even for applications that use blocking IO, but at the
>>> expense of memory for buffering.
>>>
>>> Stuart
>>>
>>> On Mon, Jul 2, 2018 at 8:55 PM Girish Sharma <scrapmachines at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I tried searching around in github/stackexchange but could not find
>>>> anything related to RequestBufferingHandler.
>>>>
>>>> I understand that RequestBufferingHandler would read the request body
>>>> for me and then call the handler assigned as the next handler. But how does
>>>> the next handler read the buffered request body?
>>>>
>>>> Looking around the code of RequestBufferingHandler, I see that it adds
>>>> an attachment to the exchange, but the key for that attachment is protected
>>>> to the undertow package.
>>>>
>>>> How can I read the value of that attachment? Or is there some other way
>>>> to read the buffered request body?
>>>>
>>>> PS: I know the alternate approach of reading request body i.e
>>>> startBlocking + getInputStream and getRequestReceiver().receiveFullString ,
>>>> but I am interested in using the RequestBufferingHandler in particular.
>>>>
>>>> --
>>>> Girish Sharma
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>>
>>
>> --
>> Girish Sharma
>> B.Tech(H), Civil Engineering,
>> Indian Institute of Technology, Kharagpur
>>
>

-- 
Girish Sharma
B.Tech(H), Civil Engineering,
Indian Institute of Technology, Kharagpur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180704/3070da72/attachment-0001.html