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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev