4:14 p.m.
I'm uploading files as "multipart/form-data" and using the FormParser as
follows:
FormParserFactory.builder().build().createParser(exchange).parse(nextHandler)
Sometimes this works fine, but very often my client shows progress up to a
certain percentage complete (monitoring the AJAX request) and then just
stops and never kicks to `nextHandler`, leaves the connection just sitting
there forever, and the server seems to stop accepting any future
connections.
Any idea what might be causing this?
5:10 p.m.
- What version of Undertow?
- Is SSL in use?
- Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
- What does the stack trace look like when this happens?
Stuart
On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
I'm uploading files as "multipart/form-data" and using
the FormParser as
follows:
FormParserFactory.builder().build().createParser(exchange).parse(nextHandler)
Sometimes this works fine, but very often my client shows progress up to a
certain percentage complete (monitoring the AJAX request) and then just
stops and never kicks to `nextHandler`, leaves the connection just sitting
there forever, and the server seems to stop accepting any future
connections.
Any idea what might be causing this?
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
5:15 p.m.
1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
was a bug that was fixed, but it didn't make any difference.
2.) Yes
3.) No, of the 8 virtual CPUs none of them are maxed out.
4.) I'll have to get back to you...
On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas(a)redhat.com> wrote:
- What version of Undertow?
- Is SSL in use?
- Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
- What does the stack trace look like when this happens?
Stuart
On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
> I'm uploading files as "multipart/form-data" and using the FormParser
as
> follows:
>
>
FormParserFactory.builder().build().createParser(exchange).parse(nextHandler)
>
> Sometimes this works fine, but very often my client shows progress up to
a
> certain percentage complete (monitoring the AJAX request) and then just
> stops and never kicks to `nextHandler`, leaves the connection just
sitting
> there forever, and the server seems to stop accepting any future
> connections.
>
> Any idea what might be causing this?
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
5:18 p.m.
4.) I have three threads "runnable":
"XNIO-1 Accept@6446" prio=5 tid=0x21 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <merged>(a sun.nio.ch.EPollSelectorImpl)
- locked <merged>(a java.util.Collections$UnmodifiableSet)
- locked <merged>(a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
"XNIO-1 I/O-7@6448" prio=5 tid=0x1f nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <merged>(a sun.nio.ch.EPollSelectorImpl)
- locked <merged>(a java.util.Collections$UnmodifiableSet)
- locked <merged>(a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
"XNIO-1 I/O-3@6452" prio=5 tid=0x1b nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
- locked <0x1954> (a java.util.Collections$UnmodifiableSet)
- locked <0x1955> (a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt(a)matthicks.com> wrote:
1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping
it
was a bug that was fixed, but it didn't make any difference.
2.) Yes
3.) No, of the 8 virtual CPUs none of them are maxed out.
4.) I'll have to get back to you...
On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas(a)redhat.com>
wrote:
- What version of Undertow?
- Is SSL in use?
- Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
- What does the stack trace look like when this happens?
Stuart
On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
> I'm uploading files as "multipart/form-data" and using the FormParser
as
> follows:
>
>
FormParserFactory.builder().build().createParser(exchange).parse(nextHandler)
>
> Sometimes this works fine, but very often my client shows progress up to
a
> certain percentage complete (monitoring the AJAX request) and then just
> stops and never kicks to `nextHandler`, leaves the connection just
sitting
> there forever, and the server seems to stop accepting any future
> connections.
>
> Any idea what might be causing this?
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
7:18 p.m.
I gave it several minutes to run and finally just forcibly reloaded the
page and it spun for a few seconds like it normally does, but I waited and
eventually it threw this exception:
appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
invokeChannelListener
appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an exception
appJVM[ERROR] java.lang.IllegalStateException
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:574)
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:951)
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:948)
appJVM[ERROR] at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
appJVM[ERROR] at
org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
appJVM[ERROR] at
io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
appJVM[ERROR] at
io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
appJVM[ERROR] at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
appJVM[ERROR] at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
I don't know if it's relevant to the problem or not, but at this point I'm
just grasping for any straw.
On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt(a)matthicks.com> wrote:
4.) I have three threads "runnable":
"XNIO-1 Accept@6446" prio=5 tid=0x21 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <merged>(a sun.nio.ch.EPollSelectorImpl)
- locked <merged>(a java.util.Collections$UnmodifiableSet)
- locked <merged>(a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
"XNIO-1 I/O-7@6448" prio=5 tid=0x1f nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <merged>(a sun.nio.ch.EPollSelectorImpl)
- locked <merged>(a java.util.Collections$UnmodifiableSet)
- locked <merged>(a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
"XNIO-1 I/O-3@6452" prio=5 tid=0x1b nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
- locked <0x1954> (a java.util.Collections$UnmodifiableSet)
- locked <0x1955> (a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt(a)matthicks.com> wrote:
1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
was a bug that was fixed, but it didn't make any difference.
2.) Yes
3.) No, of the 8 virtual CPUs none of them are maxed out.
4.) I'll have to get back to you...
On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas(a)redhat.com>
wrote:
- What version of Undertow?
- Is SSL in use?
- Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
- What does the stack trace look like when this happens?
Stuart
On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
> I'm uploading files as "multipart/form-data" and using the FormParser
as
> follows:
>
>
FormParserFactory.builder().build().createParser(exchange).parse(nextHandler)
>
> Sometimes this works fine, but very often my client shows progress up to
a
> certain percentage complete (monitoring the AJAX request) and then just
> stops and never kicks to `nextHandler`, leaves the connection just
sitting
> there forever, and the server seems to stop accepting any future
> connections.
>
> Any idea what might be causing this?
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
10:01 a.m.
Well, it appears I fixed the problem. After switching to the following
code everything is working fine now:
if (exchange.isInIoThread()) {
exchange.dispatch(this);
} else {
exchange.startBlocking();
formParserBuilder.build().createParser(exchange).parseBlocking();
...
}
It's unfortunately that the non-blocking approach seems to be unreliable.
On Fri, Feb 24, 2017 at 7:18 PM Hicks, Matt <matt(a)matthicks.com> wrote:
I gave it several minutes to run and finally just forcibly reloaded
the
page and it spun for a few seconds like it normally does, but I waited and
eventually it threw this exception:
appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
invokeChannelListener
appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an
exception
appJVM[ERROR] java.lang.IllegalStateException
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:574)
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:951)
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:948)
appJVM[ERROR] at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
appJVM[ERROR] at
org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
appJVM[ERROR] at
io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
appJVM[ERROR] at
io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
appJVM[ERROR] at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
appJVM[ERROR] at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
I don't know if it's relevant to the problem or not, but at this point I'm
just grasping for any straw.
On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt(a)matthicks.com> wrote:
4.) I have three threads "runnable":
"XNIO-1 Accept@6446" prio=5 tid=0x21 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <merged>(a sun.nio.ch.EPollSelectorImpl)
- locked <merged>(a java.util.Collections$UnmodifiableSet)
- locked <merged>(a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
"XNIO-1 I/O-7@6448" prio=5 tid=0x1f nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <merged>(a sun.nio.ch.EPollSelectorImpl)
- locked <merged>(a java.util.Collections$UnmodifiableSet)
- locked <merged>(a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
"XNIO-1 I/O-3@6452" prio=5 tid=0x1b nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
- locked <0x1954> (a java.util.Collections$UnmodifiableSet)
- locked <0x1955> (a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt(a)matthicks.com> wrote:
1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
was a bug that was fixed, but it didn't make any difference.
2.) Yes
3.) No, of the 8 virtual CPUs none of them are maxed out.
4.) I'll have to get back to you...
On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas(a)redhat.com>
wrote:
- What version of Undertow?
- Is SSL in use?
- Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
- What does the stack trace look like when this happens?
Stuart
On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
> I'm uploading files as "multipart/form-data" and using the FormParser
as
> follows:
>
>
FormParserFactory.builder().build().createParser(exchange).parse(nextHandler)
>
> Sometimes this works fine, but very often my client shows progress up to
a
> certain percentage complete (monitoring the AJAX request) and then just
> stops and never kicks to `nextHandler`, leaves the connection just
sitting
> there forever, and the server seems to stop accepting any future
> connections.
>
> Any idea what might be causing this?
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
10:13 a.m.
Have you looked into the EagerFormParsingHandler
<https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
?
On Sat, Feb 25, 2017 at 11:01 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
Well, it appears I fixed the problem. After switching to the
following
code everything is working fine now:
if (exchange.isInIoThread()) {
exchange.dispatch(this);
} else {
exchange.startBlocking();
formParserBuilder.build().createParser(exchange).parseBlocking();
...
}
It's unfortunately that the non-blocking approach seems to be unreliable.
On Fri, Feb 24, 2017 at 7:18 PM Hicks, Matt <matt(a)matthicks.com> wrote:
> I gave it several minutes to run and finally just forcibly reloaded the
> page and it spun for a few seconds like it normally does, but I waited and
> eventually it threw this exception:
>
> appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
> invokeChannelListener
> appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an
> exception
> appJVM[ERROR] java.lang.IllegalStateException
> appJVM[ERROR] at io.undertow.server.protocol.framed.
> AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChanne
> l.java:574)
> appJVM[ERROR] at io.undertow.server.protocol.
> framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
> appJVM[ERROR] at io.undertow.server.protocol.
> framed.AbstractFramedChannel$FrameWriteListener.handleEvent(
> AbstractFramedChannel.java:951)
> appJVM[ERROR] at io.undertow.server.protocol.
> framed.AbstractFramedChannel$FrameWriteListener.handleEvent(
> AbstractFramedChannel.java:948)
> appJVM[ERROR] at org.xnio.ChannelListeners.invokeChannelListener(
> ChannelListeners.java:92)
> appJVM[ERROR] at org.xnio.conduits.WriteReadyHandler$
> ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> appJVM[ERROR] at io.undertow.protocols.ssl.SslConduit$
> SslWriteReadyHandler.writeReady(SslConduit.java:1225)
> appJVM[ERROR] at io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.
> java:275)
> appJVM[ERROR] at org.xnio.nio.WorkerThread.
> safeRun(WorkerThread.java:580)
> appJVM[ERROR] at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
>
> I don't know if it's relevant to the problem or not, but at this point
> I'm just grasping for any straw.
>
> On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt(a)matthicks.com> wrote:
>
> 4.) I have three threads "runnable":
>
> "XNIO-1 Accept@6446" prio=5 tid=0x21 nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
> - locked <merged>(a java.util.Collections$UnmodifiableSet)
> - locked <merged>(a sun.nio.ch.Util$3)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
> "XNIO-1 I/O-7@6448" prio=5 tid=0x1f nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
> - locked <merged>(a java.util.Collections$UnmodifiableSet)
> - locked <merged>(a sun.nio.ch.Util$3)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
> "XNIO-1 I/O-3@6452" prio=5 tid=0x1b nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
> - locked <0x1954> (a java.util.Collections$UnmodifiableSet)
> - locked <0x1955> (a sun.nio.ch.Util$3)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
>
>
> On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt(a)matthicks.com> wrote:
>
> 1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
> was a bug that was fixed, but it didn't make any difference.
> 2.) Yes
> 3.) No, of the 8 virtual CPUs none of them are maxed out.
> 4.) I'll have to get back to you...
>
> On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas(a)redhat.com>
> wrote:
>
> - What version of Undertow?
> - Is SSL in use?
> - Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
> - What does the stack trace look like when this happens?
>
> Stuart
>
> On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
> > I'm uploading files as "multipart/form-data" and using the
FormParser as
> > follows:
> >
> > FormParserFactory.builder().build().createParser(exchange)
> .parse(nextHandler)
> >
> > Sometimes this works fine, but very often my client shows progress up
> to a
> > certain percentage complete (monitoring the AJAX request) and then just
> > stops and never kicks to `nextHandler`, leaves the connection just
> sitting
> > there forever, and the server seems to stop accepting any future
> > connections.
> >
> > Any idea what might be causing this?
> >
> > _______________________________________________
> > 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
11:06 a.m.
Thanks for the response Bill, but that's almost verbatim what I was already
doing and it was sometimes not working and getting stuck.
On Sat, Feb 25, 2017 at 10:13 AM Bill O'Neil <bill(a)dartalley.com> wrote:
Have you looked into the EagerFormParsingHandler
<https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
?
On Sat, Feb 25, 2017 at 11:01 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
Well, it appears I fixed the problem. After switching to the following
code everything is working fine now:
if (exchange.isInIoThread()) {
exchange.dispatch(this);
} else {
exchange.startBlocking();
formParserBuilder.build().createParser(exchange).parseBlocking();
...
}
It's unfortunately that the non-blocking approach seems to be unreliable.
On Fri, Feb 24, 2017 at 7:18 PM Hicks, Matt <matt(a)matthicks.com> wrote:
I gave it several minutes to run and finally just forcibly reloaded the
page and it spun for a few seconds like it normally does, but I waited and
eventually it threw this exception:
appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
invokeChannelListener
appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an
exception
appJVM[ERROR] java.lang.IllegalStateException
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:574)
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:951)
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:948)
appJVM[ERROR] at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
appJVM[ERROR] at
org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
appJVM[ERROR] at
io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
appJVM[ERROR] at
io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
appJVM[ERROR] at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
appJVM[ERROR] at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
I don't know if it's relevant to the problem or not, but at this point I'm
just grasping for any straw.
On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt(a)matthicks.com> wrote:
4.) I have three threads "runnable":
"XNIO-1 Accept@6446" prio=5 tid=0x21 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <merged>(a sun.nio.ch.EPollSelectorImpl)
- locked <merged>(a java.util.Collections$UnmodifiableSet)
- locked <merged>(a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
"XNIO-1 I/O-7@6448" prio=5 tid=0x1f nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <merged>(a sun.nio.ch.EPollSelectorImpl)
- locked <merged>(a java.util.Collections$UnmodifiableSet)
- locked <merged>(a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
"XNIO-1 I/O-3@6452" prio=5 tid=0x1b nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
- locked <0x1954> (a java.util.Collections$UnmodifiableSet)
- locked <0x1955> (a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt(a)matthicks.com> wrote:
1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
was a bug that was fixed, but it didn't make any difference.
2.) Yes
3.) No, of the 8 virtual CPUs none of them are maxed out.
4.) I'll have to get back to you...
On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas(a)redhat.com>
wrote:
- What version of Undertow?
- Is SSL in use?
- Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
- What does the stack trace look like when this happens?
Stuart
On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
> I'm uploading files as "multipart/form-data" and using the FormParser
as
> follows:
>
>
FormParserFactory.builder().build().createParser(exchange).parse(nextHandler)
>
> Sometimes this works fine, but very often my client shows progress up to
a
> certain percentage complete (monitoring the AJAX request) and then just
> stops and never kicks to `nextHandler`, leaves the connection just
sitting
> there forever, and the server seems to stop accepting any future
> connections.
>
> Any idea what might be causing this?
>
> _______________________________________________
> 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
12:12 p.m.
It just occurred to me this might be related to me using HTTP2. I was also
experiencing both client and server errors loading resources (audio and
video). I just turned off HTTP2 and now I'm not experiencing any errors at
all. I haven't tried switching back to asynchronous parsing of
multipart/form-data yet though.
On Sat, Feb 25, 2017 at 11:06 AM Hicks, Matt <matt(a)matthicks.com> wrote:
Thanks for the response Bill, but that's almost verbatim what I
was
already doing and it was sometimes not working and getting stuck.
On Sat, Feb 25, 2017 at 10:13 AM Bill O'Neil <bill(a)dartalley.com> wrote:
Have you looked into the EagerFormParsingHandler
<https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
?
On Sat, Feb 25, 2017 at 11:01 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
Well, it appears I fixed the problem. After switching to the following
code everything is working fine now:
if (exchange.isInIoThread()) {
exchange.dispatch(this);
} else {
exchange.startBlocking();
formParserBuilder.build().createParser(exchange).parseBlocking();
...
}
It's unfortunately that the non-blocking approach seems to be unreliable.
On Fri, Feb 24, 2017 at 7:18 PM Hicks, Matt <matt(a)matthicks.com> wrote:
I gave it several minutes to run and finally just forcibly reloaded the
page and it spun for a few seconds like it normally does, but I waited and
eventually it threw this exception:
appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
invokeChannelListener
appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an
exception
appJVM[ERROR] java.lang.IllegalStateException
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:574)
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:951)
appJVM[ERROR] at
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:948)
appJVM[ERROR] at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
appJVM[ERROR] at
org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
appJVM[ERROR] at
io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
appJVM[ERROR] at
io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
appJVM[ERROR] at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
appJVM[ERROR] at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
I don't know if it's relevant to the problem or not, but at this point I'm
just grasping for any straw.
On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt(a)matthicks.com> wrote:
4.) I have three threads "runnable":
"XNIO-1 Accept@6446" prio=5 tid=0x21 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <merged>(a sun.nio.ch.EPollSelectorImpl)
- locked <merged>(a java.util.Collections$UnmodifiableSet)
- locked <merged>(a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
"XNIO-1 I/O-7@6448" prio=5 tid=0x1f nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <merged>(a sun.nio.ch.EPollSelectorImpl)
- locked <merged>(a java.util.Collections$UnmodifiableSet)
- locked <merged>(a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
"XNIO-1 I/O-3@6452" prio=5 tid=0x1b nid=NA runnable
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
- locked <0x1954> (a java.util.Collections$UnmodifiableSet)
- locked <0x1955> (a sun.nio.ch.Util$3)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt(a)matthicks.com> wrote:
1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
was a bug that was fixed, but it didn't make any difference.
2.) Yes
3.) No, of the 8 virtual CPUs none of them are maxed out.
4.) I'll have to get back to you...
On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas(a)redhat.com>
wrote:
- What version of Undertow?
- Is SSL in use?
- Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
- What does the stack trace look like when this happens?
Stuart
On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
> I'm uploading files as "multipart/form-data" and using the FormParser
as
> follows:
>
>
FormParserFactory.builder().build().createParser(exchange).parse(nextHandler)
>
> Sometimes this works fine, but very often my client shows progress up to
a
> certain percentage complete (monitoring the AJAX request) and then just
> stops and never kicks to `nextHandler`, leaves the connection just
sitting
> there forever, and the server seems to stop accepting any future
> connections.
>
> Any idea what might be causing this?
>
> _______________________________________________
> 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
3:33 p.m.
This does sound like a h2 issue. Do you have a reliable way or
reproducing it that I can debug?
Stuart
On Sun, Feb 26, 2017 at 5:12 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
It just occurred to me this might be related to me using HTTP2. I
was also
experiencing both client and server errors loading resources (audio and
video). I just turned off HTTP2 and now I'm not experiencing any errors at
all. I haven't tried switching back to asynchronous parsing of
multipart/form-data yet though.
On Sat, Feb 25, 2017 at 11:06 AM Hicks, Matt <matt(a)matthicks.com> wrote:
>
> Thanks for the response Bill, but that's almost verbatim what I was
> already doing and it was sometimes not working and getting stuck.
>
> On Sat, Feb 25, 2017 at 10:13 AM Bill O'Neil <bill(a)dartalley.com> wrote:
>>
>> Have you looked into the EagerFormParsingHandler?
>>
>> On Sat, Feb 25, 2017 at 11:01 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
>>>
>>> Well, it appears I fixed the problem. After switching to the following
>>> code everything is working fine now:
>>>
>>> if (exchange.isInIoThread()) {
>>> exchange.dispatch(this);
>>> } else {
>>> exchange.startBlocking();
>>> formParserBuilder.build().createParser(exchange).parseBlocking();
>>> ...
>>> }
>>>
>>> It's unfortunately that the non-blocking approach seems to be
>>> unreliable.
>>>
>>> On Fri, Feb 24, 2017 at 7:18 PM Hicks, Matt <matt(a)matthicks.com>
wrote:
>>>>
>>>> I gave it several minutes to run and finally just forcibly reloaded the
>>>> page and it spun for a few seconds like it normally does, but I waited
and
>>>> eventually it threw this exception:
>>>>
>>>> appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
>>>> invokeChannelListener
>>>> appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an
>>>> exception
>>>> appJVM[ERROR] java.lang.IllegalStateException
>>>> appJVM[ERROR] at
>>>>
io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:574)
>>>> appJVM[ERROR] at
>>>>
io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
>>>> appJVM[ERROR] at
>>>>
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:951)
>>>> appJVM[ERROR] at
>>>>
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:948)
>>>> appJVM[ERROR] at
>>>>
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
>>>> appJVM[ERROR] at
>>>>
org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
>>>> appJVM[ERROR] at
>>>>
io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
>>>> appJVM[ERROR] at
>>>> io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
>>>> appJVM[ERROR] at
>>>> org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
>>>> appJVM[ERROR] at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
>>>>
>>>> I don't know if it's relevant to the problem or not, but at this
point
>>>> I'm just grasping for any straw.
>>>>
>>>> On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt(a)matthicks.com>
wrote:
>>>>>
>>>>> 4.) I have three threads "runnable":
>>>>>
>>>>> "XNIO-1 Accept@6446" prio=5 tid=0x21 nid=NA runnable
>>>>> java.lang.Thread.State: RUNNABLE
>>>>> at
sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>>>>> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>>>>> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>>>>> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>>>>> - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>>>>> - locked <merged>(a java.util.Collections$UnmodifiableSet)
>>>>> - locked <merged>(a sun.nio.ch.Util$3)
>>>>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>>>>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>>>>> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>>>>>
>>>>> "XNIO-1 I/O-7@6448" prio=5 tid=0x1f nid=NA runnable
>>>>> java.lang.Thread.State: RUNNABLE
>>>>> at
sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>>>>> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>>>>> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>>>>> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>>>>> - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>>>>> - locked <merged>(a java.util.Collections$UnmodifiableSet)
>>>>> - locked <merged>(a sun.nio.ch.Util$3)
>>>>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>>>>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>>>>> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>>>>>
>>>>> "XNIO-1 I/O-3@6452" prio=5 tid=0x1b nid=NA runnable
>>>>> java.lang.Thread.State: RUNNABLE
>>>>> at
sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>>>>> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>>>>> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>>>>> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>>>>> - locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
>>>>> - locked <0x1954> (a java.util.Collections$UnmodifiableSet)
>>>>> - locked <0x1955> (a sun.nio.ch.Util$3)
>>>>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>>>>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>>>>> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt
<matt(a)matthicks.com>
>>>>> wrote:
>>>>>>
>>>>>> 1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final
hoping
>>>>>> it was a bug that was fixed, but it didn't make any
difference.
>>>>>> 2.) Yes
>>>>>> 3.) No, of the 8 virtual CPUs none of them are maxed out.
>>>>>> 4.) I'll have to get back to you...
>>>>>>
>>>>>> On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas
<sdouglas(a)redhat.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> - What version of Undertow?
>>>>>>> - Is SSL in use?
>>>>>>> - Does the server enter some kind of spin loop (i.e. 100%
CPU
>>>>>>> usage)?
>>>>>>> - What does the stack trace look like when this happens?
>>>>>>>
>>>>>>> Stuart
>>>>>>>
>>>>>>> On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt
<matt(a)matthicks.com>
>>>>>>> wrote:
>>>>>>> > I'm uploading files as
"multipart/form-data" and using the
>>>>>>> > FormParser as
>>>>>>> > follows:
>>>>>>> >
>>>>>>> >
>>>>>>> >
FormParserFactory.builder().build().createParser(exchange).parse(nextHandler)
>>>>>>> >
>>>>>>> > Sometimes this works fine, but very often my client
shows progress
>>>>>>> > up to a
>>>>>>> > certain percentage complete (monitoring the AJAX
request) and then
>>>>>>> > just
>>>>>>> > stops and never kicks to `nextHandler`, leaves the
connection just
>>>>>>> > sitting
>>>>>>> > there forever, and the server seems to stop accepting
any future
>>>>>>> > connections.
>>>>>>> >
>>>>>>> > Any idea what might be causing this?
>>>>>>> >
>>>>>>> > _______________________________________________
>>>>>>> > 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
>>
>>
9:51 a.m.
Unfortunately not, but my scenario itself was fairly simple. I was just
creating a FormData instance in JavaScript that had a few values including
a file and then sending it via AJAX POST to the server as
multipart/form-data.
On Sun, Feb 26, 2017 at 3:33 PM Stuart Douglas <sdouglas(a)redhat.com> wrote:
This does sound like a h2 issue. Do you have a reliable way or
reproducing it that I can debug?
Stuart
On Sun, Feb 26, 2017 at 5:12 AM, Hicks, Matt <matt(a)matthicks.com> wrote:
> It just occurred to me this might be related to me using HTTP2. I was
also
> experiencing both client and server errors loading resources (audio and
> video). I just turned off HTTP2 and now I'm not experiencing any errors
at
> all. I haven't tried switching back to asynchronous parsing of
> multipart/form-data yet though.
>
> On Sat, Feb 25, 2017 at 11:06 AM Hicks, Matt <matt(a)matthicks.com> wrote:
>>
>> Thanks for the response Bill, but that's almost verbatim what I was
>> already doing and it was sometimes not working and getting stuck.
>>
>> On Sat, Feb 25, 2017 at 10:13 AM Bill O'Neil <bill(a)dartalley.com>
wrote:
>>>
>>> Have you looked into the EagerFormParsingHandler?
>>>
>>> On Sat, Feb 25, 2017 at 11:01 AM, Hicks, Matt <matt(a)matthicks.com>
wrote:
>>>>
>>>> Well, it appears I fixed the problem. After switching to the
following
>>>> code everything is working fine now:
>>>>
>>>> if (exchange.isInIoThread()) {
>>>> exchange.dispatch(this);
>>>> } else {
>>>> exchange.startBlocking();
>>>> formParserBuilder.build().createParser(exchange).parseBlocking();
>>>> ...
>>>> }
>>>>
>>>> It's unfortunately that the non-blocking approach seems to be
>>>> unreliable.
>>>>
>>>> On Fri, Feb 24, 2017 at 7:18 PM Hicks, Matt <matt(a)matthicks.com>
wrote:
>>>>>
>>>>> I gave it several minutes to run and finally just forcibly reloaded
the
>>>>> page and it spun for a few seconds like it normally does, but I
waited and
>>>>> eventually it threw this exception:
>>>>>
>>>>> appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
>>>>> invokeChannelListener
>>>>> appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an
>>>>> exception
>>>>> appJVM[ERROR] java.lang.IllegalStateException
>>>>> appJVM[ERROR] at
>>>>>
io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:574)
>>>>> appJVM[ERROR] at
>>>>>
io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
>>>>> appJVM[ERROR] at
>>>>>
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:951)
>>>>> appJVM[ERROR] at
>>>>>
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:948)
>>>>> appJVM[ERROR] at
>>>>>
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
>>>>> appJVM[ERROR] at
>>>>>
org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
>>>>> appJVM[ERROR] at
>>>>>
io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
>>>>> appJVM[ERROR] at
>>>>> io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
>>>>> appJVM[ERROR] at
>>>>> org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
>>>>> appJVM[ERROR] at
org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
>>>>>
>>>>> I don't know if it's relevant to the problem or not, but at
this
point
>>>>> I'm just grasping for any straw.
>>>>>
>>>>> On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt
<matt(a)matthicks.com>
wrote:
>>>>>>
>>>>>> 4.) I have three threads "runnable":
>>>>>>
>>>>>> "XNIO-1 Accept@6446" prio=5 tid=0x21 nid=NA runnable
>>>>>> java.lang.Thread.State: RUNNABLE
>>>>>> at
sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>>>>>> at
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>>>>>> at
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>>>>>> at
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>>>>>> - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>>>>>> - locked <merged>(a
java.util.Collections$UnmodifiableSet)
>>>>>> - locked <merged>(a sun.nio.ch.Util$3)
>>>>>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>>>>>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>>>>>> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>>>>>>
>>>>>> "XNIO-1 I/O-7@6448" prio=5 tid=0x1f nid=NA runnable
>>>>>> java.lang.Thread.State: RUNNABLE
>>>>>> at
sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>>>>>> at
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>>>>>> at
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>>>>>> at
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>>>>>> - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>>>>>> - locked <merged>(a
java.util.Collections$UnmodifiableSet)
>>>>>> - locked <merged>(a sun.nio.ch.Util$3)
>>>>>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>>>>>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>>>>>> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>>>>>>
>>>>>> "XNIO-1 I/O-3@6452" prio=5 tid=0x1b nid=NA runnable
>>>>>> java.lang.Thread.State: RUNNABLE
>>>>>> at
sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>>>>>> at
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>>>>>> at
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>>>>>> at
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>>>>>> - locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
>>>>>> - locked <0x1954> (a
java.util.Collections$UnmodifiableSet)
>>>>>> - locked <0x1955> (a sun.nio.ch.Util$3)
>>>>>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>>>>>> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>>>>>> at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt
<matt(a)matthicks.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> 1.) I was running 1.4.10.Final, but I upgraded to
1.4.11.Final
hoping
>>>>>>> it was a bug that was fixed, but it didn't make any
difference.
>>>>>>> 2.) Yes
>>>>>>> 3.) No, of the 8 virtual CPUs none of them are maxed out.
>>>>>>> 4.) I'll have to get back to you...
>>>>>>>
>>>>>>> On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <
sdouglas(a)redhat.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> - What version of Undertow?
>>>>>>>> - Is SSL in use?
>>>>>>>> - Does the server enter some kind of spin loop (i.e.
100% CPU
>>>>>>>> usage)?
>>>>>>>> - What does the stack trace look like when this
happens?
>>>>>>>>
>>>>>>>> Stuart
>>>>>>>>
>>>>>>>> On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt
<matt(a)matthicks.com>
>>>>>>>> wrote:
>>>>>>>> > I'm uploading files as
"multipart/form-data" and using the
>>>>>>>> > FormParser as
>>>>>>>> > follows:
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
FormParserFactory.builder().build().createParser(exchange).parse(nextHandler)
>>>>>>>> >
>>>>>>>> > Sometimes this works fine, but very often my client
shows
progress
>>>>>>>> > up to a
>>>>>>>> > certain percentage complete (monitoring the AJAX
request) and
then
>>>>>>>> > just
>>>>>>>> > stops and never kicks to `nextHandler`, leaves the
connection
just
>>>>>>>> > sitting
>>>>>>>> > there forever, and the server seems to stop
accepting any future
>>>>>>>> > connections.
>>>>>>>> >
>>>>>>>> > Any idea what might be causing this?
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > 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
>>>
>>>
>
2898
days inactive
2901
days old
10 comments
3 participants
participants (3)
-
Bill O'Neil -
Hicks, Matt -
Stuart Douglas