From epeters at epicor.com Wed Jul 1 14:44:46 2015 From: epeters at epicor.com (Eric Peters) Date: Wed, 1 Jul 2015 18:44:46 +0000 Subject: [undertow-dev] InSessionMemoryManager synchronized methods In-Reply-To: References: Message-ID: I'm still trying to gauge the release process for Undertow, and where in that process this issue sits, so as to decide how to roll things out to customers on my end: - I see UNDERTOW-479 was entered for this deadlock. - I see a patch for this was pulled into Undertow 1.3.0 Beta 3 - The patch has not been back-ported to prior releases. - The Jira case is still open. What can I expect to see in the coming days? I need an answer to give management for the question of 'How soon will the patch be deemed production-ready?', but I'd appreciate any additional insight that can be provided. //EricP From: Eric Peters Sent: Thursday, June 25, 2015 5:23 PM To: Eric Peters; undertow-dev at lists.jboss.org Subject: RE: InSessionMemoryManager synchronized methods I stand corrected - This is 50% of what brought our server down. The other half of the deadlock belongs to Seam: * io.undertow.server.session.InMemorySessionManager$SessionImpl.bumpTimeout() (line: 271) * io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(java.lang.String) (line: 355) * io.undertow.servlet.spec.HttpSessionImpl.getAttribute(java.lang.String) * com.sun.faces.context.SessionMap.get(java.lang.Object) * org.jboss.seam.contexts.ServerConversationContext.get(java.lang.String) (line: 110) * org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(java.lang.String) (line: 189) * org.jboss.seam.Component.getInstanceFromFactory(java.lang.String, org.jboss.seam.ScopeType) (line: 2088) * org.jboss.seam.Component.getInstance(java.lang.String, boolean, boolean, java.lang.Object, org.jboss.seam.ScopeType) (line: 2014) * org.jboss.seam.Component.getInstance(java.lang.String, boolean, boolean) (line: 1986) * org.jboss.seam.Component.getInstance(java.lang.String, boolean) * org.jboss.seam.Namespace.getComponentInstance(java.lang.String, boolean) org.jboss.seam.Component.getInstanceFromFactory() obtains a lock that has static scope, so nothing else can invoke getInstanceFromFacotry() while the lock is held.It then blocks on InMemorySessionManager$SessionImpl.bumpTimeout() Meanwhile, the invalidate() method blocks against the static method in getInstanceFromFactory() //EricP From: undertow-dev-bounces at lists.jboss.org [mailto:undertow-dev-bounces at lists.jboss.org] On Behalf Of Eric Peters Sent: Thursday, June 25, 2015 4:39 PM To: undertow-dev at lists.jboss.org Subject: [undertow-dev] InSessionMemoryManager synchronized methods Chasing after another problem I found several blocked task threads, best as I can determine: InMemorySessionmanager$SessionImpl.invalidate() is invoked. This method is synchronized, and the call blocks inside SesssionListeners.sessionDestroyed() (separate issue there...) Later, InMemorySessionmanager$SessionImpl.bumpTimeout() is invoked from another thread. This method is also synchronized, and blocks waiting for invalidate() to complete. As the first thread is indefinitely blocked inside invalidate(), this second thread also remains blocked indefinitely. In my environment it appears to make an existing problem slightly more severe. Found in 1.1.0, but it looks like it's in both 1.1.7 and the master branch as well. Using RHEL, Java 7, Wildfly 8.2 invalidate() Thread trace (excerpt): * (blocked) - sun.misc.Unsafe.park(boolean, long) * ... * org.jboss.seam.contexts.ServletLifecycle.endSession(javax.servlet.http.HttpSession) (line: 187) * org.jboss.seam.servlet.SeamListener.sessionDestroyed(javax.servlet.http.HttpSessionEvent) (line: 59) * io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(javax.servlet.http.HttpSession) (line: 264) * io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(io.undertow.server.session.Session, io.undertow.server.HttpServerExchange, io.undertow.server.session.SessionListener$SessionDestroyedReason) (line: 67) * io.undertow.server.session.SessionListeners.sessionDestroyed(io.undertow.server.session.Session, io.undertow.server.HttpServerExchange, io.undertow.server.session.SessionListener$SessionDestroyedReason) (line: 61) * io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(io.undertow.server.HttpServerExchange, io.undertow.server.session.SessionListener$SessionDestroyedReason) (line: 413) * io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(io.undertow.server.HttpServerExchange) (line: 399) * io.undertow.servlet.spec.HttpSessionImpl.invalidate() (line: 197) * ... bumpTimeout() Thread trace: * io.undertow.server.session.InMemorySessionManager$SessionImpl.bumpTimeout() (line: 271) * io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(java.lang.String) (line: 355) * io.undertow.servlet.util.SavedRequest.tryRestoreRequest(io.undertow.server.HttpServerExchange, javax.servlet.http.HttpSession) (line: 124) * io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 67) * io.undertow.security.handlers.SecurityInitialHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 76) * io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 43) * org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 61) * io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 43) * io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 43) * io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(io.undertow.server.HttpServerExchange, io.undertow.servlet.handlers.ServletChain, io.undertow.servlet.handlers.ServletRequestContext, javax.servlet.ServletRequest, javax.servlet.ServletResponse) (line: 261) * io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(io.undertow.server.HttpServerExchange, io.undertow.servlet.handlers.ServletRequestContext, io.undertow.servlet.handlers.ServletChain, javax.servlet.DispatcherType) (line: 247) * io.undertow.servlet.handlers.ServletInitialHandler.access$000(io.undertow.servlet.handlers.ServletInitialHandler, io.undertow.server.HttpServerExchange, io.undertow.servlet.handlers.ServletRequestContext, io.undertow.servlet.handlers.ServletChain, javax.servlet.DispatcherType) * io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(io.undertow.server.HttpServerExchange) (line: 166) * io.undertow.server.Connectors.executeRootHandler(io.undertow.server.HttpHandler, io.undertow.server.HttpServerExchange) (line: 197) * io.undertow.server.HttpServerExchange$1.run() (line: 759) * java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) (line: 1145) * java.util.concurrent.ThreadPoolExecutor$Worker.run() (line: 615) * java.lang.Thread.run() (line: 745) //EricP This message has been scanned for malware by Websense. www.websense.com Click here to report this email as spam. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150701/5463cd02/attachment-0001.html From sdouglas at redhat.com Tue Jul 7 12:56:47 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 7 Jul 2015 12:56:47 -0400 (EDT) Subject: [undertow-dev] InSessionMemoryManager synchronized methods In-Reply-To: References: Message-ID: <1409507943.47460322.1436288207904.JavaMail.zimbra@redhat.com> This has been backported to the 1.2 and 1.1 branches. Which branch are you on? I will try and get a release out this week. Stuart ----- Original Message ----- > From: "Eric Peters" > To: undertow-dev at lists.jboss.org > Sent: Wednesday, 1 July, 2015 8:44:46 PM > Subject: Re: [undertow-dev] InSessionMemoryManager synchronized methods > > > > I?m still trying to gauge the release process for Undertow, and where in that > process this issue sits, so as to decide how to roll things out to customers > on my end: > > - I see UNDERTOW-479 was entered for this deadlock. > > - I see a patch for this was pulled into Undertow 1.3.0 Beta 3 > > - The patch has not been back-ported to prior releases. > > - The Jira case is still open. > > > > What can I expect to see in the coming days? I need an answer to give > management for the question of ?How soon will the patch be deemed > production-ready??, but I?d appreciate any additional insight that can be > provided. > > > > //EricP > > > > > From: Eric Peters > Sent: Thursday, June 25, 2015 5:23 PM > To: Eric Peters; undertow-dev at lists.jboss.org > Subject: RE: InSessionMemoryManager synchronized methods > > > > > I stand corrected ? This is 50% of what brought our server down. > > > > The other half of the deadlock belongs to Seam: > > > > * > io.undertow.server.session.InMemorySessionManager$SessionImpl.bumpTimeout() > (line: 271) > * > io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(java.lang.String) > (line: 355) > * io.undertow.servlet.spec.HttpSessionImpl.getAttribute(java.lang.String) > * com.sun.faces.context.SessionMap.get(java.lang.Object) > * org.jboss.seam.contexts.ServerConversationContext.get(java.lang.String) > (line: 110) > * > org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(java.lang.String) > (line: 189) > * org.jboss.seam.Component.getInstanceFromFactory(java.lang.String, > org.jboss.seam.ScopeType) (line: 2088) > * org.jboss.seam.Component.getInstance(java.lang.String, boolean, > boolean, java.lang.Object, org.jboss.seam.ScopeType) (line: 2014) > * org.jboss.seam.Component.getInstance(java.lang.String, boolean, > boolean) (line: 1986) > * org.jboss.seam.Component.getInstance(java.lang.String, boolean) > * org.jboss.seam.Namespace.getComponentInstance(java.lang.String, > boolean) > > > > > org.jboss.seam.Component.getInstanceFromFactory() obtains a lock that has > static scope, so nothing else can invoke getInstanceFromFacotry() while the > lock is held.It then blocks on > InMemorySessionManager$SessionImpl.bumpTimeout() > > Meanwhile, the invalidate() method blocks against the static method in > getInstanceFromFactory() > > //EricP > > > > > > > > > > > From: undertow-dev-bounces at lists.jboss.org [ > mailto:undertow-dev-bounces at lists.jboss.org ] On Behalf Of Eric Peters > Sent: Thursday, June 25, 2015 4:39 PM > To: undertow-dev at lists.jboss.org > Subject: [undertow-dev] InSessionMemoryManager synchronized methods > > > > > Chasing after another problem I found several blocked task threads, best as I > can determine: > > InMemorySessionmanager$SessionImpl.invalidate() is invoked. > > This method is synchronized, and the call blocks inside > SesssionListeners.sessionDestroyed() (separate issue there?) > > > > Later, InMemorySessionmanager$SessionImpl.bumpTimeout() is invoked from > another thread. > > This method is also synchronized, and blocks waiting for invalidate() to > complete. As the first thread is indefinitely blocked inside invalidate(), > this second thread also remains blocked indefinitely. > > > > In my environment it appears to make an existing problem slightly more > severe. > > > > Found in 1.1.0, but it looks like it?s in both 1.1.7 and the master branch as > well. > > Using RHEL, Java 7, Wildfly 8.2 > > > > invalidate() Thread trace (excerpt): > > * (blocked) - sun.misc.Unsafe.park(boolean, long) > * ? > * > org.jboss.seam.contexts.ServletLifecycle.endSession(javax.servlet.http.HttpSession) > (line: 187) > * > org.jboss.seam.servlet.SeamListener.sessionDestroyed(javax.servlet.http.HttpSessionEvent) > (line: 59) > * > io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(javax.servlet.http.HttpSession) > (line: 264) > * > io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(io.undertow.server.session.Session, > io.undertow.server.HttpServerExchange, > io.undertow.server.session.SessionListener$SessionDestroyedReason) > (line: 67) > * > io.undertow.server.session.SessionListeners.sessionDestroyed(io.undertow.server.session.Session, > io.undertow.server.HttpServerExchange, > io.undertow.server.session.SessionListener$SessionDestroyedReason) > (line: 61) > * > io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(io.undertow.server.HttpServerExchange, > io.undertow.server.session.SessionListener$SessionDestroyedReason) > (line: 413) > * > io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(io.undertow.server.HttpServerExchange) > (line: 399) > * io.undertow.servlet.spec.HttpSessionImpl.invalidate() (line: 197) > * ? > > > > > bumpTimeout() Thread trace: > > * > io.undertow.server.session.InMemorySessionManager$SessionImpl.bumpTimeout() > (line: 271) > * > io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(java.lang.String) > (line: 355) > * > io.undertow.servlet.util.SavedRequest.tryRestoreRequest(io.undertow.server.HttpServerExchange, > javax.servlet.http.HttpSession) (line: 124) > * > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(io.undertow.server.HttpServerExchange) > (line: 67) > * > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(io.undertow.server.HttpServerExchange) > (line: 76) > * > io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) > (line: 43) > * > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(io.undertow.server.HttpServerExchange) > (line: 61) > * > io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) > (line: 43) > * > io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) > (line: 43) > * > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(io.undertow.server.HttpServerExchange, > io.undertow.servlet.handlers.ServletChain, > io.undertow.servlet.handlers.ServletRequestContext, > javax.servlet.ServletRequest, javax.servlet.ServletResponse) (line: 261) > * > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(io.undertow.server.HttpServerExchange, > io.undertow.servlet.handlers.ServletRequestContext, > io.undertow.servlet.handlers.ServletChain, javax.servlet.DispatcherType) > (line: 247) > * > io.undertow.servlet.handlers.ServletInitialHandler.access$000(io.undertow.servlet.handlers.ServletInitialHandler, > io.undertow.server.HttpServerExchange, > io.undertow.servlet.handlers.ServletRequestContext, > io.undertow.servlet.handlers.ServletChain, javax.servlet.DispatcherType) > * > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(io.undertow.server.HttpServerExchange) > (line: 166) > * > io.undertow.server.Connectors.executeRootHandler(io.undertow.server.HttpHandler, > io.undertow.server.HttpServerExchange) (line: 197) > * io.undertow.server.HttpServerExchange$1.run() (line: 759) > * > java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) > (line: 1145) > * java.util.concurrent.ThreadPoolExecutor$Worker.run() (line: 615) > * java.lang.Thread.run() (line: 745) > > > //EricP > > > > > > This message has been scanned for malware by Websense. www.websense.com > > > > Click here to report this email as spam. > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From epeters at epicor.com Tue Jul 7 14:11:02 2015 From: epeters at epicor.com (Eric Peters) Date: Tue, 7 Jul 2015 18:11:02 +0000 Subject: [undertow-dev] InSessionMemoryManager synchronized methods In-Reply-To: <1409507943.47460322.1436288207904.JavaMail.zimbra@redhat.com> References: <1409507943.47460322.1436288207904.JavaMail.zimbra@redhat.com> Message-ID: We're still using 1.1.x to keep code churn to a minimum - internal deadlines on this end have required me to back-port to 1.1.x and build - Looking at your 1.1.x version, it's functionally identical to the 1.1.x I prepared locally, I'll keep with our version, there is no need to cut a 1.1.x for us. For others encountering UNDERTOW-479, if they are using seam I'd suggest they look at JBSEAM-4861 Fresh data: It looks like we ran into https://issues.jboss.org/browse/JBSEAM-4861 which set us up for the deadlock in Undertow by causing multiple threads to pile up on the org.jboss.seam.Component.createFromFactory() call. - Looks like Seam versions prior to 2.3.0.CR1 help create the Undertow hang. This includes the Seam 2.2.x (which we use). The fix to Undertow makes recovery from long blocks in createFromFactory() possible. The fix to JBSEAM-4861 makes the initial failure unlikely, and appears to introduce new deadlock problems. Threading in complex settings is never easy. //EricP -----Original Message----- From: Stuart Douglas [mailto:sdouglas at redhat.com] Sent: Tuesday, July 07, 2015 10:57 AM To: Eric Peters Cc: undertow-dev at lists.jboss.org Subject: Re: [undertow-dev] InSessionMemoryManager synchronized methods This has been backported to the 1.2 and 1.1 branches. Which branch are you on? I will try and get a release out this week. Stuart ----- Original Message ----- > From: "Eric Peters" > To: undertow-dev at lists.jboss.org > Sent: Wednesday, 1 July, 2015 8:44:46 PM > Subject: Re: [undertow-dev] InSessionMemoryManager synchronized > methods > > > > I?m still trying to gauge the release process for Undertow, and where > in that process this issue sits, so as to decide how to roll things > out to customers on my end: > > - I see UNDERTOW-479 was entered for this deadlock. > > - I see a patch for this was pulled into Undertow 1.3.0 Beta 3 > > - The patch has not been back-ported to prior releases. > > - The Jira case is still open. > > > > What can I expect to see in the coming days? I need an answer to give > management for the question of ?How soon will the patch be deemed > production-ready??, but I?d appreciate any additional insight that can > be provided. > > > > //EricP > > > > > From: Eric Peters > Sent: Thursday, June 25, 2015 5:23 PM > To: Eric Peters; undertow-dev at lists.jboss.org > Subject: RE: InSessionMemoryManager synchronized methods > > > > > I stand corrected ? This is 50% of what brought our server down. > > > > The other half of the deadlock belongs to Seam: > > > > * > io.undertow.server.session.InMemorySessionManager$SessionImpl.bumpTimeout() > (line: 271) > * > io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(java.lang.String) > (line: 355) > * io.undertow.servlet.spec.HttpSessionImpl.getAttribute(java.lang.String) > * com.sun.faces.context.SessionMap.get(java.lang.Object) > * org.jboss.seam.contexts.ServerConversationContext.get(java.lang.String) > (line: 110) > * > org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(java.lang.String) > (line: 189) > * org.jboss.seam.Component.getInstanceFromFactory(java.lang.String, > org.jboss.seam.ScopeType) (line: 2088) > * org.jboss.seam.Component.getInstance(java.lang.String, boolean, > boolean, java.lang.Object, org.jboss.seam.ScopeType) (line: 2014) > * org.jboss.seam.Component.getInstance(java.lang.String, boolean, > boolean) (line: 1986) > * org.jboss.seam.Component.getInstance(java.lang.String, boolean) > * org.jboss.seam.Namespace.getComponentInstance(java.lang.String, > boolean) > > > > > org.jboss.seam.Component.getInstanceFromFactory() obtains a lock that > has static scope, so nothing else can invoke getInstanceFromFacotry() > while the lock is held.It then blocks on > InMemorySessionManager$SessionImpl.bumpTimeout() > > Meanwhile, the invalidate() method blocks against the static method in > getInstanceFromFactory() > > //EricP > > > > > > > > > > > From: undertow-dev-bounces at lists.jboss.org [ > mailto:undertow-dev-bounces at lists.jboss.org ] On Behalf Of Eric Peters > Sent: Thursday, June 25, 2015 4:39 PM > To: undertow-dev at lists.jboss.org > Subject: [undertow-dev] InSessionMemoryManager synchronized methods > > > > > Chasing after another problem I found several blocked task threads, > best as I can determine: > > InMemorySessionmanager$SessionImpl.invalidate() is invoked. > > This method is synchronized, and the call blocks inside > SesssionListeners.sessionDestroyed() (separate issue there?) > > > > Later, InMemorySessionmanager$SessionImpl.bumpTimeout() is invoked > from another thread. > > This method is also synchronized, and blocks waiting for invalidate() > to complete. As the first thread is indefinitely blocked inside > invalidate(), this second thread also remains blocked indefinitely. > > > > In my environment it appears to make an existing problem slightly more > severe. > > > > Found in 1.1.0, but it looks like it?s in both 1.1.7 and the master > branch as well. > > Using RHEL, Java 7, Wildfly 8.2 > > > > invalidate() Thread trace (excerpt): > > * (blocked) - sun.misc.Unsafe.park(boolean, long) > * ? > * > org.jboss.seam.contexts.ServletLifecycle.endSession(javax.servlet.http.HttpSession) > (line: 187) > * > org.jboss.seam.servlet.SeamListener.sessionDestroyed(javax.servlet.http.HttpSessionEvent) > (line: 59) > * > io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(javax.servlet.http.HttpSession) > (line: 264) > * > io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(io.undertow.server.session.Session, > io.undertow.server.HttpServerExchange, > io.undertow.server.session.SessionListener$SessionDestroyedReason) > (line: 67) > * > io.undertow.server.session.SessionListeners.sessionDestroyed(io.undertow.server.session.Session, > io.undertow.server.HttpServerExchange, > io.undertow.server.session.SessionListener$SessionDestroyedReason) > (line: 61) > * > io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(io.undertow.server.HttpServerExchange, > io.undertow.server.session.SessionListener$SessionDestroyedReason) > (line: 413) > * > io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(io.undertow.server.HttpServerExchange) > (line: 399) > * io.undertow.servlet.spec.HttpSessionImpl.invalidate() (line: 197) > * ? > > > > > bumpTimeout() Thread trace: > > * > io.undertow.server.session.InMemorySessionManager$SessionImpl.bumpTimeout() > (line: 271) > * > io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(java.lang.String) > (line: 355) > * > io.undertow.servlet.util.SavedRequest.tryRestoreRequest(io.undertow.server.HttpServerExchange, > javax.servlet.http.HttpSession) (line: 124) > * > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(io.undertow.server.HttpServerExchange) > (line: 67) > * > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(io.undertow.server.HttpServerExchange) > (line: 76) > * > io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) > (line: 43) > * > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(io.undertow.server.HttpServerExchange) > (line: 61) > * > io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) > (line: 43) > * > io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) > (line: 43) > * > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(io.undertow.server.HttpServerExchange, > io.undertow.servlet.handlers.ServletChain, > io.undertow.servlet.handlers.ServletRequestContext, > javax.servlet.ServletRequest, javax.servlet.ServletResponse) (line: 261) > * > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(io.undertow.server.HttpServerExchange, > io.undertow.servlet.handlers.ServletRequestContext, > io.undertow.servlet.handlers.ServletChain, javax.servlet.DispatcherType) > (line: 247) > * > io.undertow.servlet.handlers.ServletInitialHandler.access$000(io.undertow.servlet.handlers.ServletInitialHandler, > io.undertow.server.HttpServerExchange, > io.undertow.servlet.handlers.ServletRequestContext, > io.undertow.servlet.handlers.ServletChain, javax.servlet.DispatcherType) > * > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(io.undertow.server.HttpServerExchange) > (line: 166) > * > io.undertow.server.Connectors.executeRootHandler(io.undertow.server.HttpHandler, > io.undertow.server.HttpServerExchange) (line: 197) > * io.undertow.server.HttpServerExchange$1.run() (line: 759) > * > java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) > (line: 1145) > * java.util.concurrent.ThreadPoolExecutor$Worker.run() (line: 615) > * java.lang.Thread.run() (line: 745) > > > //EricP > > > > > > This message has been scanned for malware by Websense. > www.websense.com > > > > Click here to report this email as spam. > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From dsimansk at redhat.com Wed Jul 15 11:05:37 2015 From: dsimansk at redhat.com (David Simansky) Date: Wed, 15 Jul 2015 11:05:37 -0400 (EDT) Subject: [undertow-dev] Camel Undertow component In-Reply-To: <1791978720.33435894.1436972038751.JavaMail.zimbra@redhat.com> Message-ID: <601942744.33441735.1436972737820.JavaMail.zimbra@redhat.com> Hi all, I just wanted to let you now, that the Apache Camel project accepted new HTTP component based on Undertow[1], regardless the missing OSGi support[2]. I've developed this component as a part of my master's thesis[3]. As always there is much to improve, I'll do my best to work with Camel community to improve it. [1] https://github.com/apache/camel/pull/562 [2] https://github.com/dsimansk/camel-undertow/issues/1 [3] https://github.com/dsimansk/thesis/raw/master/thesis.pdf Regards, David From miere.teixeira at gmail.com Wed Jul 15 11:50:52 2015 From: miere.teixeira at gmail.com (Miere Teixeira) Date: Wed, 15 Jul 2015 15:50:52 +0000 Subject: [undertow-dev] Camel Undertow component In-Reply-To: <601942744.33441735.1436972737820.JavaMail.zimbra@redhat.com> References: <1791978720.33435894.1436972038751.JavaMail.zimbra@redhat.com> <601942744.33441735.1436972737820.JavaMail.zimbra@redhat.com> Message-ID: Btw, nice thesis article. Congrats! On Wed, Jul 15, 2015 at 12:06 PM David Simansky wrote: > Hi all, > > I just wanted to let you now, that the Apache Camel project accepted new > HTTP component based on Undertow[1], regardless the missing OSGi support[2]. > I've developed this component as a part of my master's thesis[3]. > > As always there is much to improve, I'll do my best to work with Camel > community to improve it. > > [1] https://github.com/apache/camel/pull/562 > [2] https://github.com/dsimansk/camel-undertow/issues/1 > [3] https://github.com/dsimansk/thesis/raw/master/thesis.pdf > > > Regards, > David > > > _______________________________________________ > 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/20150715/ece9ce8c/attachment.html From rdavies at redhat.com Wed Jul 15 11:58:52 2015 From: rdavies at redhat.com (Rob Davies) Date: Wed, 15 Jul 2015 16:58:52 +0100 Subject: [undertow-dev] Camel Undertow component In-Reply-To: <601942744.33441735.1436972737820.JavaMail.zimbra@redhat.com> References: <601942744.33441735.1436972737820.JavaMail.zimbra@redhat.com> Message-ID: <07B03804-B175-40CA-9FED-CC2525625468@redhat.com> that is awesome! Well done David > On 15 Jul 2015, at 16:05, David Simansky wrote: > > Hi all, > > I just wanted to let you now, that the Apache Camel project accepted new HTTP component based on Undertow[1], regardless the missing OSGi support[2]. > I've developed this component as a part of my master's thesis[3]. > > As always there is much to improve, I'll do my best to work with Camel community to improve it. > > [1] https://github.com/apache/camel/pull/562 > [2] https://github.com/dsimansk/camel-undertow/issues/1 > [3] https://github.com/dsimansk/thesis/raw/master/thesis.pdf > > > Regards, > David > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From devl.development at gmail.com Thu Jul 16 07:24:49 2015 From: devl.development at gmail.com (Devl Devel) Date: Thu, 16 Jul 2015 12:24:49 +0100 Subject: [undertow-dev] SSL Client Certificate Request Message-ID: Hi group I'm trying to get a client to present its certificate when it hits the first request to my server e.g. http://localhost/run I want undertow to "ask" for client certificate. I have an undertow server with an https listener and valid sslcontext with trust and keystore. What steps are required to get a client to present the certificate. Does any one have a basic hello world example? I've tried to get hints from DefaultServer but maybe this is too much detail for what I need and I can't find a good example in the docs. Thanks in advance, Devl -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150716/a9d15c9b/attachment.html From sdouglas at redhat.com Fri Jul 17 03:01:37 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 17 Jul 2015 03:01:37 -0400 (EDT) Subject: [undertow-dev] SSL Client Certificate Request In-Reply-To: References: Message-ID: <1250249310.568471.1437116497671.JavaMail.zimbra@redhat.com> You need to specify the mode you are after using org.xnio.Options#SSL_CLIENT_AUTH_MODE, options are NONE, REQUESTED and REQUIRED. e.g. Undertow.builder() .setSocketOption(Options.SSL_CLIENT_AUTH_MODE, SslClientAuthMode.REQUESTED) ----- Original Message ----- > From: "Devl Devel" > To: undertow-dev at lists.jboss.org > Sent: Thursday, 16 July, 2015 1:24:49 PM > Subject: [undertow-dev] SSL Client Certificate Request > > Hi group > > I'm trying to get a client to present its certificate when it hits the first > request to my server > > e.g. http://localhost/run > > I want undertow to "ask" for client certificate. > > I have an undertow server with an https listener and valid sslcontext with > trust and keystore. What steps are required to get a client to present the > certificate. Does any one have a basic hello world example? > > I've tried to get hints from DefaultServer but maybe this is too much detail > for what I need and I can't find a good example in the docs. > > Thanks in advance, > Devl > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From melghaouat at gmail.com Tue Jul 28 16:27:56 2015 From: melghaouat at gmail.com (Mohammed ElGhaouat) Date: Tue, 28 Jul 2015 22:27:56 +0200 Subject: [undertow-dev] Forwarding request's parameters to error servlet Message-ID: Hello, I am working on few application's migration from Jonas which is based on tomcat to Wildfly 8.2, some of theses applications are using the section of web.xml to forward the request to a specific servlet. if the user type something like: localhost:8080/someunmappedurl/?param=elghaoua the next error-page section force a forward to a specific servlet 404 /specificServlet with tomcat this specific servlet receives the parameters of the initial request but with Wildfly/Undertow these paramters are lost. tryed on the Wildfly 8.2 and 9.0.1 Any idea how to fix this ? Thank you ! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150728/4ea1ff99/attachment.html From sdouglas at redhat.com Tue Jul 28 17:18:12 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 28 Jul 2015 17:18:12 -0400 (EDT) Subject: [undertow-dev] Forwarding request's parameters to error servlet In-Reply-To: References: Message-ID: <1273097510.72934.1438118292466.JavaMail.zimbra@redhat.com> This looks like a bug. https://issues.jboss.org/browse/UNDERTOW-505 Stuart ----- Original Message ----- > From: "Mohammed ElGhaouat" > To: undertow-dev at lists.jboss.org > Sent: Wednesday, 29 July, 2015 6:27:56 AM > Subject: [undertow-dev] Forwarding request's parameters to error servlet > > > > Hello, > > > > I am working on few application's migration from Jonas which is based on > tomcat to Wildfly 8.2, some of theses applications are using the > section of web.xml to forward the request to a specific > servlet. > > > > if the user type something like: > localhost:8080/someunmappedurl/?param=elghaoua > > > > the next error-page section force a forward to a specific servlet > > > > > > 404 > > /specificServlet > > > > > > with tomcat this specific servlet receives the parameters of the initial > request but with Wildfly/Undertow these paramters are lost. tryed on the > Wildfly 8.2 and 9.0.1 > > > > > Any idea how to fix this ? > > > > > Thank you ! > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From melghaouat at gmail.com Wed Jul 29 04:00:06 2015 From: melghaouat at gmail.com (Mohammed ElGhaouat) Date: Wed, 29 Jul 2015 10:00:06 +0200 Subject: [undertow-dev] Forwarding request's parameters to error servlet In-Reply-To: <1273097510.72934.1438118292466.JavaMail.zimbra@redhat.com> References: <1273097510.72934.1438118292466.JavaMail.zimbra@redhat.com> Message-ID: Thank you, Would it be possible to have Undertow 1.2.10 working with Wildfly 8.2.0 ? Mohammed. On Tue, Jul 28, 2015 at 11:18 PM, Stuart Douglas wrote: > This looks like a bug. > > https://issues.jboss.org/browse/UNDERTOW-505 > > Stuart > > ----- Original Message ----- > > From: "Mohammed ElGhaouat" > > To: undertow-dev at lists.jboss.org > > Sent: Wednesday, 29 July, 2015 6:27:56 AM > > Subject: [undertow-dev] Forwarding request's parameters to error servlet > > > > > > > > Hello, > > > > > > > > I am working on few application's migration from Jonas which is based on > > tomcat to Wildfly 8.2, some of theses applications are using the > > section of web.xml to forward the request to a specific > > servlet. > > > > > > > > if the user type something like: > > localhost:8080/someunmappedurl/?param=elghaoua > > > > > > > > the next error-page section force a forward to a specific servlet > > > > > > > > > > > > 404 > > > > /specificServlet > > > > > > > > > > > > with tomcat this specific servlet receives the parameters of the initial > > request but with Wildfly/Undertow these paramters are lost. tryed on the > > Wildfly 8.2 and 9.0.1 > > > > > > > > > > Any idea how to fix this ? > > > > > > > > > > Thank you ! > > > > _______________________________________________ > > 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/20150729/7e5d355c/attachment.html From sdouglas at redhat.com Thu Jul 30 23:11:09 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 30 Jul 2015 23:11:09 -0400 (EDT) Subject: [undertow-dev] Forwarding request's parameters to error servlet In-Reply-To: References: <1273097510.72934.1438118292466.JavaMail.zimbra@redhat.com> Message-ID: <798880216.2204722.1438312269250.JavaMail.zimbra@redhat.com> Probably, although it has not been tested. I also backported the fix to 1.1.x, so you could build a copy from that branch. Stuart ----- Original Message ----- > From: "Mohammed ElGhaouat" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Wednesday, 29 July, 2015 6:00:06 PM > Subject: Re: [undertow-dev] Forwarding request's parameters to error servlet > > Thank you, > > Would it be possible to have Undertow 1.2.10 working with Wildfly 8.2.0 ? > > > Mohammed. > > On Tue, Jul 28, 2015 at 11:18 PM, Stuart Douglas > wrote: > > > This looks like a bug. > > > > https://issues.jboss.org/browse/UNDERTOW-505 > > > > Stuart > > > > ----- Original Message ----- > > > From: "Mohammed ElGhaouat" > > > To: undertow-dev at lists.jboss.org > > > Sent: Wednesday, 29 July, 2015 6:27:56 AM > > > Subject: [undertow-dev] Forwarding request's parameters to error servlet > > > > > > > > > > > > Hello, > > > > > > > > > > > > I am working on few application's migration from Jonas which is based on > > > tomcat to Wildfly 8.2, some of theses applications are using the > > > section of web.xml to forward the request to a specific > > > servlet. > > > > > > > > > > > > if the user type something like: > > > localhost:8080/someunmappedurl/?param=elghaoua > > > > > > > > > > > > the next error-page section force a forward to a specific servlet > > > > > > > > > > > > > > > > > > 404 > > > > > > /specificServlet > > > > > > > > > > > > > > > > > > with tomcat this specific servlet receives the parameters of the initial > > > request but with Wildfly/Undertow these paramters are lost. tryed on the > > > Wildfly 8.2 and 9.0.1 > > > > > > > > > > > > > > > Any idea how to fix this ? > > > > > > > > > > > > > > > Thank you ! > > > > > > _______________________________________________ > > > undertow-dev mailing list > > > undertow-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > From fabian.mager at gmail.com Mon Jul 27 11:48:39 2015 From: fabian.mager at gmail.com (Fabian Mager) Date: Mon, 27 Jul 2015 17:48:39 +0200 Subject: [undertow-dev] ServerSentEventConnection Message-ID: Hi all, is there a way to access the queryParameters of an HttpServerExchange object via a ServerSentEventConnection object? As far as I can see, there is only access to certain members of the exchange object. In case it is not possible, would it be problematic in some ways to implement it? Thanks in advance, Fabian