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@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@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@dartalley.com> wrote:
>>>
>>> Have you looked into the EagerFormParsingHandler?
>>>
>>> On Sat, Feb 25, 2017 at 11:01 AM, Hicks, Matt <matt@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@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@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@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@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@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@lists.jboss.org
>>>>>>>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>>
>