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> 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> 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(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> 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