[undertow-dev] FormParserFactory getting stuck

Sat Feb 25 11:13:32 EST 2017

Have you looked into the EagerFormParsingHandler
<https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/handlers/form/EagerFormParsingHandler.java>
?

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(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 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/20170225/3be46ccb/attachment.html 