5:51 p.m.
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
6:34 p.m.
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
3:16 a.m.
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
11:48 a.m.
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.
Here is a sample implementation
<https://gist.github.com/miere/c2da3e8783e7db176097> with this approach.
Note: could be some typos as I've wrote this code manually to send this
mail.
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
3:30 p.m.
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
3:55 p.m.
On Aug 18, 2014, at 3: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.
The former, and it is required. We should add an example for this, but for now you can
look at ReadTimeoutTestCase to get a rough idea. Basically the pattern is:
1. Read as much as you can (loop until 0 is returned)
2. Register a listener
3. Call resumeReads (which really means resume read notifications for your listener)
Then your listener needs to:
1. Read as much data as you can
2. Process/buffer it
3. If all data is read, suspend reads, and remove the listener from the exchange,
otherwise return
It’s important that your listener be truly non-blocking, and have no possibility of
calling blocking operations (e.g. reading files, interacting with JDBC etc).
> 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
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
7:22 a.m.
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.
Jason, thanks for your clarification. I was focused on Vladmir's email
subject and I've totally forget to consider non-blocking approach.
It leads me to a question, what's the real impact on my previously
approach? I did apply a similar approach on a customer application, should
I expect serious performance issue, or maybe a possible starvation on
request peaks?
On Mon, Aug 18, 2014 at 5:55 PM, Jason Greene <jason.greene(a)redhat.com>
wrote:
On Aug 18, 2014, at 3: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.
The former, and it is required. We should add an example for this, but for
now you can look at ReadTimeoutTestCase to get a rough idea. Basically the
pattern is:
1. Read as much as you can (loop until 0 is returned)
2. Register a listener
3. Call resumeReads (which really means resume read notifications for your
listener)
Then your listener needs to:
1. Read as much data as you can
2. Process/buffer it
3. If all data is read, suspend reads, and remove the listener from the
exchange,
otherwise return
It’s important that your listener be truly non-blocking, and have no
possibility of calling blocking operations (e.g. reading files, interacting
with JDBC etc).
>
> > 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
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
12:43 a.m.
Miere Teixeira wrote:
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.
Jason, thanks for your clarification. I was focused on Vladmir's email
subject and I've totally forget to consider non-blocking approach.
It leads me to a question, what's the real impact on my previously
approach? I did apply a similar approach on a customer application,
should I expect serious performance issue, or maybe a possible
starvation on request peaks?
If you have dispatched to a worker thread it will work fine. If you are
doing it in an IO thread you can have some serious performance issues,
as other connections that the IO thread is servicing will not be handled
until the blocking operation is complete.
Stuart
On Mon, Aug 18, 2014 at 5:55 PM, Jason Greene <jason.greene(a)redhat.com
<mailto:jason.greene@redhat.com>> wrote:
On Aug 18, 2014, at 3:16 AM, Vladimir Tsukur <flushdia(a)gmail.com
<mailto:flushdia@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.
The former, and it is required. We should add an example for this,
but for now you can look at ReadTimeoutTestCase to get a rough idea.
Basically the pattern is:
1. Read as much as you can (loop until 0 is returned)
2. Register a listener
3. Call resumeReads (which really means resume read notifications
for your listener)
Then your listener needs to:
1. Read as much data as you can
2. Process/buffer it
3. If all data is read, suspend reads, and remove the listener from
the exchange,
otherwise return
It’s important that your listener be truly non-blocking, and have no
possibility of calling blocking operations (e.g. reading files,
interacting with JDBC etc).
>
> > 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 <mailto:sdouglas@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 <mailto:undertow-dev@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 <mailto:undertow-dev@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
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org <mailto:undertow-dev@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
8:02 a.m.
Thanks for the clarification Stuart,
I confused the concepts of IO Threads and Worker Threads.
On Wed, Aug 20, 2014 at 2:43 AM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
Miere Teixeira wrote:
> 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.
>
> Jason, thanks for your clarification. I was focused on Vladmir's email
> subject and I've totally forget to consider non-blocking approach.
>
> It leads me to a question, what's the real impact on my previously
> approach? I did apply a similar approach on a customer application,
> should I expect serious performance issue, or maybe a possible
> starvation on request peaks?
>
If you have dispatched to a worker thread it will work fine. If you are
doing it in an IO thread you can have some serious performance issues, as
other connections that the IO thread is servicing will not be handled until
the blocking operation is complete.
Stuart
>
>
>
> On Mon, Aug 18, 2014 at 5:55 PM, Jason Greene <jason.greene(a)redhat.com
> <mailto:jason.greene@redhat.com>> wrote:
>
>
> On Aug 18, 2014, at 3:16 AM, Vladimir Tsukur <flushdia(a)gmail.com
> <mailto:flushdia@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.
>
> The former, and it is required. We should add an example for this,
> but for now you can look at ReadTimeoutTestCase to get a rough idea.
> Basically the pattern is:
>
> 1. Read as much as you can (loop until 0 is returned)
> 2. Register a listener
> 3. Call resumeReads (which really means resume read notifications
> for your listener)
>
> Then your listener needs to:
>
> 1. Read as much data as you can
> 2. Process/buffer it
> 3. If all data is read, suspend reads, and remove the listener from
> the exchange,
> otherwise return
>
> It’s important that your listener be truly non-blocking, and have no
> possibility of calling blocking operations (e.g. reading files,
> interacting with JDBC etc).
>
> >
> > > 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 <mailto:sdouglas@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 <mailto:undertow-dev@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 <mailto:undertow-dev@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
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org <mailto:undertow-dev@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
>
3791
days inactive
3797
days old
8 comments
4 participants
participants (4)
-
Jason Greene -
Miere Teixeira -
Stuart Douglas -
Vladimir Tsukur