On Aug 18, 2014, at 11:48 AM, Miere Teixeira <miere.teixeira(a)gmail.com> wrote:
Hi Vladmir,
I've faced the same problem before, but reading each byte manually didn't fit my
needs.
When the JDK 1.4 released Java NIO API, they have already created a common way to
read data with less development effort, I'm talking about java.nio.channels.Channels
class, which
has many helper methods able to convert data from old IO API to NIO API.
My prefered method is Channels.newReader. This method is able to convert a
StreamSourceChannel
to a lightweight Reader implementation. I like this method because many object
marshallers are
ready to handle Java IO Reader implementations.
This method doesn’t support non-blocking channels, so can’t be used in a non-blocking
handler. You can, however, just use getInputStream after putting the exchange in blocking
mode.
Here is a sample implementation with this approach.
Note: could be some typos as I've wrote this code manually to send this mail.
While I am not aware of any non-blocking JSON parsers, it would be possible to build an
event based JSON parser, which dispatches to non-blocking handlers to take action.
I really hope it helps you.
Please Undertow devs let me know If I'm missing some important point on this.
Regards.
On Mon, Aug 18, 2014 at 5:16 AM, Vladimir Tsukur <flushdia(a)gmail.com> wrote:
Thanks for explaining the option with getRequestChannel! Got it working by reading
content into a pre-allocated ByteBuffer.
if it returns 0 register a read listener and call resumeReads()
One thing I don't fully understand though is your note about registering a read
listener (+ calling resumeReads) and why this is needed. Is it a mandatory step, and if it
is, are you referring to application-specific read listener or Undertow's
io.undertow.server.protocol.http.HttpReadListener? I guess this is pretty basic question,
so it would be great if you can just point me to the right place at documentation, so that
I can figure it out.
Thinking about it we probably just need some way to buffer a complete/partial message and
then invoke a callback with the data.
Yep, I guess this would be easier for the app developer to use.
On Mon, Aug 18, 2014 at 2:34 AM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
You can use the getRequestChannel() method to get the request channel. Basically call
read() on the channel till it returns either 0 or -1, if it returns -1 you are done, if it
returns 0 register a read listener and call resumeReads().
I have always been meaning to add a nicer non-blocking API for this, but I have never
been exactly sure what would be required here. Thinking about it we probably just need
some way to buffer a complete/partial message and then invoke a callback with the data.
Stuart
Vladimir Tsukur wrote:
One of the ways to obtain request entity is to call
HttpServerExchange.startBlocking and then read content from the
HttpServerExchange.getInputStream.
Is there a way to obtain request entity in a non-blocking way?
--
Vladimir Tsukur
Software Architect, Design Engineer and Scrum Master
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
--
Vladimir Tsukur
Software Architect, Design Engineer and Scrum Master
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat