From electrotype at gmail.com Tue Aug 2 22:34:03 2016 From: electrotype at gmail.com (electrotype) Date: Tue, 2 Aug 2016 22:34:03 -0400 Subject: [undertow-dev] StackOverflowError on AbstractFramedChannel Message-ID: <39eca272-2df9-8846-15e5-4d7fdeea001d@gmail.com> Hi, Using Undertow 1.3.23.Final, I /sometimes/ get this error, when running my WebSocket tests : ------------------------------------------ 2016-08-02 21:56:15 [ERROR] XNIO001007: A channel event listener threw an exception ~ Caller+0 at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:94) java.lang.StackOverflowError: null at ch.qos.logback.classic.pattern.ThrowableProxyConverter.subjoinSTEPArray(ThrowableProxyConverter.java:197) at ch.qos.logback.classic.pattern.ThrowableProxyConverter.recursiveAppend(ThrowableProxyConverter.java:161) at ch.qos.logback.classic.pattern.ThrowableProxyConverter.throwableProxyToString(ThrowableProxyConverter.java:151) at ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:145) at ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:1) at ch.qos.logback.core.pattern.FormattingConverter.write(FormattingConverter.java:36) at ch.qos.logback.core.pattern.PatternLayoutBase.writeLoopOnConverters(PatternLayoutBase.java:114) at ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:141) at ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:1) at ch.qos.logback.core.encoder.LayoutWrappingEncoder.doEncode(LayoutWrappingEncoder.java:130) at ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:187) at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:212) at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:100) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383) at ch.qos.logback.classic.Logger.log(Logger.java:765) at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.logging.Slf4jLocationAwareLogger.doLog(Slf4jLocationAwareLogger.java:89) at org.jboss.logging.Slf4jLocationAwareLogger.doLogf(Slf4jLocationAwareLogger.java:82) at org.jboss.logging.Logger.logf(Logger.java:2445) at org.xnio._private.Messages_$logger.listenerException(Messages_$logger.java:923) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:94) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) at io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) at io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) at io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) at io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) at io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) ... ------------------------------------------ The ------------------------------------------ at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) at io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) ------------------------------------------ part is repeated a lot of times before a stack overflow is reached. I'm currently not able to reproduce the error on demand, most of the time it works just fine. I'm still investigating. I'd like to know if someone has already seen this? Any potential causes you may think of? Thanks, Julien -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160802/20fdad35/attachment.html From sdouglas at redhat.com Tue Aug 2 22:56:30 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 3 Aug 2016 12:56:30 +1000 Subject: [undertow-dev] StackOverflowError on AbstractFramedChannel In-Reply-To: <39eca272-2df9-8846-15e5-4d7fdeea001d@gmail.com> References: <39eca272-2df9-8846-15e5-4d7fdeea001d@gmail.com> Message-ID: Looks like it is an exception that can occur when a server is being shut down. The close listener attempts to queue a task in the IO thread, but it is rejected because of the shutdown. It then executes it directly in the current thread, which results in another attempted dispatch. I have created: https://issues.jboss.org/browse/UNDERTOW-791 Should be an easy fix, and should not actually cause any issues because the server is being shut down anyway (at worst you might miss an OnClose notification). Stuart On Wed, Aug 3, 2016 at 12:34 PM, electrotype wrote: > Hi, > > Using Undertow 1.3.23.Final, I sometimes get this error, when running my > WebSocket tests : > > ------------------------------------------ > > 2016-08-02 21:56:15 [ERROR] XNIO001007: A channel event listener threw an > exception ~ Caller+0 at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:94) > java.lang.StackOverflowError: null > at > ch.qos.logback.classic.pattern.ThrowableProxyConverter.subjoinSTEPArray(ThrowableProxyConverter.java:197) > at > ch.qos.logback.classic.pattern.ThrowableProxyConverter.recursiveAppend(ThrowableProxyConverter.java:161) > at > ch.qos.logback.classic.pattern.ThrowableProxyConverter.throwableProxyToString(ThrowableProxyConverter.java:151) > at > ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:145) > at > ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:1) > at > ch.qos.logback.core.pattern.FormattingConverter.write(FormattingConverter.java:36) > at > ch.qos.logback.core.pattern.PatternLayoutBase.writeLoopOnConverters(PatternLayoutBase.java:114) > at > ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:141) > at > ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:1) > at > ch.qos.logback.core.encoder.LayoutWrappingEncoder.doEncode(LayoutWrappingEncoder.java:130) > at > ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:187) > at > ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:212) > at > ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:100) > at > ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) > at > ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48) > at > ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) > at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) > at > ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421) > at > ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383) > at ch.qos.logback.classic.Logger.log(Logger.java:765) > at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.logging.Slf4jLocationAwareLogger.doLog(Slf4jLocationAwareLogger.java:89) > at > org.jboss.logging.Slf4jLocationAwareLogger.doLogf(Slf4jLocationAwareLogger.java:82) > at org.jboss.logging.Logger.logf(Logger.java:2445) > at > org.xnio._private.Messages_$logger.listenerException(Messages_$logger.java:923) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:94) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) > at > io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) > at > io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) > at > io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) > at > io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) > at > io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > ... > ------------------------------------------ > > The > ------------------------------------------ > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) > at > io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > ------------------------------------------ > > part is repeated a lot of times before a stack overflow is reached. > > I'm currently not able to reproduce the error on demand, most of the time it > works just fine. I'm still investigating. > > I'd like to know if someone has already seen this? Any potential causes you > may think of? > > Thanks, > > Julien > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From electrotype at gmail.com Wed Aug 3 08:47:37 2016 From: electrotype at gmail.com (electrotype) Date: Wed, 3 Aug 2016 08:47:37 -0400 Subject: [undertow-dev] StackOverflowError on AbstractFramedChannel In-Reply-To: References: <39eca272-2df9-8846-15e5-4d7fdeea001d@gmail.com> Message-ID: Do I understand that this won't be fixed in the 1.3.X branch? If not, I may have to try to extend "AbstractFramedChannel" and apply your fix ( https://github.com/undertow-io/undertow/commit/e7b3f0342e60ad445e18ccde65d566a0bc618811 ). Not sure how easy this will be... I agree it's not a major issue when running in production. The real problem is that when the issue occures my tests take forever to complete. Thanks Stuart! Julien On 2016-08-02 22:56, Stuart Douglas wrote: > Looks like it is an exception that can occur when a server is being > shut down. The close listener attempts to queue a task in the IO > thread, but it is rejected because of the shutdown. It then executes > it directly in the current thread, which results in another attempted > dispatch. > > I have created: https://issues.jboss.org/browse/UNDERTOW-791 > > Should be an easy fix, and should not actually cause any issues > because the server is being shut down anyway (at worst you might miss > an OnClose notification). > > Stuart > > On Wed, Aug 3, 2016 at 12:34 PM, electrotype wrote: >> Hi, >> >> Using Undertow 1.3.23.Final, I sometimes get this error, when running my >> WebSocket tests : >> >> ------------------------------------------ >> >> 2016-08-02 21:56:15 [ERROR] XNIO001007: A channel event listener threw an >> exception ~ Caller+0 at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:94) >> java.lang.StackOverflowError: null >> at >> ch.qos.logback.classic.pattern.ThrowableProxyConverter.subjoinSTEPArray(ThrowableProxyConverter.java:197) >> at >> ch.qos.logback.classic.pattern.ThrowableProxyConverter.recursiveAppend(ThrowableProxyConverter.java:161) >> at >> ch.qos.logback.classic.pattern.ThrowableProxyConverter.throwableProxyToString(ThrowableProxyConverter.java:151) >> at >> ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:145) >> at >> ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:1) >> at >> ch.qos.logback.core.pattern.FormattingConverter.write(FormattingConverter.java:36) >> at >> ch.qos.logback.core.pattern.PatternLayoutBase.writeLoopOnConverters(PatternLayoutBase.java:114) >> at >> ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:141) >> at >> ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:1) >> at >> ch.qos.logback.core.encoder.LayoutWrappingEncoder.doEncode(LayoutWrappingEncoder.java:130) >> at >> ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:187) >> at >> ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:212) >> at >> ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:100) >> at >> ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) >> at >> ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48) >> at >> ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) >> at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) >> at >> ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421) >> at >> ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383) >> at ch.qos.logback.classic.Logger.log(Logger.java:765) >> at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.logging.Slf4jLocationAwareLogger.doLog(Slf4jLocationAwareLogger.java:89) >> at >> org.jboss.logging.Slf4jLocationAwareLogger.doLogf(Slf4jLocationAwareLogger.java:82) >> at org.jboss.logging.Logger.logf(Logger.java:2445) >> at >> org.xnio._private.Messages_$logger.listenerException(Messages_$logger.java:923) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:94) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> ... >> ------------------------------------------ >> >> The >> ------------------------------------------ >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >> at >> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> ------------------------------------------ >> >> part is repeated a lot of times before a stack overflow is reached. >> >> I'm currently not able to reproduce the error on demand, most of the time it >> works just fine. I'm still investigating. >> >> I'd like to know if someone has already seen this? Any potential causes you >> may think of? >> >> Thanks, >> >> Julien >> >> >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Wed Aug 3 21:48:50 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 4 Aug 2016 11:48:50 +1000 Subject: [undertow-dev] StackOverflowError on AbstractFramedChannel In-Reply-To: References: <39eca272-2df9-8846-15e5-4d7fdeea001d@gmail.com> Message-ID: For now I would recommend upgrading to Undertow 1.4.1.Final when once it is out (soonish). For the most part it should be a drop in replacement for 1.3.x, except with improved ALPN support for HTTP/2. I will get back to you about a possible merge into 1.3.x, I am still figuring out a few things with regard to how to best manage this branch. Also with regards to tests if you make sure you close all websocket connections before shutting down the worker this should not be an issue. Stuart On Wed, Aug 3, 2016 at 10:47 PM, electrotype wrote: > Do I understand that this won't be fixed in the 1.3.X branch? If not, I may > have to try to extend "AbstractFramedChannel" and apply your fix ( > https://github.com/undertow-io/undertow/commit/e7b3f0342e60ad445e18ccde65d566a0bc618811 > ). Not sure how easy this will be... > > I agree it's not a major issue when running in production. The real problem > is that when the issue occures my tests take forever to complete. > > Thanks Stuart! > > Julien > > > > On 2016-08-02 22:56, Stuart Douglas wrote: >> >> Looks like it is an exception that can occur when a server is being >> shut down. The close listener attempts to queue a task in the IO >> thread, but it is rejected because of the shutdown. It then executes >> it directly in the current thread, which results in another attempted >> dispatch. >> >> I have created: https://issues.jboss.org/browse/UNDERTOW-791 >> >> Should be an easy fix, and should not actually cause any issues >> because the server is being shut down anyway (at worst you might miss >> an OnClose notification). >> >> Stuart >> >> On Wed, Aug 3, 2016 at 12:34 PM, electrotype >> wrote: >>> >>> Hi, >>> >>> Using Undertow 1.3.23.Final, I sometimes get this error, when running my >>> WebSocket tests : >>> >>> ------------------------------------------ >>> >>> 2016-08-02 21:56:15 [ERROR] XNIO001007: A channel event listener threw an >>> exception ~ Caller+0 at >>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:94) >>> java.lang.StackOverflowError: null >>> at >>> >>> ch.qos.logback.classic.pattern.ThrowableProxyConverter.subjoinSTEPArray(ThrowableProxyConverter.java:197) >>> at >>> >>> ch.qos.logback.classic.pattern.ThrowableProxyConverter.recursiveAppend(ThrowableProxyConverter.java:161) >>> at >>> >>> ch.qos.logback.classic.pattern.ThrowableProxyConverter.throwableProxyToString(ThrowableProxyConverter.java:151) >>> at >>> >>> ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:145) >>> at >>> >>> ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:1) >>> at >>> >>> ch.qos.logback.core.pattern.FormattingConverter.write(FormattingConverter.java:36) >>> at >>> >>> ch.qos.logback.core.pattern.PatternLayoutBase.writeLoopOnConverters(PatternLayoutBase.java:114) >>> at >>> ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:141) >>> at >>> ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:1) >>> at >>> >>> ch.qos.logback.core.encoder.LayoutWrappingEncoder.doEncode(LayoutWrappingEncoder.java:130) >>> at >>> >>> ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:187) >>> at >>> >>> ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:212) >>> at >>> >>> ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:100) >>> at >>> >>> ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) >>> at >>> >>> ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48) >>> at >>> ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) >>> at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) >>> at >>> ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421) >>> at >>> ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383) >>> at ch.qos.logback.classic.Logger.log(Logger.java:765) >>> at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:497) >>> at >>> >>> org.jboss.logging.Slf4jLocationAwareLogger.doLog(Slf4jLocationAwareLogger.java:89) >>> at >>> >>> org.jboss.logging.Slf4jLocationAwareLogger.doLogf(Slf4jLocationAwareLogger.java:82) >>> at org.jboss.logging.Logger.logf(Logger.java:2445) >>> at >>> >>> org.xnio._private.Messages_$logger.listenerException(Messages_$logger.java:923) >>> at >>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:94) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >>> at >>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >>> at >>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >>> at >>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >>> at >>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >>> at >>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >>> ... >>> ------------------------------------------ >>> >>> The >>> ------------------------------------------ >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >>> at >>> >>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >>> at >>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >>> ------------------------------------------ >>> >>> part is repeated a lot of times before a stack overflow is reached. >>> >>> I'm currently not able to reproduce the error on demand, most of the time >>> it >>> works just fine. I'm still investigating. >>> >>> I'd like to know if someone has already seen this? Any potential causes >>> you >>> may think of? >>> >>> Thanks, >>> >>> Julien >>> >>> >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev > > From electrotype at gmail.com Wed Aug 3 22:13:44 2016 From: electrotype at gmail.com (electrotype) Date: Wed, 3 Aug 2016 22:13:44 -0400 Subject: [undertow-dev] StackOverflowError on AbstractFramedChannel In-Reply-To: References: <39eca272-2df9-8846-15e5-4d7fdeea001d@gmail.com> Message-ID: 1.4.X works well indeed, I just upgraded. I'll un-ignore my problematic test class once the fix is included in the next 1.4.X release. Thanks Stuart, Julien On 2016-08-03 21:48, Stuart Douglas wrote: > For now I would recommend upgrading to Undertow 1.4.1.Final when once > it is out (soonish). For the most part it should be a drop in > replacement for 1.3.x, except with improved ALPN support for HTTP/2. > > I will get back to you about a possible merge into 1.3.x, I am still > figuring out a few things with regard to how to best manage this > branch. > > Also with regards to tests if you make sure you close all websocket > connections before shutting down the worker this should not be an > issue. > > Stuart > > On Wed, Aug 3, 2016 at 10:47 PM, electrotype wrote: >> Do I understand that this won't be fixed in the 1.3.X branch? If not, I may >> have to try to extend "AbstractFramedChannel" and apply your fix ( >> https://github.com/undertow-io/undertow/commit/e7b3f0342e60ad445e18ccde65d566a0bc618811 >> ). Not sure how easy this will be... >> >> I agree it's not a major issue when running in production. The real problem >> is that when the issue occures my tests take forever to complete. >> >> Thanks Stuart! >> >> Julien >> >> >> >> On 2016-08-02 22:56, Stuart Douglas wrote: >>> Looks like it is an exception that can occur when a server is being >>> shut down. The close listener attempts to queue a task in the IO >>> thread, but it is rejected because of the shutdown. It then executes >>> it directly in the current thread, which results in another attempted >>> dispatch. >>> >>> I have created: https://issues.jboss.org/browse/UNDERTOW-791 >>> >>> Should be an easy fix, and should not actually cause any issues >>> because the server is being shut down anyway (at worst you might miss >>> an OnClose notification). >>> >>> Stuart >>> >>> On Wed, Aug 3, 2016 at 12:34 PM, electrotype >>> wrote: >>>> Hi, >>>> >>>> Using Undertow 1.3.23.Final, I sometimes get this error, when running my >>>> WebSocket tests : >>>> >>>> ------------------------------------------ >>>> >>>> 2016-08-02 21:56:15 [ERROR] XNIO001007: A channel event listener threw an >>>> exception ~ Caller+0 at >>>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:94) >>>> java.lang.StackOverflowError: null >>>> at >>>> >>>> ch.qos.logback.classic.pattern.ThrowableProxyConverter.subjoinSTEPArray(ThrowableProxyConverter.java:197) >>>> at >>>> >>>> ch.qos.logback.classic.pattern.ThrowableProxyConverter.recursiveAppend(ThrowableProxyConverter.java:161) >>>> at >>>> >>>> ch.qos.logback.classic.pattern.ThrowableProxyConverter.throwableProxyToString(ThrowableProxyConverter.java:151) >>>> at >>>> >>>> ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:145) >>>> at >>>> >>>> ch.qos.logback.classic.pattern.ThrowableProxyConverter.convert(ThrowableProxyConverter.java:1) >>>> at >>>> >>>> ch.qos.logback.core.pattern.FormattingConverter.write(FormattingConverter.java:36) >>>> at >>>> >>>> ch.qos.logback.core.pattern.PatternLayoutBase.writeLoopOnConverters(PatternLayoutBase.java:114) >>>> at >>>> ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:141) >>>> at >>>> ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:1) >>>> at >>>> >>>> ch.qos.logback.core.encoder.LayoutWrappingEncoder.doEncode(LayoutWrappingEncoder.java:130) >>>> at >>>> >>>> ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:187) >>>> at >>>> >>>> ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:212) >>>> at >>>> >>>> ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:100) >>>> at >>>> >>>> ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) >>>> at >>>> >>>> ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48) >>>> at >>>> ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) >>>> at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) >>>> at >>>> ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421) >>>> at >>>> ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383) >>>> at ch.qos.logback.classic.Logger.log(Logger.java:765) >>>> at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) >>>> at >>>> >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:497) >>>> at >>>> >>>> org.jboss.logging.Slf4jLocationAwareLogger.doLog(Slf4jLocationAwareLogger.java:89) >>>> at >>>> >>>> org.jboss.logging.Slf4jLocationAwareLogger.doLogf(Slf4jLocationAwareLogger.java:82) >>>> at org.jboss.logging.Logger.logf(Logger.java:2445) >>>> at >>>> >>>> org.xnio._private.Messages_$logger.listenerException(Messages_$logger.java:923) >>>> at >>>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:94) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >>>> at >>>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >>>> at >>>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >>>> at >>>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >>>> at >>>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >>>> at >>>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >>>> ... >>>> ------------------------------------------ >>>> >>>> The >>>> ------------------------------------------ >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener$2.run(AbstractFramedChannel.java:981) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel.runInIoThread(AbstractFramedChannel.java:235) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:978) >>>> at >>>> >>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameCloseListener.handleEvent(AbstractFramedChannel.java:937) >>>> at >>>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >>>> ------------------------------------------ >>>> >>>> part is repeated a lot of times before a stack overflow is reached. >>>> >>>> I'm currently not able to reproduce the error on demand, most of the time >>>> it >>>> works just fine. I'm still investigating. >>>> >>>> I'd like to know if someone has already seen this? Any potential causes >>>> you >>>> may think of? >>>> >>>> Thanks, >>>> >>>> Julien >>>> >>>> >>>> >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >> From espina.edgar at gmail.com Sun Aug 7 17:20:45 2016 From: espina.edgar at gmail.com (Edgar Espina) Date: Sun, 07 Aug 2016 21:20:45 +0000 Subject: [undertow-dev] HTTP/2 initial exception Message-ID: Hi, I'm playing with HTTP/2 and 1.4.0.Final and got a long stack trace on first request, after first request no exception is generated or logged it. You can reproduce this with a simple text response or with the HTTP/2 directory listing example. Everything works as expected and exceptions are logged as debug not as error... but I would like to know if this is expected or normal, as I said everything works just got this ugly and log stack trace. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160807/236e0d48/attachment-0001.html -------------- next part -------------- DEBUG io.undertow.request.io at XNIO-1 I/O-2 UT005013: An IOException occurred java.io.IOException: javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack? at io.undertow.protocols.ssl.SslConduit.notifyReadClosed(SslConduit.java:608) at io.undertow.protocols.ssl.SslConduit.closed(SslConduit.java:973) at io.undertow.protocols.ssl.SslConduit.close(SslConduit.java:1068) at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:789) at io.undertow.protocols.ssl.SslConduit.read(SslConduit.java:561) at io.undertow.conduits.IdleTimeoutConduit.read(IdleTimeoutConduit.java:198) at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:369) at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:103) at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:56) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:921) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:902) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1118) at io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:168) at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580) at org.xnio.nio.WorkerThread.run(WorkerThread.java:464) Caused by: javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack? at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) at sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:1561) at io.undertow.protocols.ssl.ALPNHackSSLEngine.closeInbound(ALPNHackSSLEngine.java:268) at io.undertow.protocols.ssl.SslConduit.notifyReadClosed(SslConduit.java:606) ... 18 common frames omitted DEBUG io.undertow.request at XNIO-1 I/O-2 Closing HTTP2 channel to /127.0.0.1:50068 due to broken read side java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcherImpl.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:192) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:286) at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:694) at io.undertow.protocols.ssl.SslConduit.read(SslConduit.java:561) at io.undertow.conduits.IdleTimeoutConduit.read(IdleTimeoutConduit.java:198) at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:369) at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:103) at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:56) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:921) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:902) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1118) at io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:168) at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580) at org.xnio.nio.WorkerThread.run(WorkerThread.java:464) DEBUG io.undertow.request at XNIO-1 I/O-2 Closing HTTP2 channel to /127.0.0.1:50068 due to broken write side java.nio.channels.ClosedChannelException: null at io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:377) at io.undertow.conduits.IdleTimeoutConduit.write(IdleTimeoutConduit.java:126) at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:154) at io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:636) at io.undertow.server.protocol.framed.AbstractFramedChannel.flush(AbstractFramedChannel.java:716) at io.undertow.server.protocol.framed.AbstractFramedChannel.queueFrame(AbstractFramedChannel.java:709) at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.queueFinalFrame(AbstractFramedStreamSinkChannel.java:272) at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.shutdownWrites(AbstractFramedStreamSinkChannel.java:257) at io.undertow.protocols.http2.Http2Channel.sendGoAway(Http2Channel.java:613) at io.undertow.protocols.http2.Http2Channel.handleBrokenSourceChannel(Http2Channel.java:475) at io.undertow.server.protocol.framed.AbstractFramedChannel.markReadsBroken(AbstractFramedChannel.java:818) at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:475) at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:103) at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:56) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:921) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:902) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1118) at io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:168) at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580) at org.xnio.nio.WorkerThread.run(WorkerThread.java:464) DEBUG io.undertow.request at XNIO-1 I/O-2 Closing HTTP2 channel to /127.0.0.1:50068 due to broken write side java.nio.channels.ClosedChannelException: null at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.flush(AbstractFramedStreamSinkChannel.java:361) at io.undertow.protocols.http2.Http2Channel.sendGoAway(Http2Channel.java:614) at io.undertow.protocols.http2.Http2Channel.handleBrokenSourceChannel(Http2Channel.java:475) at io.undertow.server.protocol.framed.AbstractFramedChannel.markReadsBroken(AbstractFramedChannel.java:818) at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:475) at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:103) at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:56) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:921) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:902) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1118) at io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:168) at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580) at org.xnio.nio.WorkerThread.run(WorkerThread.java:464) DEBUG io.undertow.request.io at XNIO-1 I/O-2 UT005013: An IOException occurred java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcherImpl.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:192) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:286) at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:694) at io.undertow.protocols.ssl.SslConduit.read(SslConduit.java:561) at io.undertow.conduits.IdleTimeoutConduit.read(IdleTimeoutConduit.java:198) at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:369) at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:103) at io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:56) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:921) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:902) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1118) at io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:168) at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580) at org.xnio.nio.WorkerThread.run(WorkerThread.java:464) From sdouglas at redhat.com Sun Aug 7 19:31:48 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 8 Aug 2016 09:31:48 +1000 Subject: [undertow-dev] HTTP/2 initial exception In-Reply-To: References: Message-ID: That exception is logged at debug level, and basically happens when an SSL connection is not closed cleanly. It can be safely ignored (in general anything under io.undertow.request.io can be ignored, as it basically means some kind of connection issue (such as the user closing the browser window) that you can likely do nothing about). In this case it is probably because if you use a self signed certificate on the first connection the browser will abort the connection, and display a warning/error page about the self signed cert. Once you add the exception it should not happen again. Stuart On Mon, Aug 8, 2016 at 7:20 AM, Edgar Espina wrote: > Hi, > > I'm playing with HTTP/2 and 1.4.0.Final and got a long stack trace on first > request, after first request no exception is generated or logged it. > > You can reproduce this with a simple text response or with the HTTP/2 > directory listing example. > > Everything works as expected and exceptions are logged as debug not as > error... but I would like to know if this is expected or normal, as I said > everything works just got this ugly and log stack trace. > > Thanks. > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From espina.edgar at gmail.com Sun Aug 7 21:36:16 2016 From: espina.edgar at gmail.com (Edgar Espina) Date: Mon, 08 Aug 2016 01:36:16 +0000 Subject: [undertow-dev] HTTP/2 initial exception In-Reply-To: References: Message-ID: Thanks a lot Stuart!! Good work you did in 1.4.x by removing alpn-boot On Sun, Aug 7, 2016 at 8:31 PM Stuart Douglas wrote: > That exception is logged at debug level, and basically happens when an > SSL connection is not closed cleanly. It can be safely ignored (in > general anything under io.undertow.request.io can be ignored, as it > basically means some kind of connection issue (such as the user > closing the browser window) that you can likely do nothing about). > > In this case it is probably because if you use a self signed > certificate on the first connection the browser will abort the > connection, and display a warning/error page about the self signed > cert. Once you add the exception it should not happen again. > > Stuart > > On Mon, Aug 8, 2016 at 7:20 AM, Edgar Espina > wrote: > > Hi, > > > > I'm playing with HTTP/2 and 1.4.0.Final and got a long stack trace on > first > > request, after first request no exception is generated or logged it. > > > > You can reproduce this with a simple text response or with the HTTP/2 > > directory listing example. > > > > Everything works as expected and exceptions are logged as debug not as > > error... but I would like to know if this is expected or normal, as I > said > > everything works just got this ugly and log stack trace. > > > > Thanks. > > > > > > _______________________________________________ > > 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/20160808/8015484d/attachment.html From leleuj at gmail.com Mon Aug 8 12:27:03 2016 From: leleuj at gmail.com (=?UTF-8?B?SsOpcsO0bWUgTEVMRVU=?=) Date: Mon, 8 Aug 2016 18:27:03 +0200 Subject: [undertow-dev] Release of the undertow-pac4j security library version 1.2.0 Message-ID: Hi, I'm proud to announce the release of undertow-pac4j v1.2.0: *https://github.com/pac4j/undertow-pac4j * It supports most: - authentication mechanisms: OAuth (Facebook, Twitter, Google, Yahoo...), CAS, HTTP (form, basic auth...), OpenID, SAML, Google App Engine, OpenID Connect, JWT, LDAP, RDBMS, MongoDB and Stormpath - authorization checks: roles / permissions, CSRF, security headers... It's based on Java 8, Undertow 1.3 and pac4j v1.9.1. pac4j v1.9 is a big upgrade compared to v1.8: - all dependencies have been upgraded, the source code has been cleaned (-15%) - multi-profiles are now supported - the extension capabilities have been highly improved (core components can now throw a HttpAction to break the flow and perform any specific behaviour). Check out the demo: *https://github.com/pac4j/undertow-pac4j-demo * Thanks. Best regards, J?r?me -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160808/028ea77e/attachment.html From thomas.darimont at googlemail.com Mon Aug 8 16:35:08 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 8 Aug 2016 22:35:08 +0200 Subject: [undertow-dev] How to configure Undertow programatically at runtime within Wildfly? Message-ID: Hello list, I'm currently working on embedding Keycloak's currently dedicated Proxy Server into Keycloak itself. For this I need to be able to dynamically configure Undertow's ProxyHandler and register VirtualHosts at runtime. For reference the discussion thread on keycloak-dev ML: [1] Keycloak uses the Undertow Subsystem provided by Wildfly 10 which is configured via the standalone(-ha).xml. I could already configure a reverse-proxy and additional hosts via jboss-cli but I wonder whether there is an API that I could use to get access to the undertow infrastructure from within a JAX-RS endpoint. I could probably also use the wildfly management client API or perhaps do something via JMX. Would be great if someone could give me a tip or an example for registering / configuring Undertow Handler or Virtual Hosts as described above. Btw. I saw that Undertow ships with a io.undertow.server.handlers.proxy.HostTable but I couldn't find any usage of it in the Undertow codebase - did I miss something or is this dead code? FYI current code of Keycloak dedicated Proxy Server (uses embedded undertow) can be found here: [0] Cherrs, Thomas [0] https://github.com/keycloak/keycloak/tree/master/proxy [1] http://lists.jboss.org/pipermail/keycloak-dev/2016-August/007742.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160808/e9d84380/attachment.html From sdouglas at redhat.com Mon Aug 8 23:50:47 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 9 Aug 2016 13:50:47 +1000 Subject: [undertow-dev] How to configure Undertow programatically at runtime within Wildfly? In-Reply-To: References: Message-ID: So does this need to proxy all requests, or just requests targeted at the keycloak deployment? If it is the later then you could just use ServletExtension to set up the ProxyHandler. Stuart On Tue, Aug 9, 2016 at 6:35 AM, Thomas Darimont wrote: > Hello list, > > I'm currently working on embedding Keycloak's currently dedicated Proxy > Server into Keycloak itself. > For this I need to be able to dynamically configure Undertow's ProxyHandler > and register VirtualHosts at runtime. > For reference the discussion thread on keycloak-dev ML: [1] > > Keycloak uses the Undertow Subsystem provided by Wildfly 10 which is > configured via the standalone(-ha).xml. > > I could already configure a reverse-proxy and additional hosts via jboss-cli > but I wonder whether there is an API > that I could use to get access to the undertow infrastructure from within a > JAX-RS endpoint. > I could probably also use the wildfly management client API or perhaps do > something via JMX. > > Would be great if someone could give me a tip or an example for registering > / configuring Undertow Handler or Virtual Hosts as described above. > > Btw. I saw that Undertow ships with a > io.undertow.server.handlers.proxy.HostTable but I couldn't find > any usage of it in the Undertow codebase - did I miss something or is this > dead code? > > FYI current code of Keycloak dedicated Proxy Server (uses embedded undertow) > can be found here: [0] > > Cherrs, > Thomas > [0] https://github.com/keycloak/keycloak/tree/master/proxy > [1] http://lists.jboss.org/pipermail/keycloak-dev/2016-August/007742.html > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From thomas.darimont at googlemail.com Tue Aug 9 05:04:50 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 9 Aug 2016 11:04:50 +0200 Subject: [undertow-dev] How to configure Undertow programatically at runtime within Wildfly? In-Reply-To: References: Message-ID: Hello Stuart, thanks for your help :) My current understanding is that I need to proxy requests that are sent to a virtual host created at runtime by the Keycloak deployment and Keycloak would add some additional headers with auth information and takes care of authentication of necessary. Since this can be configured at runtime I don't see how I could use the ServletExtension (which is to my knowledge applied at start-time) to dynamically register virtual hosts with Undertow. The workflow is as follows: So an admin would create a new "proxied" client configuration in the Keycloak admin console where he would configure the name for a new virtual host and a target url. E.g. if the keycloak servername is "sso.acme.com" a user would create proxied client with the following configuration: * clientid: app1 * virtual host: app1.acme.com * target url: https://myapp1.com/app * Header Mapping: key value pairs with header name to (dynamic) expression mapping to inject in the proxied request * Certificate / public / private key The certificate is used to provide TLS for app1.acme.com - one could also use a wildcard cert here or generate the cert on the server on client setup. With that in place requests sent to: https://app1.acme.com/ should be proxied to: https://myapp1.com/app/ The DNS name app1.acme.com would of course resolve to the IP of sso.acme.com . A purely path-based solution would be to define a proxy endpoint like https://sso.acme.com/proxy/ which then proxies all requests sent to https://sso.acme.com/proxy/app1 to https://myapp1.com/app. The servlet based approach could be done easily done with Servlets or JAX-RS endpoints, but I still wonder how the dynamic vhost registration could be done. Cheers, Thomas 2016-08-09 5:50 GMT+02:00 Stuart Douglas : > So does this need to proxy all requests, or just requests targeted at > the keycloak deployment? If it is the later then you could just use > ServletExtension to set up the ProxyHandler. > > Stuart > > On Tue, Aug 9, 2016 at 6:35 AM, Thomas Darimont > wrote: > > Hello list, > > > > I'm currently working on embedding Keycloak's currently dedicated Proxy > > Server into Keycloak itself. > > For this I need to be able to dynamically configure Undertow's > ProxyHandler > > and register VirtualHosts at runtime. > > For reference the discussion thread on keycloak-dev ML: [1] > > > > Keycloak uses the Undertow Subsystem provided by Wildfly 10 which is > > configured via the standalone(-ha).xml. > > > > I could already configure a reverse-proxy and additional hosts via > jboss-cli > > but I wonder whether there is an API > > that I could use to get access to the undertow infrastructure from > within a > > JAX-RS endpoint. > > I could probably also use the wildfly management client API or perhaps do > > something via JMX. > > > > Would be great if someone could give me a tip or an example for > registering > > / configuring Undertow Handler or Virtual Hosts as described above. > > > > Btw. I saw that Undertow ships with a > > io.undertow.server.handlers.proxy.HostTable but I couldn't find > > any usage of it in the Undertow codebase - did I miss something or is > this > > dead code? > > > > FYI current code of Keycloak dedicated Proxy Server (uses embedded > undertow) > > can be found here: [0] > > > > Cherrs, > > Thomas > > [0] https://github.com/keycloak/keycloak/tree/master/proxy > > [1] http://lists.jboss.org/pipermail/keycloak-dev/2016- > August/007742.html > > > > > > _______________________________________________ > > 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/20160809/6289223a/attachment-0001.html From sdouglas at redhat.com Mon Aug 15 23:18:05 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 16 Aug 2016 13:18:05 +1000 Subject: [undertow-dev] How to configure Undertow programatically at runtime within Wildfly? In-Reply-To: References: Message-ID: I think you are going to need a management client based solution here. At the moment the subsystem is not really designed to be extended in this way. Another possibility would be to install your own virtual host handler in the default host (i.e. the host that gets selected if none match). You could then control this programmatically. I don't think this would be a great solution though Stuart On Tue, Aug 9, 2016 at 7:04 PM, Thomas Darimont wrote: > Hello Stuart, > > thanks for your help :) > > My current understanding is that I need to proxy requests that are sent to a > virtual host created > at runtime by the Keycloak deployment and Keycloak would add some additional > headers with auth information > and takes care of authentication of necessary. > > Since this can be configured at runtime I don't see how I could use the > ServletExtension (which is to my knowledge > applied at start-time) to dynamically register virtual hosts with Undertow. > > The workflow is as follows: > > So an admin would create a new "proxied" client configuration in the > Keycloak admin console where > he would configure the name for a new virtual host and a target url. > > E.g. if the keycloak servername is "sso.acme.com" a user would create > proxied client with the following configuration: > * clientid: app1 > * virtual host: app1.acme.com > * target url: https://myapp1.com/app > * Header Mapping: key value pairs with header name to (dynamic) expression > mapping to inject in the proxied request > * Certificate / public / private key > > The certificate is used to provide TLS for app1.acme.com - one could also > use a wildcard cert here or generate > the cert on the server on client setup. > > With that in place requests sent to: https://app1.acme.com/ > should be proxied to: https://myapp1.com/app/ > The DNS name app1.acme.com would of course resolve to the IP of > sso.acme.com. > > A purely path-based solution would be to define a proxy endpoint like > https://sso.acme.com/proxy/ which then > proxies all requests sent to https://sso.acme.com/proxy/app1 to > https://myapp1.com/app. > > The servlet based approach could be done easily done with Servlets or JAX-RS > endpoints, but I still wonder how the dynamic vhost registration could be > done. > > Cheers, > Thomas > > 2016-08-09 5:50 GMT+02:00 Stuart Douglas : >> >> So does this need to proxy all requests, or just requests targeted at >> the keycloak deployment? If it is the later then you could just use >> ServletExtension to set up the ProxyHandler. >> >> Stuart >> >> On Tue, Aug 9, 2016 at 6:35 AM, Thomas Darimont >> wrote: >> > Hello list, >> > >> > I'm currently working on embedding Keycloak's currently dedicated Proxy >> > Server into Keycloak itself. >> > For this I need to be able to dynamically configure Undertow's >> > ProxyHandler >> > and register VirtualHosts at runtime. >> > For reference the discussion thread on keycloak-dev ML: [1] >> > >> > Keycloak uses the Undertow Subsystem provided by Wildfly 10 which is >> > configured via the standalone(-ha).xml. >> > >> > I could already configure a reverse-proxy and additional hosts via >> > jboss-cli >> > but I wonder whether there is an API >> > that I could use to get access to the undertow infrastructure from >> > within a >> > JAX-RS endpoint. >> > I could probably also use the wildfly management client API or perhaps >> > do >> > something via JMX. >> > >> > Would be great if someone could give me a tip or an example for >> > registering >> > / configuring Undertow Handler or Virtual Hosts as described above. >> > >> > Btw. I saw that Undertow ships with a >> > io.undertow.server.handlers.proxy.HostTable but I couldn't find >> > any usage of it in the Undertow codebase - did I miss something or is >> > this >> > dead code? >> > >> > FYI current code of Keycloak dedicated Proxy Server (uses embedded >> > undertow) >> > can be found here: [0] >> > >> > Cherrs, >> > Thomas >> > [0] https://github.com/keycloak/keycloak/tree/master/proxy >> > [1] >> > http://lists.jboss.org/pipermail/keycloak-dev/2016-August/007742.html >> > >> > >> > _______________________________________________ >> > undertow-dev mailing list >> > undertow-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/undertow-dev > > From tomaz.cerar at gmail.com Tue Aug 16 05:38:13 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 16 Aug 2016 11:38:13 +0200 Subject: [undertow-dev] How to configure Undertow programatically at runtime within Wildfly? In-Reply-To: References: Message-ID: On Tue, Aug 16, 2016 at 5:18 AM, Stuart Douglas wrote: > I think you are going to need a management client based solution here. > At the moment the subsystem is not really designed to be extended in > this way. > Well, given that keycloak already has a subsystem, it could be done by deep integration with undertow subsystem directly. but in general it can be done by calling management operations in whatever way it is easiest for you. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160816/21136387/attachment.html From matt at matthicks.com Tue Aug 16 17:21:34 2016 From: matt at matthicks.com (Hicks, Matt) Date: Tue, 16 Aug 2016 21:21:34 +0000 Subject: [undertow-dev] UndertowClient Multipart Message-ID: I'm attempting to use the UndertowClient to send multipart/form-data to a server but I'm having trouble figuring out how to do so. I can't seem to find any examples or documentation of how to accomplish this. Any insights would be appreciated. I'm simply trying to encode a form POST into multipart/form-data to send to a server and get the response back. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160816/ba8d3133/attachment.html From sdouglas at redhat.com Tue Aug 16 18:55:06 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 17 Aug 2016 08:55:06 +1000 Subject: [undertow-dev] UndertowClient Multipart In-Reply-To: References: Message-ID: At the moment the client does not have support for building a multipart request. Because the primary use case for the client is the reverse proxy the API only deals with complete request bodies (as the client basically just forwards existing requests). We could add some kind of builder API for building multipart/form encoded request bodies, although it is not planned at the moment. Stuart On Wed, Aug 17, 2016 at 7:21 AM, Hicks, Matt wrote: > I'm attempting to use the UndertowClient to send multipart/form-data to a > server but I'm having trouble figuring out how to do so. I can't seem to > find any examples or documentation of how to accomplish this. > > Any insights would be appreciated. I'm simply trying to encode a form POST > into multipart/form-data to send to a server and get the response back. > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From matt at matthicks.com Fri Aug 26 09:31:53 2016 From: matt at matthicks.com (Hicks, Matt) Date: Fri, 26 Aug 2016 13:31:53 +0000 Subject: [undertow-dev] Session Cookie Domain? Message-ID: I can't seem to figure out any way to configure the session manager to define the domain of the cookie. I want the domain to be *.mydomain.com so the cookie is shared across multiple sub-domains. Can someone give me an example of how to do this? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160826/a5f6afe6/attachment.html From martin.andersson at purplescout.se Mon Aug 29 03:19:06 2016 From: martin.andersson at purplescout.se (Martin Andersson) Date: Mon, 29 Aug 2016 09:19:06 +0200 Subject: [undertow-dev] Gzip and Proxy Message-ID: Hi all, I've seem to have hit a bug in undertow when combining proxying and gzip. I'm trying to use undertow as a reverse-proxy and also compressing the result when clients support it. Undertow-code below. * Proxying without compressing works fine (curl -v localhost:8099/proxy) * Compressing content that is not proxied works fine (curl -v --compress localhost:8099/local) * Proxy and compression just hangs. Not even headers are received (curl -v --compress localhost:8099/proxy) Trying to debug what's going on I found that the GzipStreamSinkConduit receives all content but is never flushed. The call sequence for GzipStreamSinkConduit for proxied content is: write(ByteBuffer src) - all context from the proxied app is written. wakeupWrites() - which basically does nothing. Ends up in DeflatingStreamSinkConduit.queueWriteListener() which calls any WriteReadyHandlers but there are none. Any clues? My code to setup undertow: final PathHandler pathHandler = Handlers.path(); pathHandler.addExactPath("/local", new HttpHandler() { @Override public void handleRequest(HttpServerExchange exchange) throws Exception { exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain"); exchange.getResponseSender().send("Hello World"); } }); pathHandler.addPrefixPath("/proxy", new ProxyHandler( new SimpleProxyClientProvider(new URI("http://localhost:8060/menu")), ResponseCodeHandler.HANDLE_404)); final EncodingHandler handler = new EncodingHandler(pathHandler, new ContentEncodingRepository() .addEncodingHandler("gzip", new GzipEncodingProvider(), 50, Predicates.truePredicate())); Undertow.builder() .addHttpListener(8099, "0.0.0.0") .setHandler(handler) .build().start(); -- Br, Martin Andersson Purple Scout AB +46 732 05 14 01 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160829/8c974fbd/attachment-0001.html From sdouglas at redhat.com Mon Aug 29 20:51:49 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 30 Aug 2016 10:51:49 +1000 Subject: [undertow-dev] Gzip and Proxy In-Reply-To: References: Message-ID: https://issues.jboss.org/browse/UNDERTOW-810 I have fixed this upstream. Stuart On Mon, Aug 29, 2016 at 5:19 PM, Martin Andersson wrote: > Hi all, > > I've seem to have hit a bug in undertow when combining proxying and gzip. > > I'm trying to use undertow as a reverse-proxy and also compressing the > result when clients support it. Undertow-code below. > > * Proxying without compressing works fine (curl -v localhost:8099/proxy) > * Compressing content that is not proxied works fine (curl -v --compress > localhost:8099/local) > * Proxy and compression just hangs. Not even headers are received (curl -v > --compress localhost:8099/proxy) > > Trying to debug what's going on I found that the GzipStreamSinkConduit > receives all content but is never flushed. > > The call sequence for GzipStreamSinkConduit for proxied content is: > write(ByteBuffer src) - all context from the proxied app is written. > wakeupWrites() - which basically does nothing. Ends up in > DeflatingStreamSinkConduit.queueWriteListener() which calls any > WriteReadyHandlers but there are none. > > Any clues? > > My code to setup undertow: > > final PathHandler pathHandler = Handlers.path(); > pathHandler.addExactPath("/local", new HttpHandler() { > @Override > public void handleRequest(HttpServerExchange exchange) throws Exception { > exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain"); > exchange.getResponseSender().send("Hello World"); } > }); > pathHandler.addPrefixPath("/proxy", > new ProxyHandler( > new SimpleProxyClientProvider(new URI("http://localhost:8060/menu")), > ResponseCodeHandler.HANDLE_404)); > > final EncodingHandler handler = > new EncodingHandler(pathHandler, new ContentEncodingRepository() > .addEncodingHandler("gzip", > new GzipEncodingProvider(), 50, > Predicates.truePredicate())); > > Undertow.builder() > .addHttpListener(8099, "0.0.0.0") > .setHandler(handler) > .build().start(); > > -- > Br, > Martin Andersson > Purple Scout AB > +46 732 05 14 01 > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Mon Aug 29 21:05:51 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 30 Aug 2016 11:05:51 +1000 Subject: [undertow-dev] Session Cookie Domain? In-Reply-To: References: Message-ID: For servlet or Undertow native? For native it is controlled by the io.undertow.server.session.SessionCookieConfig implementation that is passed to the session manager. For Servlet the standard way to do it is to use a ServletContextListener to modify the domain under javax.servlet.ServletContext#getSessionCookieConfig Stuart On Fri, Aug 26, 2016 at 11:31 PM, Hicks, Matt wrote: > I can't seem to figure out any way to configure the session manager to > define the domain of the cookie. I want the domain to be *.mydomain.com so > the cookie is shared across multiple sub-domains. Can someone give me an > example of how to do this? > > Thanks > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From martin.andersson at purplescout.se Tue Aug 30 01:59:31 2016 From: martin.andersson at purplescout.se (Martin Andersson) Date: Tue, 30 Aug 2016 07:59:31 +0200 Subject: [undertow-dev] Gzip and Proxy In-Reply-To: References: Message-ID: Nice, thanks! On Tue, Aug 30, 2016 at 2:51 AM, Stuart Douglas wrote: > https://issues.jboss.org/browse/UNDERTOW-810 > > I have fixed this upstream. > > Stuart > > On Mon, Aug 29, 2016 at 5:19 PM, Martin Andersson > wrote: > > Hi all, > > > > I've seem to have hit a bug in undertow when combining proxying and gzip. > > > > I'm trying to use undertow as a reverse-proxy and also compressing the > > result when clients support it. Undertow-code below. > > > > * Proxying without compressing works fine (curl -v localhost:8099/proxy) > > * Compressing content that is not proxied works fine (curl -v --compress > > localhost:8099/local) > > * Proxy and compression just hangs. Not even headers are received (curl > -v > > --compress localhost:8099/proxy) > > > > Trying to debug what's going on I found that the GzipStreamSinkConduit > > receives all content but is never flushed. > > > > The call sequence for GzipStreamSinkConduit for proxied content is: > > write(ByteBuffer src) - all context from the proxied app is written. > > wakeupWrites() - which basically does nothing. Ends up in > > DeflatingStreamSinkConduit.queueWriteListener() which calls any > > WriteReadyHandlers but there are none. > > > > Any clues? > > > > My code to setup undertow: > > > > final PathHandler pathHandler = Handlers.path(); > > pathHandler.addExactPath("/local", new HttpHandler() { > > @Override > > public void handleRequest(HttpServerExchange exchange) throws Exception > { > > exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain"); > > exchange.getResponseSender().send("Hello World"); } > > }); > > pathHandler.addPrefixPath("/proxy", > > new ProxyHandler( > > new SimpleProxyClientProvider(new URI("http://localhost:8060/menu")), > > ResponseCodeHandler.HANDLE_404)); > > > > final EncodingHandler handler = > > new EncodingHandler(pathHandler, new ContentEncodingRepository() > > .addEncodingHandler("gzip", > > new GzipEncodingProvider(), 50, > > Predicates.truePredicate())); > > > > Undertow.builder() > > .addHttpListener(8099, "0.0.0.0") > > .setHandler(handler) > > .build().start(); > > > > -- > > Br, > > Martin Andersson > > Purple Scout AB > > +46 732 05 14 01 > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > -- Br, Martin Andersson Purple Scout AB +46 732 05 14 01 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160830/7a30e457/attachment.html From matt at matthicks.com Tue Aug 30 16:11:25 2016 From: matt at matthicks.com (Hicks, Matt) Date: Tue, 30 Aug 2016 20:11:25 +0000 Subject: [undertow-dev] Session Cookie Domain? In-Reply-To: References: Message-ID: Thanks Stuart, that did the trick. I'm extending FileResourceManager to convert from the web path to an internal storage path and also trying to validation against the session to verify the logged-in state. However, I'm running into a roadblock because `getResource` doesn't have access to the exchange to be able to get the cookie value. I tried using ThreadLocal, but it's dispatched to another thread so that won't work either. How am I supposed to access a cookie or session from within a ResourceManager.getResource? On Mon, Aug 29, 2016 at 8:05 PM Stuart Douglas wrote: > For servlet or Undertow native? > > For native it is controlled by the > io.undertow.server.session.SessionCookieConfig implementation that is > passed to the session manager. > > For Servlet the standard way to do it is to use a > ServletContextListener to modify the domain under > javax.servlet.ServletContext#getSessionCookieConfig > > Stuart > > On Fri, Aug 26, 2016 at 11:31 PM, Hicks, Matt wrote: > > I can't seem to figure out any way to configure the session manager to > > define the domain of the cookie. I want the domain to be *.mydomain.com > so > > the cookie is shared across multiple sub-domains. Can someone give me an > > example of how to do this? > > > > Thanks > > > > _______________________________________________ > > 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/20160830/5d59ffa3/attachment.html From sdouglas at redhat.com Tue Aug 30 19:03:55 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 31 Aug 2016 09:03:55 +1000 Subject: [undertow-dev] Session Cookie Domain? In-Reply-To: References: Message-ID: The ResourceManager interface was not expected to be able to handle that, you should probably do that in a handler before the resource manager is invoked. Stuart On Wed, Aug 31, 2016 at 6:11 AM, Hicks, Matt wrote: > Thanks Stuart, that did the trick. > > I'm extending FileResourceManager to convert from the web path to an > internal storage path and also trying to validation against the session to > verify the logged-in state. However, I'm running into a roadblock because > `getResource` doesn't have access to the exchange to be able to get the > cookie value. I tried using ThreadLocal, but it's dispatched to another > thread so that won't work either. How am I supposed to access a cookie or > session from within a ResourceManager.getResource? > > On Mon, Aug 29, 2016 at 8:05 PM Stuart Douglas wrote: >> >> For servlet or Undertow native? >> >> For native it is controlled by the >> io.undertow.server.session.SessionCookieConfig implementation that is >> passed to the session manager. >> >> For Servlet the standard way to do it is to use a >> ServletContextListener to modify the domain under >> javax.servlet.ServletContext#getSessionCookieConfig >> >> Stuart >> >> On Fri, Aug 26, 2016 at 11:31 PM, Hicks, Matt wrote: >> > I can't seem to figure out any way to configure the session manager to >> > define the domain of the cookie. I want the domain to be *.mydomain.com >> > so >> > the cookie is shared across multiple sub-domains. Can someone give me >> > an >> > example of how to do this? >> > >> > Thanks >> > >> > _______________________________________________ >> > undertow-dev mailing list >> > undertow-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/undertow-dev From matt at matthicks.com Tue Aug 30 20:36:46 2016 From: matt at matthicks.com (Hicks, Matt) Date: Wed, 31 Aug 2016 00:36:46 +0000 Subject: [undertow-dev] Session Cookie Domain? In-Reply-To: References: Message-ID: That's unfortunate, so I completely translated ResourceHandler into Scala to be able to add the functionality I need: https://github.com/outr/hyperscala/blob/master/core/jvm/src/main/scala/org/hyperscala/FunctionalResourceManager.scala#L125 It's not the ideal solution, but it does work. I still need to do some cleanup as well, but a simple mechanism to allow some overrides or some separation of this massive block of logic into modular utilities would make Undertow far easier to customize. On Tue, Aug 30, 2016 at 6:03 PM Stuart Douglas wrote: > The ResourceManager interface was not expected to be able to handle > that, you should probably do that in a handler before the resource > manager is invoked. > > Stuart > > On Wed, Aug 31, 2016 at 6:11 AM, Hicks, Matt wrote: > > Thanks Stuart, that did the trick. > > > > I'm extending FileResourceManager to convert from the web path to an > > internal storage path and also trying to validation against the session > to > > verify the logged-in state. However, I'm running into a roadblock > because > > `getResource` doesn't have access to the exchange to be able to get the > > cookie value. I tried using ThreadLocal, but it's dispatched to another > > thread so that won't work either. How am I supposed to access a cookie > or > > session from within a ResourceManager.getResource? > > > > On Mon, Aug 29, 2016 at 8:05 PM Stuart Douglas > wrote: > >> > >> For servlet or Undertow native? > >> > >> For native it is controlled by the > >> io.undertow.server.session.SessionCookieConfig implementation that is > >> passed to the session manager. > >> > >> For Servlet the standard way to do it is to use a > >> ServletContextListener to modify the domain under > >> javax.servlet.ServletContext#getSessionCookieConfig > >> > >> Stuart > >> > >> On Fri, Aug 26, 2016 at 11:31 PM, Hicks, Matt > wrote: > >> > I can't seem to figure out any way to configure the session manager to > >> > define the domain of the cookie. I want the domain to be *. > mydomain.com > >> > so > >> > the cookie is shared across multiple sub-domains. Can someone give me > >> > an > >> > example of how to do this? > >> > > >> > Thanks > >> > > >> > _______________________________________________ > >> > 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/20160831/29a31854/attachment-0001.html From sdouglas at redhat.com Tue Aug 30 20:57:15 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 31 Aug 2016 10:57:15 +1000 Subject: [undertow-dev] Session Cookie Domain? In-Reply-To: References: Message-ID: Why can't you just add a handler before the resource handler to modify the path and verify the user is authenticated? Stuart On Wed, Aug 31, 2016 at 10:36 AM, Hicks, Matt wrote: > That's unfortunate, so I completely translated ResourceHandler into Scala to > be able to add the functionality I need: > > https://github.com/outr/hyperscala/blob/master/core/jvm/src/main/scala/org/hyperscala/FunctionalResourceManager.scala#L125 > > It's not the ideal solution, but it does work. I still need to do some > cleanup as well, but a simple mechanism to allow some overrides or some > separation of this massive block of logic into modular utilities would make > Undertow far easier to customize. > > On Tue, Aug 30, 2016 at 6:03 PM Stuart Douglas wrote: >> >> The ResourceManager interface was not expected to be able to handle >> that, you should probably do that in a handler before the resource >> manager is invoked. >> >> Stuart >> >> On Wed, Aug 31, 2016 at 6:11 AM, Hicks, Matt wrote: >> > Thanks Stuart, that did the trick. >> > >> > I'm extending FileResourceManager to convert from the web path to an >> > internal storage path and also trying to validation against the session >> > to >> > verify the logged-in state. However, I'm running into a roadblock >> > because >> > `getResource` doesn't have access to the exchange to be able to get the >> > cookie value. I tried using ThreadLocal, but it's dispatched to another >> > thread so that won't work either. How am I supposed to access a cookie >> > or >> > session from within a ResourceManager.getResource? >> > >> > On Mon, Aug 29, 2016 at 8:05 PM Stuart Douglas >> > wrote: >> >> >> >> For servlet or Undertow native? >> >> >> >> For native it is controlled by the >> >> io.undertow.server.session.SessionCookieConfig implementation that is >> >> passed to the session manager. >> >> >> >> For Servlet the standard way to do it is to use a >> >> ServletContextListener to modify the domain under >> >> javax.servlet.ServletContext#getSessionCookieConfig >> >> >> >> Stuart >> >> >> >> On Fri, Aug 26, 2016 at 11:31 PM, Hicks, Matt >> >> wrote: >> >> > I can't seem to figure out any way to configure the session manager >> >> > to >> >> > define the domain of the cookie. I want the domain to be >> >> > *.mydomain.com >> >> > so >> >> > the cookie is shared across multiple sub-domains. Can someone give >> >> > me >> >> > an >> >> > example of how to do this? >> >> > >> >> > Thanks >> >> > >> >> > _______________________________________________ >> >> > undertow-dev mailing list >> >> > undertow-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev From matt at matthicks.com Tue Aug 30 21:16:54 2016 From: matt at matthicks.com (Hicks, Matt) Date: Wed, 31 Aug 2016 01:16:54 +0000 Subject: [undertow-dev] Session Cookie Domain? In-Reply-To: References: Message-ID: For a few reasons: 1. I'd have to insulate the resource handler and directly call it from the authenticated resource (so that someone couldn't call the modified path and get the resource bypassing security). Though that wouldn't be terrible, it adds an additional stage in the process where I'd like to handle everything at once. 2. In my specific use-case the security validation will be hitting the database so I'd prefer it not occur on the IO thread anyway. 3. I'm working towards a more simplistic mapping of (path: String) => Option[Resource] to allow some paths to have different handling based on the context or state of the server and add modularity in so much as they don't need to know about each other. 4. It didn't occur to me until after I had almost finished writing it. :) It doesn't seem Undertow has a convenient capability to just serve up a File easily. That would be very useful for explicit files with explicit mappings without requiring a ResourceManager. On Tue, Aug 30, 2016 at 7:57 PM Stuart Douglas wrote: > Why can't you just add a handler before the resource handler to modify > the path and verify the user is authenticated? > > Stuart > > On Wed, Aug 31, 2016 at 10:36 AM, Hicks, Matt wrote: > > That's unfortunate, so I completely translated ResourceHandler into > Scala to > > be able to add the functionality I need: > > > > > https://github.com/outr/hyperscala/blob/master/core/jvm/src/main/scala/org/hyperscala/FunctionalResourceManager.scala#L125 > > > > It's not the ideal solution, but it does work. I still need to do some > > cleanup as well, but a simple mechanism to allow some overrides or some > > separation of this massive block of logic into modular utilities would > make > > Undertow far easier to customize. > > > > On Tue, Aug 30, 2016 at 6:03 PM Stuart Douglas > wrote: > >> > >> The ResourceManager interface was not expected to be able to handle > >> that, you should probably do that in a handler before the resource > >> manager is invoked. > >> > >> Stuart > >> > >> On Wed, Aug 31, 2016 at 6:11 AM, Hicks, Matt > wrote: > >> > Thanks Stuart, that did the trick. > >> > > >> > I'm extending FileResourceManager to convert from the web path to an > >> > internal storage path and also trying to validation against the > session > >> > to > >> > verify the logged-in state. However, I'm running into a roadblock > >> > because > >> > `getResource` doesn't have access to the exchange to be able to get > the > >> > cookie value. I tried using ThreadLocal, but it's dispatched to > another > >> > thread so that won't work either. How am I supposed to access a > cookie > >> > or > >> > session from within a ResourceManager.getResource? > >> > > >> > On Mon, Aug 29, 2016 at 8:05 PM Stuart Douglas > >> > wrote: > >> >> > >> >> For servlet or Undertow native? > >> >> > >> >> For native it is controlled by the > >> >> io.undertow.server.session.SessionCookieConfig implementation that is > >> >> passed to the session manager. > >> >> > >> >> For Servlet the standard way to do it is to use a > >> >> ServletContextListener to modify the domain under > >> >> javax.servlet.ServletContext#getSessionCookieConfig > >> >> > >> >> Stuart > >> >> > >> >> On Fri, Aug 26, 2016 at 11:31 PM, Hicks, Matt > >> >> wrote: > >> >> > I can't seem to figure out any way to configure the session manager > >> >> > to > >> >> > define the domain of the cookie. I want the domain to be > >> >> > *.mydomain.com > >> >> > so > >> >> > the cookie is shared across multiple sub-domains. Can someone give > >> >> > me > >> >> > an > >> >> > example of how to do this? > >> >> > > >> >> > Thanks > >> >> > > >> >> > _______________________________________________ > >> >> > 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/20160831/71963a12/attachment.html From peter.royal at pobox.com Wed Aug 31 10:02:46 2016 From: peter.royal at pobox.com (peter royal) Date: Wed, 31 Aug 2016 09:02:46 -0500 Subject: [undertow-dev] Session Cookie Domain? In-Reply-To: References: Message-ID: <1472652166.1230280.711545873.0FD033C4@webmail.messagingengine.com> 1- handlers are a chain, one won't be able to get to your resource handler without going through the one before it first 2- very easy to do, check if the handler is running on the IO thread. see "Dispatching to a worker thread" in http://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#undertow-handler-authors-guide 4- :) -pete -- (peter.royal|osi)@pobox.com - http://fotap.org/~osi On Tue, Aug 30, 2016, at 08:16 PM, Hicks, Matt wrote: > For a few reasons: > 1. I'd have to insulate the resource handler and directly call it > from the authenticated resource (so that someone couldn't call the > modified path and get the resource bypassing security). Though > that wouldn't be terrible, it adds an additional stage in the > process where I'd like to handle everything at once. > 2. In my specific use-case the security validation will be hitting > the database so I'd prefer it not occur on the IO thread anyway. > 3. I'm working towards a more simplistic mapping of (path: String) => > Option[Resource] to allow some paths to have different handling > based on the context or state of the server and add modularity in > so much as they don't need to know about each other. > 4. It didn't occur to me until after I had almost finished writing > it. :) > It doesn't seem Undertow has a convenient capability to just serve up > a File easily. That would be very useful for explicit files with > explicit mappings without requiring a ResourceManager. > > On Tue, Aug 30, 2016 at 7:57 PM Stuart Douglas > wrote: >> Why can't you just add a handler before the resource handler >> to modify >> the path and verify the user is authenticated? >> >> Stuart >> >> On Wed, Aug 31, 2016 at 10:36 AM, Hicks, Matt >> wrote: >> > That's unfortunate, so I completely translated ResourceHandler >> > into Scala to >> > be able to add the functionality I need: >> > >> > https://github.com/outr/hyperscala/blob/master/core/jvm/src/main/scala/org/hyperscala/FunctionalResourceManager.scala#L125 >> > >> > It's not the ideal solution, but it does work. I still need to do >> > some >> > cleanup as well, but a simple mechanism to allow some overrides or >> > some >> > separation of this massive block of logic into modular utilities >> > would make >> > Undertow far easier to customize. >> > >> > On Tue, Aug 30, 2016 at 6:03 PM Stuart Douglas >> > wrote: >> >> >> >> The ResourceManager interface was not expected to be able to >> >> handle >> >> that, you should probably do that in a handler before the >> >> resource >> >> manager is invoked. >> >> >> >> Stuart >> >> >> >> On Wed, Aug 31, 2016 at 6:11 AM, Hicks, Matt >> >> wrote: >> >> > Thanks Stuart, that did the trick. >> >> > >> >> > I'm extending FileResourceManager to convert from the web path >> >> > to an >> >> > internal storage path and also trying to validation against the >> >> > session >> >> > to >> >> > verify the logged-in state. However, I'm running into a >> >> > roadblock >> >> > because >> >> > `getResource` doesn't have access to the exchange to be able to >> >> > get the >> >> > cookie value. I tried using ThreadLocal, but it's dispatched >> >> > to another >> >> > thread so that won't work either. How am I supposed to access >> >> > a cookie >> >> > or >> >> > session from within a ResourceManager.getResource? >> >> > >> >> > On Mon, Aug 29, 2016 at 8:05 PM Stuart Douglas >> >> > >> >> > wrote: >> >> >> >> >> >> For servlet or Undertow native? >> >> >> >> >> >> For native it is controlled by the >> >> >> io.undertow.server.session.SessionCookieConfig implementation >> >> >> that is >> >> >> passed to the session manager. >> >> >> >> >> >> For Servlet the standard way to do it is to use a >> >> >> ServletContextListener to modify the domain under >> >> >> javax.servlet.ServletContext#getSessionCookieConfig >> >> >> >> >> >> Stuart >> >> >> >> >> >> On Fri, Aug 26, 2016 at 11:31 PM, Hicks, Matt >> >> >> >> >> >> wrote: >> >> >> > I can't seem to figure out any way to configure the session >> >> >> > manager >> >> >> > to >> >> >> > define the domain of the cookie. I want the domain to be >> >> >> > *.mydomain.com >> >> >> > so >> >> >> > the cookie is shared across multiple sub-domains. Can >> >> >> > someone give >> >> >> > me >> >> >> > an >> >> >> > example of how to do this? >> >> >> > >> >> >> > Thanks >> >> >> > >> >> >> > _______________________________________________ >> >> >> > 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/20160831/4455aae5/attachment-0001.html