From wolfgang.knauf at gmx.de Fri Aug 8 16:05:24 2014 From: wolfgang.knauf at gmx.de (Wolfgang Knauf) Date: Fri, 08 Aug 2014 22:05:24 +0200 Subject: [undertow-dev] "unauthenticatedIndentity" in Undertow Message-ID: <53E52D84.2060805@gmx.de> Hi guys, I try to sort out the "unauthenticatedIdentity" feature for JAS login modules in WildFly 8. To my understanding, when logging in without username/password, the login module should fallback to this "unauthenticatedIndentity", which can only access public content (e.g. unsecured or @PermitAll ejb methods). But without a login, my public ejb method shows that "this.sessionContext.getCallerPrincipal().getName()" returns "anonymous", which is NOT the "unauthenticatedIdentity" value. And "httpRequest.login(null, null)" will fail because of the Undertow implementation. How can a switch to the user name declared in the "unauthenticatedIdentity"? Same question e.g. here: https://community.jboss.org/thread/237899 Seems I have a basic misunderstanding about this ;-), but I don't find a clear explanation in the web... Best regards Wolfgang Knauf From arjan.tijms at gmail.com Sat Aug 9 08:33:35 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Sat, 9 Aug 2014 14:33:35 +0200 Subject: [undertow-dev] "unauthenticatedIndentity" in Undertow In-Reply-To: <53E52D84.2060805@gmx.de> References: <53E52D84.2060805@gmx.de> Message-ID: Hi, Although it's not directly what you asked, one thing which you may want to take into account is that in the web layer (via HttpServletRequest) the user/caller principal corresponding to the unauthenticated identity is always null. When using the EJBContext that same user/caller principal is something container specific (although contrary to the web layer never null). EJB is underspecified here (just as the run-as principal). Likewise, the way in which a security context established in the web layer propagates to EJB is not clear either. There's a vague paragraph about a security domain that should be consulted, which JBoss takes very literally (for secured beans it attempts to re-authenticate instead of propagating the established context), for non-secured beans it doesn't do this. Finally there are a couple of implementation differences between JBoss' native login modules and the Java EE standard JASPIC ones. For JASPIC you would call HttpServletRequest.authenticate() and the "login module" (SAM) would pass a null to the CallerPrincipalCallback in order to establish the unauthenticated identity. Hope this somehow helps. On Friday, August 8, 2014, Wolfgang Knauf wrote: > Hi guys, > > I try to sort out the "unauthenticatedIdentity" feature for JAS login > modules in WildFly 8. > To my understanding, when logging in without username/password, the > login module should fallback to this "unauthenticatedIndentity", which > can only access public content (e.g. unsecured or @PermitAll ejb methods). > > But without a login, my public ejb method shows that > "this.sessionContext.getCallerPrincipal().getName()" returns > "anonymous", which is NOT the "unauthenticatedIdentity" value. > And "httpRequest.login(null, null)" will fail because of the Undertow > implementation. > > How can a switch to the user name declared in the > "unauthenticatedIdentity"? > > Same question e.g. here: https://community.jboss.org/thread/237899 > > Seems I have a basic misunderstanding about this ;-), but I don't find a > clear explanation in the web... > > Best regards > > Wolfgang Knauf > _______________________________________________ > 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/20140809/32f207fd/attachment-0001.html From wolfgang.knauf at gmx.de Sun Aug 10 14:24:07 2014 From: wolfgang.knauf at gmx.de (Wolfgang Knauf) Date: Sun, 10 Aug 2014 20:24:07 +0200 Subject: [undertow-dev] "unauthenticatedIndentity" in Undertow In-Reply-To: References: <53E52D84.2060805@gmx.de> Message-ID: <53E7B8C7.8000804@gmx.de> Hi Arjan, thanks for your reply, but I fear it does not help much. I think my basic question should be "what is the unauthenticatedIdentity used for?". If this question is answered, the next question could be "how could one use it in a web app or application client?" I tried to call HttpServletRequest.authenticate() in an unsecured JSP page, and this redirected me to my login form - so no help ;-). Best regards Wolfgang -------- Original-Nachricht -------- Betreff: Re: [undertow-dev] "unauthenticatedIndentity" in Undertow Von: arjan tijms An: Wolfgang Knauf Kopie (CC): "undertow-dev at lists.jboss.org" Datum: 09.08.2014 14:33 > Hi, > > Although it's not directly what you asked, one thing which you may want > to take into account is that in the web layer (via HttpServletRequest) > the user/caller principal corresponding to the unauthenticated identity > is always null. When using the EJBContext that same user/caller > principal is something container specific (although contrary to the web > layer never null). > > EJB is underspecified here (just as the run-as principal). Likewise, the > way in which a security context established in the web layer propagates > to EJB is not clear either. There's a vague paragraph about a security > domain that should be consulted, which JBoss takes very literally (for > secured beans it attempts to re-authenticate instead of propagating the > established context), for non-secured beans it doesn't do this. > > Finally there are a couple of implementation differences between JBoss' > native login modules and the Java EE standard JASPIC ones. For JASPIC > you would call HttpServletRequest.authenticate() and the "login module" > (SAM) would pass a null to the CallerPrincipalCallback in order to > establish the unauthenticated identity. > > Hope this somehow helps. > > On Friday, August 8, 2014, Wolfgang Knauf > wrote: > > Hi guys, > > I try to sort out the "unauthenticatedIdentity" feature for JAS login > modules in WildFly 8. > To my understanding, when logging in without username/password, the > login module should fallback to this "unauthenticatedIndentity", which > can only access public content (e.g. unsecured or @PermitAll ejb > methods). > > But without a login, my public ejb method shows that > "this.sessionContext.getCallerPrincipal().getName()" returns > "anonymous", which is NOT the "unauthenticatedIdentity" value. > And "httpRequest.login(null, null)" will fail because of the Undertow > implementation. > > How can a switch to the user name declared in the > "unauthenticatedIdentity"? > > Same question e.g. here: https://community.jboss.org/thread/237899 > > Seems I have a basic misunderstanding about this ;-), but I don't find a > clear explanation in the web... > > Best regards > > Wolfgang Knauf > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From darran.lofthouse at jboss.com Mon Aug 11 04:04:12 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 11 Aug 2014 09:04:12 +0100 Subject: [undertow-dev] Can we please have a notification scheme enabled for Undertow Jira? In-Reply-To: <52935545.70100@jboss.com> References: <5166DC58.1090800@jboss.com> <52935545.70100@jboss.com> Message-ID: <53E878FC.202@jboss.com> If there are no objections I am going to go ahead and ask eng-ops to set the notification scheme for the Undertow project in Jira to use the same scheme as is in use by WildFly. Regards, Darran Lofthouse. On 25/11/13 13:48, Darran Lofthouse wrote: > Did we ever get the notifications sent to a mailing list? > > On 11/04/13 16:52, Darran Lofthouse wrote: >> Can we please have a notification scheme enabling for the Undertow Jira >> project so that we can receive e-mail notifications. >> >> I would suggest just use the same one as is used for Remoting JMX, it >> should be sufficient to have the notifications go to the general mailing >> list and interested individuals. >> >> Regards, >> Darran Lofthouse. >> _______________________________________________ >> 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 > From sdouglas at redhat.com Mon Aug 11 19:25:36 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 12 Aug 2014 09:25:36 +1000 Subject: [undertow-dev] Can we please have a notification scheme enabled for Undertow Jira? In-Reply-To: <53E878FC.202@jboss.com> References: <5166DC58.1090800@jboss.com> <52935545.70100@jboss.com> <53E878FC.202@jboss.com> Message-ID: <53E950F0.9080409@redhat.com> No objection here, although I do wonder if we should have a separate list just for JIRA issues, so we don't spam subscribers to this list with notifications they are not interested in. Stuart Darran Lofthouse wrote: > If there are no objections I am going to go ahead and ask eng-ops to set > the notification scheme for the Undertow project in Jira to use the same > scheme as is in use by WildFly. > > Regards, > Darran Lofthouse. > > > On 25/11/13 13:48, Darran Lofthouse wrote: >> Did we ever get the notifications sent to a mailing list? >> >> On 11/04/13 16:52, Darran Lofthouse wrote: >>> Can we please have a notification scheme enabling for the Undertow Jira >>> project so that we can receive e-mail notifications. >>> >>> I would suggest just use the same one as is used for Remoting JMX, it >>> should be sufficient to have the notifications go to the general >>> mailing >>> list and interested individuals. >>> >>> Regards, >>> Darran Lofthouse. >>> _______________________________________________ >>> 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 >> > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From darran.lofthouse at jboss.com Tue Aug 12 05:03:37 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 12 Aug 2014 10:03:37 +0100 Subject: [undertow-dev] Can we please have a notification scheme enabled for Undertow Jira? In-Reply-To: <53E950F0.9080409@redhat.com> References: <5166DC58.1090800@jboss.com> <52935545.70100@jboss.com> <53E878FC.202@jboss.com> <53E950F0.9080409@redhat.com> Message-ID: <53E9D869.2090302@jboss.com> Hi Stuart, No what I am suggesting is using the same notification schema as WildFly - that scheme is used by a few projects to send notifications to jboss-jira at lists.jboss.org so users do have a choice which list to use. Regards, Darran Lofthouse. On 12/08/14 00:25, Stuart Douglas wrote: > No objection here, although I do wonder if we should have a separate > list just for JIRA issues, so we don't spam subscribers to this list > with notifications they are not interested in. > > Stuart > > Darran Lofthouse wrote: >> If there are no objections I am going to go ahead and ask eng-ops to set >> the notification scheme for the Undertow project in Jira to use the same >> scheme as is in use by WildFly. >> >> Regards, >> Darran Lofthouse. >> >> >> On 25/11/13 13:48, Darran Lofthouse wrote: >>> Did we ever get the notifications sent to a mailing list? >>> >>> On 11/04/13 16:52, Darran Lofthouse wrote: >>>> Can we please have a notification scheme enabling for the Undertow Jira >>>> project so that we can receive e-mail notifications. >>>> >>>> I would suggest just use the same one as is used for Remoting JMX, it >>>> should be sufficient to have the notifications go to the general >>>> mailing >>>> list and interested individuals. >>>> >>>> Regards, >>>> Darran Lofthouse. >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev From arjan.tijms at gmail.com Tue Aug 12 06:28:16 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 12 Aug 2014 12:28:16 +0200 Subject: [undertow-dev] "unauthenticatedIndentity" in Undertow In-Reply-To: <53E7B8C7.8000804@gmx.de> References: <53E52D84.2060805@gmx.de> <53E7B8C7.8000804@gmx.de> Message-ID: On Sunday, August 10, 2014, Wolfgang Knauf wrote: > I think my > basic question should be "what is the unauthenticatedIdentity used > for?" Afaik the unauthenticated identity that's exposed to user code is a very unfortunate result of the fact that whoever wrote the first EJB spec thought it was a good idea to add the requirement "never null" to the return value of EJBContext#getCallerPrincipal. I'm sure it was done with the best intentions, but without also defining a constant that we can use to compare to (ie via a reference) OR an explicit "isCallerAuthenticated" method, this has been nothing but a world of hurt. The problem is that now there's no real good way to check if a user is authenticated in EJB. A null return would be a good method, but since that value is mysteriously not allowed the container has to use a regular principal. You should then compare the name of this principal to whatever the container has decided to use to determine if the user is authenticated or not. This is a recipe for disaster, since without reserving a name, any name the container chooses could be a valid name in the application domain. It just can't work this way. As a workaround some containers like JBoss offer the option to remap the name to something, should it clash. . If this question is answered, the next question could be "how > could one use it in a web app or application client?" See above, to test if the user is authenticated or not. I tried to call HttpServletRequest.authenticate() in an unsecured JSP > page, and this redirected me to my login form - so no help ;-). This is because the SAM or login module that you configured wasn't instructed to "do nothing" ;) But my mentioning of request#authenticate was just an explanation of how a SAM could "do nothing" even after an explicit request for authentication. A SAM is a special case here since it's always called for every request (just like a Servlet Filter). If I'm not mistaken, JBoss' proprietary login modules are only called when authentication is explicitly required. Kind regards, Arjan > > Best regards > > Wolfgang > > -------- Original-Nachricht -------- > Betreff: Re: [undertow-dev] "unauthenticatedIndentity" in Undertow > Von: arjan tijms > > An: Wolfgang Knauf > > Kopie (CC): "undertow-dev at lists.jboss.org " < > undertow-dev at lists.jboss.org > > Datum: 09.08.2014 14:33 > > > Hi, > > > > Although it's not directly what you asked, one thing which you may want > > to take into account is that in the web layer (via HttpServletRequest) > > the user/caller principal corresponding to the unauthenticated identity > > is always null. When using the EJBContext that same user/caller > > principal is something container specific (although contrary to the web > > layer never null). > > > > EJB is underspecified here (just as the run-as principal). Likewise, the > > way in which a security context established in the web layer propagates > > to EJB is not clear either. There's a vague paragraph about a security > > domain that should be consulted, which JBoss takes very literally (for > > secured beans it attempts to re-authenticate instead of propagating the > > established context), for non-secured beans it doesn't do this. > > > > Finally there are a couple of implementation differences between JBoss' > > native login modules and the Java EE standard JASPIC ones. For JASPIC > > you would call HttpServletRequest.authenticate() and the "login module" > > (SAM) would pass a null to the CallerPrincipalCallback in order to > > establish the unauthenticated identity. > > > > Hope this somehow helps. > > > > On Friday, August 8, 2014, Wolfgang Knauf > > >> wrote: > > > > Hi guys, > > > > I try to sort out the "unauthenticatedIdentity" feature for JAS login > > modules in WildFly 8. > > To my understanding, when logging in without username/password, the > > login module should fallback to this "unauthenticatedIndentity", > which > > can only access public content (e.g. unsecured or @PermitAll ejb > > methods). > > > > But without a login, my public ejb method shows that > > "this.sessionContext.getCallerPrincipal().getName()" returns > > "anonymous", which is NOT the "unauthenticatedIdentity" value. > > And "httpRequest.login(null, null)" will fail because of the Undertow > > implementation. > > > > How can a switch to the user name declared in the > > "unauthenticatedIdentity"? > > > > Same question e.g. here: https://community.jboss.org/thread/237899 > > > > Seems I have a basic misunderstanding about this ;-), but I don't > find a > > clear explanation in the web... > > > > Best regards > > > > Wolfgang Knauf > > _______________________________________________ > > 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/20140812/19535f2d/attachment-0001.html From lponce at redhat.com Tue Aug 12 11:28:21 2014 From: lponce at redhat.com (Lucas Ponce) Date: Tue, 12 Aug 2014 11:28:21 -0400 (EDT) Subject: [undertow-dev] Build on Windows 7 Message-ID: <2135322662.6025589.1407857301967.JavaMail.zimbra@redhat.com> Hi, I am trying to build current master (Commit: ceb019c91bd5ff5f219093298be93452770c3a70 Checkstyle) on Windows 7, failing with this error: http://pastebin.com/EP4y5pu4 Is there perhaps some specific config/flag for windows ? I can build it in linux (Fedora 19) without issues. Thanks, Lucas From tomaz.cerar at gmail.com Tue Aug 12 16:48:34 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 12 Aug 2014 22:48:34 +0200 Subject: [undertow-dev] Build on Windows 7 In-Reply-To: <2135322662.6025589.1407857301967.JavaMail.zimbra@redhat.com> References: <2135322662.6025589.1407857301967.JavaMail.zimbra@redhat.com> Message-ID: Hey, I have no issues with this test on windows 8, however there is currently failing MultiPartTestCase.testMultiPartRequestToLarge test on windows. if you just need to build the server, just do it with -DskipTests and you should be fine. On Tue, Aug 12, 2014 at 5:28 PM, Lucas Ponce wrote: > Hi, > > I am trying to build current master (Commit: > ceb019c91bd5ff5f219093298be93452770c3a70 Checkstyle) on Windows 7, failing > with this error: > > http://pastebin.com/EP4y5pu4 > > Is there perhaps some specific config/flag for windows ? > > I can build it in linux (Fedora 19) without issues. > > Thanks, > Lucas > _______________________________________________ > 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/20140812/22a78ef3/attachment.html From sdouglas at redhat.com Tue Aug 12 21:50:54 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 13 Aug 2014 11:50:54 +1000 Subject: [undertow-dev] Build on Windows 7 In-Reply-To: <2135322662.6025589.1407857301967.JavaMail.zimbra@redhat.com> References: <2135322662.6025589.1407857301967.JavaMail.zimbra@redhat.com> Message-ID: <53EAC47E.5020700@redhat.com> Can you try with current upstream? I think I have fixed the issue. Stuart Lucas Ponce wrote: > Hi, > > I am trying to build current master (Commit: ceb019c91bd5ff5f219093298be93452770c3a70 Checkstyle) on Windows 7, failing with this error: > > http://pastebin.com/EP4y5pu4 > > Is there perhaps some specific config/flag for windows ? > > I can build it in linux (Fedora 19) without issues. > > Thanks, > Lucas > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From tomaz.cerar at gmail.com Wed Aug 13 09:36:08 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 13 Aug 2014 15:36:08 +0200 Subject: [undertow-dev] Build on Windows 7 In-Reply-To: <53EAC47E.5020700@redhat.com> References: <2135322662.6025589.1407857301967.JavaMail.zimbra@redhat.com> <53EAC47E.5020700@redhat.com> Message-ID: Your changes makes default build / testsuite pass on windows /w JDK7. Using -Pproxy still fails with SslUpgradeTestCase.testAsyncUpgrade{proxy} ? Runtime Buffer Leak io.undertow.s... SslUpgradeTestCase.testBlockingUpgrade{proxy} ? Runtime Buffer Leak io.underto... SslUpgradeTestCase.testBlockingUpgrade{proxy} ? Runtime Buffer Leak io.underto... On Wed, Aug 13, 2014 at 3:50 AM, Stuart Douglas wrote: > Can you try with current upstream? I think I have fixed the issue. > > Stuart > > Lucas Ponce wrote: > > Hi, > > > > I am trying to build current master (Commit: > ceb019c91bd5ff5f219093298be93452770c3a70 Checkstyle) on Windows 7, failing > with this error: > > > > http://pastebin.com/EP4y5pu4 > > > > Is there perhaps some specific config/flag for windows ? > > > > I can build it in linux (Fedora 19) without issues. > > > > Thanks, > > Lucas > > _______________________________________________ > > 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/20140813/2fe7abbf/attachment.html From wolfgang.knauf at gmx.de Wed Aug 13 16:01:55 2014 From: wolfgang.knauf at gmx.de (Wolfgang Knauf) Date: Wed, 13 Aug 2014 22:01:55 +0200 Subject: [undertow-dev] "unauthenticatedIndentity" in Undertow In-Reply-To: References: <53E52D84.2060805@gmx.de> <53E7B8C7.8000804@gmx.de> Message-ID: <53EBC433.1060209@gmx.de> Hi Arjan, thanks for the explanations. But I think I won't continue digging deeper in the "unauthenticatedIdentity" area ;-). Seems this is something that is not worth to know about ;-) Best regards Wolfgang -------- Original-Nachricht -------- Betreff: Re: [undertow-dev] "unauthenticatedIndentity" in Undertow Von: arjan tijms An: Wolfgang Knauf Kopie (CC): "undertow-dev at lists.jboss.org" Datum: 12.08.2014 12:28 > On Sunday, August 10, 2014, Wolfgang Knauf wrote: > > I think my > basic question should be "what is the unauthenticatedIdentity used > for?" > > > Afaik the unauthenticated identity that's exposed to user code is a very > unfortunate result of the fact that whoever wrote the first EJB spec > thought it was a good idea to add the requirement "never null" to the > return value of EJBContext#getCallerPrincipal. > > I'm sure it was done with the best intentions, but without also defining > a constant that we can use to compare to (ie via a reference) OR an > explicit "isCallerAuthenticated" method, this has been nothing but a > world of hurt. > > The problem is that now there's no real good way to check if a user is > authenticated in EJB. A null return would be a good method, but since > that value is mysteriously not allowed the container has to use a > regular principal. You should then compare the name of this principal to > whatever the container has decided to use to determine if the user is > authenticated or not. > > This is a recipe for disaster, since without reserving a name, any name > the container chooses could be a valid name in the application domain. > It just can't work this way. > > As a workaround some containers like JBoss offer the option to remap the > name to something, should it clash. > > . If this question is answered, the next question could be "how > could one use it in a web app or application client?" > > > See above, to test if the user is authenticated or not. > > I tried to call HttpServletRequest.authenticate() in an unsecured JSP > page, and this redirected me to my login form - so no help ;-). > > > This is because the SAM or login module that you configured wasn't > instructed to "do nothing" ;) > > But my mentioning of request#authenticate was just an explanation of how > a SAM could "do nothing" even after an explicit request for > authentication. A SAM is a special case here since it's always called > for every request (just like a Servlet Filter). If I'm not mistaken, > JBoss' proprietary login modules are only called when authentication is > explicitly required. > > Kind regards, > Arjan > > > Best regards > > Wolfgang > > -------- Original-Nachricht -------- > Betreff: Re: [undertow-dev] "unauthenticatedIndentity" in Undertow > Von: arjan tijms > > An: Wolfgang Knauf > > Kopie (CC): "undertow-dev at lists.jboss.org " > > > Datum: 09.08.2014 14:33 > > > Hi, > > > > Although it's not directly what you asked, one thing which you > may want > > to take into account is that in the web layer (via > HttpServletRequest) > > the user/caller principal corresponding to the unauthenticated > identity > > is always null. When using the EJBContext that same user/caller > > principal is something container specific (although contrary to > the web > > layer never null). > > > > EJB is underspecified here (just as the run-as principal). > Likewise, the > > way in which a security context established in the web layer > propagates > > to EJB is not clear either. There's a vague paragraph about a > security > > domain that should be consulted, which JBoss takes very literally > (for > > secured beans it attempts to re-authenticate instead of > propagating the > > established context), for non-secured beans it doesn't do this. > > > > Finally there are a couple of implementation differences between > JBoss' > > native login modules and the Java EE standard JASPIC ones. For JASPIC > > you would call HttpServletRequest.authenticate() and the "login > module" > > (SAM) would pass a null to the CallerPrincipalCallback in order to > > establish the unauthenticated identity. > > > > Hope this somehow helps. > > > > On Friday, August 8, 2014, Wolfgang Knauf > > >> wrote: > > > > Hi guys, > > > > I try to sort out the "unauthenticatedIdentity" feature for > JAS login > > modules in WildFly 8. > > To my understanding, when logging in without > username/password, the > > login module should fallback to this > "unauthenticatedIndentity", which > > can only access public content (e.g. unsecured or @PermitAll ejb > > methods). > > > > But without a login, my public ejb method shows that > > "this.sessionContext.getCallerPrincipal().getName()" returns > > "anonymous", which is NOT the "unauthenticatedIdentity" value. > > And "httpRequest.login(null, null)" will fail because of the > Undertow > > implementation. > > > > How can a switch to the user name declared in the > > "unauthenticatedIdentity"? > > > > Same question e.g. here: > https://community.jboss.org/thread/237899 > > > > Seems I have a basic misunderstanding about this ;-), but I > don't find a > > clear explanation in the web... > > > > Best regards > > > > Wolfgang Knauf > > _______________________________________________ > > 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 > From flushdia at gmail.com Fri Aug 15 18:51:02 2014 From: flushdia at gmail.com (Vladimir Tsukur) Date: Sat, 16 Aug 2014 01:51:02 +0300 Subject: [undertow-dev] Retrieving request entity Message-ID: One of the ways to obtain request entity is to call HttpServerExchange.startBlocking and then read content from the HttpServerExchange.getInputStream. Is there a way to obtain request entity in a non-blocking way? -- Vladimir Tsukur Software Architect, Design Engineer and Scrum Master -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140816/6ef4455d/attachment.html From flushdia at gmail.com Fri Aug 15 19:32:32 2014 From: flushdia at gmail.com (Vladimir Tsukur) Date: Sat, 16 Aug 2014 02:32:32 +0300 Subject: [undertow-dev] Sending response asynchronously to IO or worker thread Message-ID: Imagine the use case when sending response does not happen from IO or worker thread, but instead originates as a part of asynchronous event handling in an application thread. Below is a code snippet for a simple timer use case where response is meant to be sent in 5 seconds after receiving a request. This solution is put here just to illustrate the point, it does NOT work for the obvious reason that we'll cover later: final Undertow undertow = Undertow.builder() .addHttpListener(9090, "localhost") .setHandler(new HttpHandler() { public void handleRequest(final HttpServerExchange exchange) throws Exception { new Timer().schedule(new TimerTask() { public void run() { exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain"); exchange.getResponseSender().send("Returned in 5 seconds"); } }, 5000); } }).build(); undertow.start(); This handler is implemented incorrectly because exchange will end right after handleRequest method is called. In order to fix this we can use dispatching (only implementation of handleRequest method is shown): public void handleRequest(final HttpServerExchange exchange) throws Exception { if (exchange.isInIoThread()) { exchange.dispatch(new Runnable() { public void run() { new Timer().schedule(new TimerTask() { public void run() { Connectors.executeRootHandler(new HttpHandler() { public void handleRequest(HttpServerExchange exchange) throws Exception { exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain"); exchange.getResponseSender().send("Returned in 5 seconds"); } }, exchange); } }, 5000); } }); } } Please pay attention that the requirement here is not to use dumb blocking in the work thread (like Thread.sleep(5000)) but rely on asynchronous event handling instead. I would appreciate if someone can answer the following questions: - Are there any pitfalls with the working dispatch/executeRootHandler solution mentioned above? - Is there a simpler and more elegant way to achieve the same? -- Vladimir Tsukur Software Architect, Design Engineer and Scrum Master -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140816/cc823772/attachment-0001.html From sdouglas at redhat.com Sun Aug 17 19:34:24 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 18 Aug 2014 09:34:24 +1000 Subject: [undertow-dev] Retrieving request entity In-Reply-To: References: Message-ID: <53F13C00.9020603@redhat.com> You can use the getRequestChannel() method to get the request channel. Basically call read() on the channel till it returns either 0 or -1, if it returns -1 you are done, if it returns 0 register a read listener and call resumeReads(). I have always been meaning to add a nicer non-blocking API for this, but I have never been exactly sure what would be required here. Thinking about it we probably just need some way to buffer a complete/partial message and then invoke a callback with the data. Stuart Vladimir Tsukur wrote: > One of the ways to obtain request entity is to call > HttpServerExchange.startBlocking and then read content from the > HttpServerExchange.getInputStream. > > Is there a way to obtain request entity in a non-blocking way? > > -- > Vladimir Tsukur > Software Architect, Design Engineer and Scrum Master > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Sun Aug 17 19:42:58 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 18 Aug 2014 09:42:58 +1000 Subject: [undertow-dev] Sending response asynchronously to IO or worker thread In-Reply-To: References: Message-ID: <53F13E02.20807@redhat.com> > > This handler is implemented incorrectly because exchange will end right > after handleRequest method is called. > > In order to fix this we can use dispatching (only implementation of > handleRequest method is shown): > > public void handleRequest(final HttpServerExchange exchange) throws > Exception { > if (exchange.isInIoThread()) { > exchange.dispatch(new Runnable() { > public void run() { > new Timer().schedule(new TimerTask() { > public void run() { > Connectors.executeRootHandler(new > HttpHandler() { > public void > handleRequest(HttpServerExchange exchange) throws Exception { > > exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain"); > > exchange.getResponseSender().send("Returned in 5 seconds"); > } > }, exchange); > } > }, 5000); > } > }); > } > } > > Please pay attention that the requirement here is not to use dumb > blocking in the work thread (like Thread.sleep(5000)) but rely on > asynchronous event handling instead. > > I would appreciate if someone can answer the following questions: > You don't need the isInIoThread() check, otherwise this handler will do nothing if an earlier handler dispatched (e.g. a security handler that needed to do a blocking LDAP lookup). > * Are there any pitfalls with the working dispatch/executeRootHandler > solution mentioned above? No, this is the correct way to do it. Undertow's exchange is not thread safe (as making it thread safe seriously degrades performance by an order of magnitude). Instead multi-threading is implemented by having a safe hand off point (the dispatch() method), which basically allows a thread to hand off to another thread when it is done, so only one thread 'owns' the exchange at a time. You can just call the dispatch() method with no arguments to stop the exchange ending, but if your async task finished before the call stack returns then you will have two threads active in the exchange, which will cause all kinds of potential problems (this is not going to happen with a 5000ms delay, but with a 1ms delay it will). > * Is there a simpler and more elegant way to achieve the same? I assume you are not actually dealing with timers and this was just an example, but if you do want to schedule a task (like a timeout for instance) you can schedule it using exchange.getIoThread().executeAfter(), which will run the timed task in the IO thread. Stuart > > -- > Vladimir Tsukur > Software Architect, Design Engineer and Scrum Master > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From flushdia at gmail.com Mon Aug 18 04:16:09 2014 From: flushdia at gmail.com (Vladimir Tsukur) Date: Mon, 18 Aug 2014 11:16:09 +0300 Subject: [undertow-dev] Retrieving request entity In-Reply-To: <53F13C00.9020603@redhat.com> References: <53F13C00.9020603@redhat.com> Message-ID: Thanks for explaining the option with getRequestChannel! Got it working by reading content into a pre-allocated ByteBuffer. if it returns 0 register a read listener and call resumeReads() One thing I don't fully understand though is your note about registering a read listener (+ calling resumeReads) and why this is needed. Is it a mandatory step, and if it is, are you referring to application-specific read listener or Undertow's io.undertow.server.protocol.http.HttpReadListener? I guess this is pretty basic question, so it would be great if you can just point me to the right place at documentation, so that I can figure it out. Thinking about it we probably just need some way to buffer a > complete/partial message and then invoke a callback with the data. Yep, I guess this would be easier for the app developer to use. On Mon, Aug 18, 2014 at 2:34 AM, Stuart Douglas wrote: > You can use the getRequestChannel() method to get the request channel. > Basically call read() on the channel till it returns either 0 or -1, if it > returns -1 you are done, if it returns 0 register a read listener and call > resumeReads(). > > I have always been meaning to add a nicer non-blocking API for this, but I > have never been exactly sure what would be required here. Thinking about it > we probably just need some way to buffer a complete/partial message and > then invoke a callback with the data. > > Stuart > > Vladimir Tsukur wrote: > >> One of the ways to obtain request entity is to call >> HttpServerExchange.startBlocking and then read content from the >> HttpServerExchange.getInputStream. >> >> Is there a way to obtain request entity in a non-blocking way? >> >> -- >> Vladimir Tsukur >> Software Architect, Design Engineer and Scrum Master >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> > -- Vladimir Tsukur Software Architect, Design Engineer and Scrum Master -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140818/11eadde7/attachment.html From flushdia at gmail.com Mon Aug 18 04:19:32 2014 From: flushdia at gmail.com (Vladimir Tsukur) Date: Mon, 18 Aug 2014 11:19:32 +0300 Subject: [undertow-dev] Sending response asynchronously to IO or worker thread In-Reply-To: <53F13E02.20807@redhat.com> References: <53F13E02.20807@redhat.com> Message-ID: > > You don't need the isInIoThread() check, otherwise this handler will do > nothing if an earlier handler dispatched (e.g. a security handler that > needed to do a blocking LDAP lookup). That is true, thanks for pointing it out. I assume you are not actually dealing with timers and this was just an > example Yes, timer was just an example. I am dealing with asynchronous client API that is used from the handler. Thanks a lot for the answer! On Mon, Aug 18, 2014 at 2:42 AM, Stuart Douglas wrote: > > >> This handler is implemented incorrectly because exchange will end right >> after handleRequest method is called. >> >> In order to fix this we can use dispatching (only implementation of >> handleRequest method is shown): >> >> public void handleRequest(final HttpServerExchange exchange) throws >> Exception { >> if (exchange.isInIoThread()) { >> exchange.dispatch(new Runnable() { >> public void run() { >> new Timer().schedule(new TimerTask() { >> public void run() { >> Connectors.executeRootHandler(new >> HttpHandler() { >> public void >> handleRequest(HttpServerExchange exchange) throws Exception { >> >> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain"); >> >> exchange.getResponseSender().send("Returned in 5 seconds"); >> } >> }, exchange); >> } >> }, 5000); >> } >> }); >> } >> } >> >> Please pay attention that the requirement here is not to use dumb >> blocking in the work thread (like Thread.sleep(5000)) but rely on >> asynchronous event handling instead. >> >> I would appreciate if someone can answer the following questions: >> >> > You don't need the isInIoThread() check, otherwise this handler will do > nothing if an earlier handler dispatched (e.g. a security handler that > needed to do a blocking LDAP lookup). > > * Are there any pitfalls with the working dispatch/executeRootHandler >> solution mentioned above? >> > > No, this is the correct way to do it. Undertow's exchange is not thread > safe (as making it thread safe seriously degrades performance by an order > of magnitude). Instead multi-threading is implemented by having a safe hand > off point (the dispatch() method), which basically allows a thread to hand > off to another thread when it is done, so only one thread 'owns' the > exchange at a time. > > You can just call the dispatch() method with no arguments to stop the > exchange ending, but if your async task finished before the call stack > returns then you will have two threads active in the exchange, which will > cause all kinds of potential problems (this is not going to happen with a > 5000ms delay, but with a 1ms delay it will). > > * Is there a simpler and more elegant way to achieve the same? >> > > I assume you are not actually dealing with timers and this was just an > example, but if you do want to schedule a task (like a timeout for > instance) you can schedule it using > > exchange.getIoThread().executeAfter(), which will run the timed task in > the IO thread. > > Stuart > > >> -- >> Vladimir Tsukur >> Software Architect, Design Engineer and Scrum Master >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> > -- Vladimir Tsukur Software Architect, Design Engineer and Scrum Master -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140818/7942e679/attachment.html From miere.teixeira at gmail.com Mon Aug 18 12:48:40 2014 From: miere.teixeira at gmail.com (Miere Teixeira) Date: Mon, 18 Aug 2014 13:48:40 -0300 Subject: [undertow-dev] Retrieving request entity In-Reply-To: References: <53F13C00.9020603@redhat.com> Message-ID: Hi Vladmir, I've faced the same problem before, but reading each byte manually didn't fit my needs. When the JDK 1.4 released Java NIO API, they have already created a common way to read data with less development effort, I'm talking about java.nio.channels.Channels class, which has many helper methods able to convert data from old IO API to NIO API. My prefered method is *Channels.newReader. *This method is able to convert a StreamSourceChannel to a lightweight Reader implementation. I like this method because many object marshallers are ready to handle Java IO Reader implementations. Here is a sample implementation with this approach. Note: could be some typos as I've wrote this code manually to send this mail. I really hope it helps you. Please Undertow devs let me know If I'm missing some important point on this. Regards. On Mon, Aug 18, 2014 at 5:16 AM, Vladimir Tsukur wrote: > Thanks for explaining the option with getRequestChannel! Got it working by > reading content into a pre-allocated ByteBuffer. > > if it returns 0 register a read listener and call resumeReads() > > > One thing I don't fully understand though is your note about registering a > read listener (+ calling resumeReads) and why this is needed. Is it a > mandatory step, and if it is, are you referring to application-specific > read listener or Undertow's > io.undertow.server.protocol.http.HttpReadListener? I guess this is pretty > basic question, so it would be great if you can just point me to the right > place at documentation, so that I can figure it out. > > Thinking about it we probably just need some way to buffer a >> complete/partial message and then invoke a callback with the data. > > > Yep, I guess this would be easier for the app developer to use. > > > On Mon, Aug 18, 2014 at 2:34 AM, Stuart Douglas > wrote: > >> You can use the getRequestChannel() method to get the request channel. >> Basically call read() on the channel till it returns either 0 or -1, if it >> returns -1 you are done, if it returns 0 register a read listener and call >> resumeReads(). >> >> I have always been meaning to add a nicer non-blocking API for this, but >> I have never been exactly sure what would be required here. Thinking about >> it we probably just need some way to buffer a complete/partial message and >> then invoke a callback with the data. >> >> Stuart >> >> Vladimir Tsukur wrote: >> >>> One of the ways to obtain request entity is to call >>> HttpServerExchange.startBlocking and then read content from the >>> HttpServerExchange.getInputStream. >>> >>> Is there a way to obtain request entity in a non-blocking way? >>> >>> -- >>> Vladimir Tsukur >>> Software Architect, Design Engineer and Scrum Master >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >> > > > -- > Vladimir Tsukur > Software Architect, Design Engineer and Scrum Master > > _______________________________________________ > 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/20140818/cba1bb9e/attachment-0001.html From jason.greene at redhat.com Mon Aug 18 16:30:42 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 18 Aug 2014 15:30:42 -0500 Subject: [undertow-dev] Retrieving request entity In-Reply-To: References: <53F13C00.9020603@redhat.com> Message-ID: <1653EF51-6391-4A21-BBE2-565DDB0C70DC@redhat.com> On Aug 18, 2014, at 11:48 AM, Miere Teixeira wrote: > Hi Vladmir, > > I've faced the same problem before, but reading each byte manually didn't fit my needs. > When the JDK 1.4 released Java NIO API, they have already created a common way to > read data with less development effort, I'm talking about java.nio.channels.Channels class, which > has many helper methods able to convert data from old IO API to NIO API. > > My prefered method is Channels.newReader. This method is able to convert a StreamSourceChannel > to a lightweight Reader implementation. I like this method because many object marshallers are > ready to handle Java IO Reader implementations. This method doesn?t support non-blocking channels, so can?t be used in a non-blocking handler. You can, however, just use getInputStream after putting the exchange in blocking mode. > > Here is a sample implementation with this approach. > Note: could be some typos as I've wrote this code manually to send this mail. While I am not aware of any non-blocking JSON parsers, it would be possible to build an event based JSON parser, which dispatches to non-blocking handlers to take action. > > I really hope it helps you. > Please Undertow devs let me know If I'm missing some important point on this. > > Regards. > > > On Mon, Aug 18, 2014 at 5:16 AM, Vladimir Tsukur wrote: > Thanks for explaining the option with getRequestChannel! Got it working by reading content into a pre-allocated ByteBuffer. > > if it returns 0 register a read listener and call resumeReads() > > One thing I don't fully understand though is your note about registering a read listener (+ calling resumeReads) and why this is needed. Is it a mandatory step, and if it is, are you referring to application-specific read listener or Undertow's io.undertow.server.protocol.http.HttpReadListener? I guess this is pretty basic question, so it would be great if you can just point me to the right place at documentation, so that I can figure it out. > > Thinking about it we probably just need some way to buffer a complete/partial message and then invoke a callback with the data. > > Yep, I guess this would be easier for the app developer to use. > > > On Mon, Aug 18, 2014 at 2:34 AM, Stuart Douglas wrote: > You can use the getRequestChannel() method to get the request channel. Basically call read() on the channel till it returns either 0 or -1, if it returns -1 you are done, if it returns 0 register a read listener and call resumeReads(). > > I have always been meaning to add a nicer non-blocking API for this, but I have never been exactly sure what would be required here. Thinking about it we probably just need some way to buffer a complete/partial message and then invoke a callback with the data. > > Stuart > > Vladimir Tsukur wrote: > One of the ways to obtain request entity is to call > HttpServerExchange.startBlocking and then read content from the > HttpServerExchange.getInputStream. > > Is there a way to obtain request entity in a non-blocking way? > > -- > Vladimir Tsukur > Software Architect, Design Engineer and Scrum Master > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > -- > Vladimir Tsukur > Software Architect, Design Engineer and Scrum Master > > _______________________________________________ > 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 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Mon Aug 18 16:55:32 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 18 Aug 2014 15:55:32 -0500 Subject: [undertow-dev] Retrieving request entity In-Reply-To: References: <53F13C00.9020603@redhat.com> Message-ID: On Aug 18, 2014, at 3:16 AM, Vladimir Tsukur wrote: > Thanks for explaining the option with getRequestChannel! Got it working by reading content into a pre-allocated ByteBuffer. > > > if it returns 0 register a read listener and call resumeReads() > > One thing I don't fully understand though is your note about registering a read listener (+ calling resumeReads) and why this is needed. Is it a mandatory step, and if it is, are you referring to application-specific read listener or Undertow's io.undertow.server.protocol.http.HttpReadListener? I guess this is pretty basic question, so it would be great if you can just point me to the right place at documentation, so that I can figure it out. The former, and it is required. We should add an example for this, but for now you can look at ReadTimeoutTestCase to get a rough idea. Basically the pattern is: 1. Read as much as you can (loop until 0 is returned) 2. Register a listener 3. Call resumeReads (which really means resume read notifications for your listener) Then your listener needs to: 1. Read as much data as you can 2. Process/buffer it 3. If all data is read, suspend reads, and remove the listener from the exchange, otherwise return It?s important that your listener be truly non-blocking, and have no possibility of calling blocking operations (e.g. reading files, interacting with JDBC etc). > > > Thinking about it we probably just need some way to buffer a complete/partial message and then invoke a callback with the data. > > Yep, I guess this would be easier for the app developer to use. > > > On Mon, Aug 18, 2014 at 2:34 AM, Stuart Douglas wrote: > You can use the getRequestChannel() method to get the request channel. Basically call read() on the channel till it returns either 0 or -1, if it returns -1 you are done, if it returns 0 register a read listener and call resumeReads(). > > I have always been meaning to add a nicer non-blocking API for this, but I have never been exactly sure what would be required here. Thinking about it we probably just need some way to buffer a complete/partial message and then invoke a callback with the data. > > Stuart > > Vladimir Tsukur wrote: > One of the ways to obtain request entity is to call > HttpServerExchange.startBlocking and then read content from the > HttpServerExchange.getInputStream. > > Is there a way to obtain request entity in a non-blocking way? > > -- > Vladimir Tsukur > Software Architect, Design Engineer and Scrum Master > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > -- > Vladimir Tsukur > Software Architect, Design Engineer and Scrum Master > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From miere.teixeira at gmail.com Tue Aug 19 08:22:29 2014 From: miere.teixeira at gmail.com (Miere Teixeira) Date: Tue, 19 Aug 2014 09:22:29 -0300 Subject: [undertow-dev] Retrieving request entity In-Reply-To: References: <53F13C00.9020603@redhat.com> Message-ID: > > This method doesn?t support non-blocking channels, so can?t be used in a > non-blocking handler. You can, however, just use getInputStream after > putting the exchange in blocking mode. > Jason, thanks for your clarification. I was focused on Vladmir's email subject and I've totally forget to consider non-blocking approach. It leads me to a question, what's the real impact on my previously approach? I did apply a similar approach on a customer application, should I expect serious performance issue, or maybe a possible starvation on request peaks? On Mon, Aug 18, 2014 at 5:55 PM, Jason Greene wrote: > > On Aug 18, 2014, at 3:16 AM, Vladimir Tsukur wrote: > > > Thanks for explaining the option with getRequestChannel! Got it working > by reading content into a pre-allocated ByteBuffer. > > > > > if it returns 0 register a read listener and call resumeReads() > > > > One thing I don't fully understand though is your note about registering > a read listener (+ calling resumeReads) and why this is needed. Is it a > mandatory step, and if it is, are you referring to application-specific > read listener or Undertow's > io.undertow.server.protocol.http.HttpReadListener? I guess this is pretty > basic question, so it would be great if you can just point me to the right > place at documentation, so that I can figure it out. > > The former, and it is required. We should add an example for this, but for > now you can look at ReadTimeoutTestCase to get a rough idea. Basically the > pattern is: > > 1. Read as much as you can (loop until 0 is returned) > 2. Register a listener > 3. Call resumeReads (which really means resume read notifications for your > listener) > > Then your listener needs to: > > 1. Read as much data as you can > 2. Process/buffer it > 3. If all data is read, suspend reads, and remove the listener from the > exchange, > otherwise return > > It?s important that your listener be truly non-blocking, and have no > possibility of calling blocking operations (e.g. reading files, interacting > with JDBC etc). > > > > > > Thinking about it we probably just need some way to buffer a > complete/partial message and then invoke a callback with the data. > > > > > > > Yep, I guess this would be easier for the app developer to use. > > > > > > On Mon, Aug 18, 2014 at 2:34 AM, Stuart Douglas > wrote: > > You can use the getRequestChannel() method to get the request channel. > Basically call read() on the channel till it returns either 0 or -1, if it > returns -1 you are done, if it returns 0 register a read listener and call > resumeReads(). > > > > I have always been meaning to add a nicer non-blocking API for this, but > I have never been exactly sure what would be required here. Thinking about > it we probably just need some way to buffer a complete/partial message and > then invoke a callback with the data. > > > > Stuart > > > > Vladimir Tsukur wrote: > > One of the ways to obtain request entity is to call > > HttpServerExchange.startBlocking and then read content from the > > HttpServerExchange.getInputStream. > > > > Is there a way to obtain request entity in a non-blocking way? > > > > -- > > Vladimir Tsukur > > Software Architect, Design Engineer and Scrum Master > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > > > > > -- > > Vladimir Tsukur > > Software Architect, Design Engineer and Scrum Master > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > 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/20140819/6d714e63/attachment.html From bill at dartalley.com Tue Aug 19 14:12:53 2014 From: bill at dartalley.com (Bill O'Neil) Date: Tue, 19 Aug 2014 14:12:53 -0400 Subject: [undertow-dev] Setting/handling request timeouts Message-ID: I have been having trouble figuring out how to set request timeouts and how to handle them. I have been messing around with the following. Undertow server = Undertow.builder() .addHttpListener(8080, "localhost") .setSocketOption(UndertowOptions.IDLE_TIMEOUT, 1000) .setSocketOption(Options.READ_TIMEOUT, 1000) .setSocketOption(Options.WRITE_TIMEOUT, 1000) When setting a HttpHandler that sleeps this will return an empty reply from server. curl -v localhost:8080 * Adding handle: conn: 0x7f81a900ee00 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x7f81a900ee00) send_pipe: 1, recv_pipe: 0 * About to connect() to localhost port 8080 (#0) * Trying ::1... * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 8080 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.30.0 > Host: localhost:8080 > Accept: */* > * Empty reply from server * Connection #0 to host localhost left intact curl: (52) Empty reply from server 1. What is the proper way to handle time outs? 2. Is it possible to set different timeouts per HttpHandler? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140819/99c72dd7/attachment.html From jason.greene at redhat.com Tue Aug 19 15:46:20 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 19 Aug 2014 14:46:20 -0500 Subject: [undertow-dev] Setting/handling request timeouts In-Reply-To: References: Message-ID: <083EA1E1-5B89-45AD-B5C4-D9B5510A8BA1@redhat.com> On Aug 19, 2014, at 1:12 PM, Bill O'Neil wrote: > I have been having trouble figuring out how to set request timeouts and how to handle them. > > I have been messing around with the following. > > Undertow server = Undertow.builder() > .addHttpListener(8080, "localhost") > .setSocketOption(UndertowOptions.IDLE_TIMEOUT, 1000) > .setSocketOption(Options.READ_TIMEOUT, 1000) > .setSocketOption(Options.WRITE_TIMEOUT, 1000) These options go on the server via the setUndertowOptions() method. Note that idle timeout acts as a default for read and write options if not explicitly set. You don?t have to set all three of these. > > When setting a HttpHandler that sleeps this will return an empty reply from server. > > curl -v localhost:8080 > * Adding handle: conn: 0x7f81a900ee00 > * Adding handle: send: 0 > * Adding handle: recv: 0 > * Curl_addHandleToPipeline: length: 1 > * - Conn 0 (0x7f81a900ee00) send_pipe: 1, recv_pipe: 0 > * About to connect() to localhost port 8080 (#0) > * Trying ::1... > * Trying 127.0.0.1... > * Connected to localhost (127.0.0.1) port 8080 (#0) > > GET / HTTP/1.1 > > User-Agent: curl/7.30.0 > > Host: localhost:8080 > > Accept: */* > > > * Empty reply from server > * Connection #0 to host localhost left intact > curl: (52) Empty reply from server > > 1. What is the proper way to handle time outs? > 2. Is it possible to set different timeouts per HttpHandler? > > Thanks, > Bill > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From sdouglas at redhat.com Wed Aug 20 01:43:13 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 20 Aug 2014 15:43:13 +1000 Subject: [undertow-dev] Retrieving request entity In-Reply-To: References: <53F13C00.9020603@redhat.com> Message-ID: <53F43571.8080909@redhat.com> Miere Teixeira wrote: > This method doesn?t support non-blocking channels, so can?t be used > in a non-blocking handler. You can, however, just use getInputStream > after putting the exchange in blocking mode. > > Jason, thanks for your clarification. I was focused on Vladmir's email > subject and I've totally forget to consider non-blocking approach. > > It leads me to a question, what's the real impact on my previously > approach? I did apply a similar approach on a customer application, > should I expect serious performance issue, or maybe a possible > starvation on request peaks? If you have dispatched to a worker thread it will work fine. If you are doing it in an IO thread you can have some serious performance issues, as other connections that the IO thread is servicing will not be handled until the blocking operation is complete. Stuart > > > > > On Mon, Aug 18, 2014 at 5:55 PM, Jason Greene > wrote: > > > On Aug 18, 2014, at 3:16 AM, Vladimir Tsukur > wrote: > > > Thanks for explaining the option with getRequestChannel! Got it > working by reading content into a pre-allocated ByteBuffer. > > > > > if it returns 0 register a read listener and call resumeReads() > > > > One thing I don't fully understand though is your note about > registering a read listener (+ calling resumeReads) and why this is > needed. Is it a mandatory step, and if it is, are you referring to > application-specific read listener or Undertow's > io.undertow.server.protocol.http.HttpReadListener? I guess this is > pretty basic question, so it would be great if you can just point me > to the right place at documentation, so that I can figure it out. > > The former, and it is required. We should add an example for this, > but for now you can look at ReadTimeoutTestCase to get a rough idea. > Basically the pattern is: > > 1. Read as much as you can (loop until 0 is returned) > 2. Register a listener > 3. Call resumeReads (which really means resume read notifications > for your listener) > > Then your listener needs to: > > 1. Read as much data as you can > 2. Process/buffer it > 3. If all data is read, suspend reads, and remove the listener from > the exchange, > otherwise return > > It?s important that your listener be truly non-blocking, and have no > possibility of calling blocking operations (e.g. reading files, > interacting with JDBC etc). > > > > > > Thinking about it we probably just need some way to buffer a > complete/partial message and then invoke a callback with the data. > > > > > > > Yep, I guess this would be easier for the app developer to use. > > > > > > On Mon, Aug 18, 2014 at 2:34 AM, Stuart Douglas > > wrote: > > You can use the getRequestChannel() method to get the request > channel. Basically call read() on the channel till it returns either > 0 or -1, if it returns -1 you are done, if it returns 0 register a > read listener and call resumeReads(). > > > > I have always been meaning to add a nicer non-blocking API for > this, but I have never been exactly sure what would be required > here. Thinking about it we probably just need some way to buffer a > complete/partial message and then invoke a callback with the data. > > > > Stuart > > > > Vladimir Tsukur wrote: > > One of the ways to obtain request entity is to call > > HttpServerExchange.startBlocking and then read content from the > > HttpServerExchange.getInputStream. > > > > Is there a way to obtain request entity in a non-blocking way? > > > > -- > > Vladimir Tsukur > > Software Architect, Design Engineer and Scrum Master > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > > > > > -- > > Vladimir Tsukur > > Software Architect, Design Engineer and Scrum Master > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > 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 From sdouglas at redhat.com Wed Aug 20 01:46:42 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 20 Aug 2014 15:46:42 +1000 Subject: [undertow-dev] Setting/handling request timeouts In-Reply-To: References: Message-ID: <53F43642.10407@redhat.com> This is an area that we are looking to improve. In particular I am looking into adding more options in this area, to give more control over when timeouts are applied. For example I am thinking something like: NO_REQUEST_TIMEOUT - How long the server should wait between requests PARSE_TIMEOUT - the maximum amount of time that should be spent parsing a HTTP request READ_TIMEOUT - When reading a request entity the maximum idle timeout I'm not sure if this covers all the use cases though. Stuart Bill O'Neil wrote: > I have been having trouble figuring out how to set request timeouts and > how to handle them. > > I have been messing around with the following. > > Undertow server = Undertow.builder() > .addHttpListener(8080, "localhost") > .setSocketOption(UndertowOptions.IDLE_TIMEOUT, 1000) > .setSocketOption(Options.READ_TIMEOUT, 1000) > .setSocketOption(Options.WRITE_TIMEOUT, 1000) > > When setting a HttpHandler that sleeps this will return an empty reply > from server. > > curl -v localhost:8080 > * Adding handle: conn: 0x7f81a900ee00 > * Adding handle: send: 0 > * Adding handle: recv: 0 > * Curl_addHandleToPipeline: length: 1 > * - Conn 0 (0x7f81a900ee00) send_pipe: 1, recv_pipe: 0 > * About to connect() to localhost port 8080 (#0) > * Trying ::1... > * Trying 127.0.0.1... > * Connected to localhost (127.0.0.1) port 8080 (#0) > > GET / HTTP/1.1 > > User-Agent: curl/7.30.0 > > Host: localhost:8080 > > Accept: */* > > > * Empty reply from server > * Connection #0 to host localhost left intact > curl: (52) Empty reply from server > > 1. What is the proper way to handle time outs? > 2. Is it possible to set different timeouts per HttpHandler? > > Thanks, > Bill > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From bill at dartalley.com Wed Aug 20 07:55:17 2014 From: bill at dartalley.com (Bill O'Neil) Date: Wed, 20 Aug 2014 07:55:17 -0400 Subject: [undertow-dev] Setting/handling request timeouts In-Reply-To: <53F43642.10407@redhat.com> References: <53F43642.10407@redhat.com> Message-ID: I am specifically looking for a way to timeout/kill a blocking task that is taking too long to return. Is this something that should be handled when dispatching to the underlying executor? Bill On Wed, Aug 20, 2014 at 1:46 AM, Stuart Douglas wrote: > This is an area that we are looking to improve. In particular I am looking > into adding more options in this area, to give more control over when > timeouts are applied. > > For example I am thinking something like: > > NO_REQUEST_TIMEOUT - How long the server should wait between requests > PARSE_TIMEOUT - the maximum amount of time that should be spent parsing a > HTTP request > READ_TIMEOUT - When reading a request entity the maximum idle timeout > > I'm not sure if this covers all the use cases though. > > Stuart > > > Bill O'Neil wrote: > >> I have been having trouble figuring out how to set request timeouts and >> how to handle them. >> >> I have been messing around with the following. >> >> Undertow server = Undertow.builder() >> .addHttpListener(8080, "localhost") >> .setSocketOption(UndertowOptions.IDLE_TIMEOUT, 1000) >> .setSocketOption(Options.READ_TIMEOUT, 1000) >> .setSocketOption(Options.WRITE_TIMEOUT, 1000) >> >> When setting a HttpHandler that sleeps this will return an empty reply >> from server. >> >> curl -v localhost:8080 >> * Adding handle: conn: 0x7f81a900ee00 >> * Adding handle: send: 0 >> * Adding handle: recv: 0 >> * Curl_addHandleToPipeline: length: 1 >> * - Conn 0 (0x7f81a900ee00) send_pipe: 1, recv_pipe: 0 >> * About to connect() to localhost port 8080 (#0) >> * Trying ::1... >> * Trying 127.0.0.1... >> * Connected to localhost (127.0.0.1) port 8080 (#0) >> > GET / HTTP/1.1 >> > User-Agent: curl/7.30.0 >> > Host: localhost:8080 >> > Accept: */* >> > >> * Empty reply from server >> * Connection #0 to host localhost left intact >> curl: (52) Empty reply from server >> >> 1. What is the proper way to handle time outs? >> 2. Is it possible to set different timeouts per HttpHandler? >> >> Thanks, >> Bill >> >> _______________________________________________ >> 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/20140820/25ca12cc/attachment.html From miere.teixeira at gmail.com Thu Aug 21 09:02:52 2014 From: miere.teixeira at gmail.com (Miere Teixeira) Date: Thu, 21 Aug 2014 10:02:52 -0300 Subject: [undertow-dev] Retrieving request entity In-Reply-To: <53F43571.8080909@redhat.com> References: <53F13C00.9020603@redhat.com> <53F43571.8080909@redhat.com> Message-ID: Thanks for the clarification Stuart, I confused the concepts of IO Threads and Worker Threads. On Wed, Aug 20, 2014 at 2:43 AM, Stuart Douglas wrote: > > > Miere Teixeira wrote: > >> This method doesn?t support non-blocking channels, so can?t be used >> in a non-blocking handler. You can, however, just use getInputStream >> after putting the exchange in blocking mode. >> >> Jason, thanks for your clarification. I was focused on Vladmir's email >> subject and I've totally forget to consider non-blocking approach. >> >> It leads me to a question, what's the real impact on my previously >> approach? I did apply a similar approach on a customer application, >> should I expect serious performance issue, or maybe a possible >> starvation on request peaks? >> > > If you have dispatched to a worker thread it will work fine. If you are > doing it in an IO thread you can have some serious performance issues, as > other connections that the IO thread is servicing will not be handled until > the blocking operation is complete. > > Stuart > > > >> >> >> >> On Mon, Aug 18, 2014 at 5:55 PM, Jason Greene > > wrote: >> >> >> On Aug 18, 2014, at 3:16 AM, Vladimir Tsukur > > wrote: >> >> > Thanks for explaining the option with getRequestChannel! Got it >> working by reading content into a pre-allocated ByteBuffer. >> > >> > > if it returns 0 register a read listener and call resumeReads() >> > >> > One thing I don't fully understand though is your note about >> registering a read listener (+ calling resumeReads) and why this is >> needed. Is it a mandatory step, and if it is, are you referring to >> application-specific read listener or Undertow's >> io.undertow.server.protocol.http.HttpReadListener? I guess this is >> pretty basic question, so it would be great if you can just point me >> to the right place at documentation, so that I can figure it out. >> >> The former, and it is required. We should add an example for this, >> but for now you can look at ReadTimeoutTestCase to get a rough idea. >> Basically the pattern is: >> >> 1. Read as much as you can (loop until 0 is returned) >> 2. Register a listener >> 3. Call resumeReads (which really means resume read notifications >> for your listener) >> >> Then your listener needs to: >> >> 1. Read as much data as you can >> 2. Process/buffer it >> 3. If all data is read, suspend reads, and remove the listener from >> the exchange, >> otherwise return >> >> It?s important that your listener be truly non-blocking, and have no >> possibility of calling blocking operations (e.g. reading files, >> interacting with JDBC etc). >> >> > >> > > Thinking about it we probably just need some way to buffer a >> complete/partial message and then invoke a callback with the data. >> >> >> >> > >> > Yep, I guess this would be easier for the app developer to use. >> > >> > >> > On Mon, Aug 18, 2014 at 2:34 AM, Stuart Douglas >> > wrote: >> > You can use the getRequestChannel() method to get the request >> channel. Basically call read() on the channel till it returns either >> 0 or -1, if it returns -1 you are done, if it returns 0 register a >> read listener and call resumeReads(). >> > >> > I have always been meaning to add a nicer non-blocking API for >> this, but I have never been exactly sure what would be required >> here. Thinking about it we probably just need some way to buffer a >> complete/partial message and then invoke a callback with the data. >> > >> > Stuart >> > >> > Vladimir Tsukur wrote: >> > One of the ways to obtain request entity is to call >> > HttpServerExchange.startBlocking and then read content from the >> > HttpServerExchange.getInputStream. >> > >> > Is there a way to obtain request entity in a non-blocking way? >> > >> > -- >> > Vladimir Tsukur >> > Software Architect, Design Engineer and Scrum Master >> > >> > _______________________________________________ >> > undertow-dev mailing list >> > undertow-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev >> > >> > >> > >> > -- >> > Vladimir Tsukur >> > Software Architect, Design Engineer and Scrum Master >> > _______________________________________________ >> > undertow-dev mailing list >> > undertow-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> 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/20140821/26680f64/attachment-0001.html From ryan.hermanson at gmail.com Fri Aug 22 10:49:39 2014 From: ryan.hermanson at gmail.com (Ryan Hermanson) Date: Fri, 22 Aug 2014 08:49:39 -0600 Subject: [undertow-dev] WebSocketContainer configuration Message-ID: I have had good luck with use of Undertow recently but now I?ve come up against a problem. When the deployment is strictly a server (I.e. handling inbound requests over web sockets), all is happy. Recently, there is a need to support outbound ?client? sessions. And, all is not well. I?ll be as detailed as possible to keep the speculation of specifics to a minimum. Thanks for your patience. My problem is two fold. The client session needs to have associated sslContext (presumably thru EndpointConfig instance), as well as a way to control/configure the underlying HTTP timeouts (presumably thru socketOptions). When I do something as simple as ContainerProvider.getWebSocketContainer().connectToServer(annotatedClientEndpoint.class, path) , the client connection is established with far-end as hoped, but the sslContext defined for our undertow instance is not employed. To add to the headache, if the remote server is unresponsive, the connection attempt blocks for roughly 5 minutes. Neither of these scenarios is ideal, obviously. ServerWebSocketContainer serverContainer = (ServerWebSocketContainer) deployment.getDeployment() .getServletContext().getAttribute(ServerContainer.class.getName()); serverContainer.connectToServer(annotatedClientEndpoint.class, path); The above attempt to leverage the deployed ServerWebSocketContainer (simpleAnnotatedServerEndpoint), successfully establishes the remote connection, but any attempt at handling a message via @OnMessage (public void onMessage(String msg)), yields NPE (BufferPool is null) with stack trace of: 2014-08-21 16:03:30,978;20667;DEBUG;core.request;(XNIO-1 I/O-1);Invoking receive listener 2014-08-21 16:03:30,978;20667;ERROR;xnio.listener;(XNIO-1 I/O-1);XNIO001007: A channel event listener threw an exception java.lang.NullPointerException at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:234) at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:20) at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:632) at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:618) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) Based on description above and the relevant code snippets below, how should I proceed in order to successfully establish outbound ?client? connection with functional xnioWorker instance, including SSL_CONTEXT and working channels? Thank you for any suggestions. Undertow version: 1.0.15 Final Xnio version: 3.2.2 Final My undertow instance: undertow = Undertow.builder() .addHttpListener(wsDefaultPort, WS_HOST) .addHttpsListener(wssDefaultPort, WS_HOST, MySSLSocketFactory.getSslContext()) .setHandler(rootPath) .build(); undertow.start(); ?. final WebSocketDeploymentInfo deployment = new WebSocketDeploymentInfo(); try { final Xnio xnio = Xnio.getInstance("nio", Undertow.class.getClassLoader()); final XnioWorker xnioWorker = xnio.createWorker(OptionMap.builder().getMap()); deployment.setWorker(xnioWorker); deployment.addEndpoint(simpleAnnotatedServerEndpoint.class); ?. final DeploymentManager deploymentManager = defaultContainer().addDeployment(deployment() .setClassLoader(classLoader) .setContextPath(prefixPath) .setDeploymentName(prefixPath) .addServletContextAttribute(ATTRIBUTE_NAME, deployment)); deploymentManager.deploy(); .? rootPath.addPrefixPath(prefixPath, deploymentManager.start()); deployments.put(prefixPath, deploymentManager); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140822/3b4b31ac/attachment.html From ryan.hermanson at gmail.com Fri Aug 22 14:12:27 2014 From: ryan.hermanson at gmail.com (Ryan Hermanson) Date: Fri, 22 Aug 2014 12:12:27 -0600 Subject: [undertow-dev] How to interrupt WebSocketClient.connect(...) Message-ID: Is there way to cancel an outstanding WebSocketContainer.connectToServer(...) request ? A connection attempt to an offline server blocks a very long time (minutes), and debugging would indicate IoFuture seems unwilling to respect an interrupt/cancel from the main thread. IoFuture session = WebSocketClient.connect(xnioWorker, ssl, bufferPool, OptionMap.EMPTY, path, WebSocketVersion.V13, clientNegotiation); //TODO: fix this WebSocketChannel channel = session.get(); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140822/34c8754a/attachment.html From sdouglas at redhat.com Mon Aug 25 02:25:19 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 25 Aug 2014 16:25:19 +1000 Subject: [undertow-dev] How to interrupt WebSocketClient.connect(...) In-Reply-To: References: Message-ID: <53FAD6CF.6050401@redhat.com> This should be fixed in the 1.1 branch of Undertow. Can you try using Undertow upstream? Stuart Ryan Hermanson wrote: > Is there way to cancel an outstanding > WebSocketContainer.connectToServer(...) request ? A connection attempt > to an offline server blocks a very long time (minutes), and debugging > would indicate IoFuture seems unwilling to respect an > interrupt/cancel from the main thread. > > IoFuture session = WebSocketClient.connect(xnioWorker, > ssl, bufferPool, OptionMap.EMPTY, path, WebSocketVersion.V13, > clientNegotiation); //TODO: fix this > WebSocketChannel channel = session.get(); > > _______________________________________________ > 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 25 03:43:33 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 25 Aug 2014 17:43:33 +1000 Subject: [undertow-dev] WebSocketContainer configuration In-Reply-To: References: Message-ID: <53FAE925.4040600@redhat.com> Ryan Hermanson wrote: > I have had good luck with use of Undertow recently but now I?ve come up > against a problem. When the deployment is strictly a server (I.e. > handling inbound requests over web sockets), all is happy. Recently, > there is a need to support outbound ?client? sessions. And, all is not > well. I?ll be as detailed as possible to keep the speculation of > specifics to a minimum. Thanks for your patience. > > My problem is two fold. The client session needs to have associated > sslContext (presumably thru EndpointConfig instance), as well as a way > to control/configure the underlying HTTP timeouts (presumably thru > socketOptions). When I do something as simple as > > ContainerProvider.getWebSocketContainer().connectToServer(annotatedClientEndpoint.class, > path) > > , the client connection is established with far-end as hoped, but the > sslContext defined for our undertow instance is not employed. To add to > the headache, if the remote server is unresponsive, the connection > attempt blocks for roughly 5 minutes. Neither of these scenarios is > ideal, obviously. The ssl context can be set in three ways. 1) Use the version of connect that takes a ClientEndpointConfig and set the io.undertow.websocket.SSL_CONTEXT property to the SSL context you want to use (unfortunatly this won't work with annotated endpoints). 2) Call io.undertow.websockets.jsr.DefaultWebSocketClientSslProvider#setSslContext() which sets the thread local SSL context. 3) Implement io.undertow.websockets.jsr.WebsocketClientSslProvider and add a META-INF/services entry pointing to your implementation. (The web socket API is sadly lacking when it comes to configuring SSL). > > ServerWebSocketContainer serverContainer = (ServerWebSocketContainer) > deployment.getDeployment() > > .getServletContext().getAttribute(ServerContainer.class.getName()); > serverContainer.connectToServer(annotatedClientEndpoint.class, path); > > The above attempt to leverage the deployed ServerWebSocketContainer > (simpleAnnotatedServerEndpoint), successfully establishes the remote > connection, but any attempt at handling a message via @OnMessage (public > void onMessage(String msg)), yields NPE (BufferPool is null) with stack > trace of: Make sure you set the buffer pool on the WebSocketDeploymentInfo (io.undertow.websockets.jsr.WebSocketDeploymentInfo#setBuffers). Stuart > > 2014-08-21 16:03:30,978;20667;DEBUG;core.request;(XNIO-1 I/O-1);Invoking > receive listener > 2014-08-21 16:03:30,978;20667;ERROR;xnio.listener;(XNIO-1 > I/O-1);XNIO001007: A channel event listener threw an exception > java.lang.NullPointerException > at > io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:234) > at > io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:20) > at > io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:632) > at > io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:618) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > > Based on description above and the relevant code snippets below, how > should I proceed in order to successfully establish outbound ?client? > connection with functional xnioWorker instance, including SSL_CONTEXT > and working channels? Thank you for any suggestions. > > Undertow version: 1.0.15 Final > Xnio version: 3.2.2 Final > > My undertow instance: > > undertow = Undertow.builder() > .addHttpListener(wsDefaultPort, WS_HOST) > .addHttpsListener(wssDefaultPort, WS_HOST, > MySSLSocketFactory.getSslContext()) > .setHandler(rootPath) > .build(); > undertow.start(); > > ?. > final WebSocketDeploymentInfo deployment = new > WebSocketDeploymentInfo(); > > try > { > final Xnio xnio = Xnio.getInstance("nio", > Undertow.class.getClassLoader()); > final XnioWorker xnioWorker = > xnio.createWorker(OptionMap.builder().getMap()); > > deployment.setWorker(xnioWorker); > deployment.addEndpoint(simpleAnnotatedServerEndpoint.class); > ?. > final DeploymentManager deploymentManager = > defaultContainer().addDeployment(deployment() > .setClassLoader(classLoader) > .setContextPath(prefixPath) > .setDeploymentName(prefixPath) > .addServletContextAttribute(ATTRIBUTE_NAME, deployment)); > deploymentManager.deploy(); > .? > rootPath.addPrefixPath(prefixPath, deploymentManager.start()); > deployments.put(prefixPath, deploymentManager); > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From ryan.hermanson at gmail.com Mon Aug 25 14:48:06 2014 From: ryan.hermanson at gmail.com (Ryan Hermanson) Date: Mon, 25 Aug 2014 12:48:06 -0600 Subject: [undertow-dev] How to interrupt WebSocketClient.connect(...) In-Reply-To: <53FAD6CF.6050401@redhat.com> References: <53FAD6CF.6050401@redhat.com> Message-ID: You are absolutely correct. Running with 1.1.0.Beta7-SNAPSHOT times out the connect attempt at 10s, as advertised. Any idea when this is planned to be tagged for release? Thanks. On Mon, Aug 25, 2014 at 12:25 AM, Stuart Douglas wrote: > This should be fixed in the 1.1 branch of Undertow. Can you try using > Undertow upstream? > > Stuart > > Ryan Hermanson wrote: > >> Is there way to cancel an outstanding >> WebSocketContainer.connectToServer(...) request ? A connection attempt >> to an offline server blocks a very long time (minutes), and debugging >> would indicate IoFuture seems unwilling to respect an >> interrupt/cancel from the main thread. >> >> IoFuture session = WebSocketClient.connect(xnioWorker, >> ssl, bufferPool, OptionMap.EMPTY, path, WebSocketVersion.V13, >> clientNegotiation); //TODO: fix this >> WebSocketChannel channel = session.get(); >> >> _______________________________________________ >> 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/20140825/62e45c99/attachment.html From sdouglas at redhat.com Mon Aug 25 17:55:11 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 26 Aug 2014 07:55:11 +1000 Subject: [undertow-dev] How to interrupt WebSocketClient.connect(...) In-Reply-To: References: <53FAD6CF.6050401@redhat.com> Message-ID: <53FBB0BF.1070500@redhat.com> Probably some time this week. Stuart Ryan Hermanson wrote: > You are absolutely correct. Running with 1.1.0.Beta7-SNAPSHOT times out > the connect attempt at 10s, as advertised. > > Any idea when this is planned to be tagged for release? > > Thanks. > > > On Mon, Aug 25, 2014 at 12:25 AM, Stuart Douglas > wrote: > > This should be fixed in the 1.1 branch of Undertow. Can you try > using Undertow upstream? > > Stuart > > Ryan Hermanson wrote: > > Is there way to cancel an outstanding > WebSocketContainer.__connectToServer(...) request ? A connection > attempt > to an offline server blocks a very long time (minutes), and > debugging > would indicate IoFuture seems unwilling to > respect an > interrupt/cancel from the main thread. > > IoFuture session = > WebSocketClient.connect(__xnioWorker, > ssl, bufferPool, OptionMap.EMPTY, path, WebSocketVersion.V13, > clientNegotiation); //TODO: fix this > WebSocketChannel channel = session.get(); > > _________________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/__mailman/listinfo/undertow-dev > > > From ralf_boogie_blues at bluewin.ch Fri Aug 29 10:33:43 2014 From: ralf_boogie_blues at bluewin.ch (ralf_boogie_blues at bluewin.ch) Date: Fri, 29 Aug 2014 14:33:43 +0000 (GMT+00:00) Subject: [undertow-dev] Download Bandwidth Throttling Handler Message-ID: <16041223.29741.1409322823601.JavaMail.webmail@bluewin.ch> Hi I am looking for a handler that throttles downloads to a configurable download rate. As far as I can see, there is no such handler yet available. I can find good solution based on servlets but I would like to solve this requirement with a undertow handler. How difficult is it implement such a handler? May you can give just a little hint and I could proceed. That would be great. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140829/400b36bb/attachment.html From sdouglas at redhat.com Sun Aug 31 19:41:02 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 01 Sep 2014 09:41:02 +1000 Subject: [undertow-dev] Download Bandwidth Throttling Handler In-Reply-To: <16041223.29741.1409322823601.JavaMail.webmail@bluewin.ch> References: <16041223.29741.1409322823601.JavaMail.webmail@bluewin.ch> Message-ID: <5403B28E.3010309@redhat.com> ralf_boogie_blues at bluewin.ch wrote: > Hi > > I am looking for a handler that throttles downloads to a configurable > download rate. As far as I can see, there is no such handler yet available. > I can find good solution based on servlets but I would like to solve > this requirement with a undertow handler. > > How difficult is it implement such a handler? May you can give just a > little hint and I could proceed. That would be great. Unfortunately it is fairly technical, as you need to provide a StreamSinkCoduit implementation that achieves this. These conduits support both blocking and non-blocking IO. The blocking side of things is fairly easy (if the data limit is exceeded just block for a while), however the non-blocking side of things is a bit more technical (basically when the limit is exceeded you return 0 and register a timer to notify the conduit when it can write again). Feel free to have ago at implementing this, or you can just file a JIRA and I will try and get to it some time this week. Stuart > > Ralf > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev