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 invokeChannelListenerappJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an exceptionappJVM[ERROR] java.lang.IllegalStateExceptionappJVM[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 runnablejava.lang.Thread.State: RUNNABLEat 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 runnablejava.lang.Thread.State: RUNNABLEat 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 runnablejava.lang.Thread.State: RUNNABLEat 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.) Yes3.) 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