[undertow-dev] FormParserFactory getting stuck

Hicks, Matt matt at matthicks.com
Mon Feb 27 10:51:42 EST 2017 

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 at 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 at 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 at 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 at dartalley.com>
> wrote:
> >>>
> >>> Have you looked into the EagerFormParsingHandler?
> >>>
> >>> On Sat, Feb 25, 2017 at 11:01 AM, Hicks, Matt <matt at 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 at 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 at matthicks.com>
> wrote:
> >>>>>>
> >>>>>> 4.) I have three threads "runnable":
> >>>>>>
> >>>>>> "XNIO-1 Accept at 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 at 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 at 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 at 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 at 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 at 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 at lists.jboss.org
> >>>>>>>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> undertow-dev mailing list
> >>>> undertow-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>
> >>>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170227/32de1906/attachment.html

More information about the undertow-dev mailing list