?
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