Re: [undertow-dev] FormParserFactory getting stuck

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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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