From Wind.Ko at jos.com.hk Mon Nov 2 02:08:29 2015 From: Wind.Ko at jos.com.hk (Wind Ko) Date: Mon, 2 Nov 2015 07:08:29 +0000 Subject: [undertow-dev] UnderTow-Core component 1.1.19 release Message-ID: <507DE66A966E8D4BA754AD4670B001CB1BEF29BF@EXS01HK.corp.jos.com> Hi UnderTow/JBoss devlopement Team, Our Customer are using JBoss 8.2.0, and found the URL querystring is missing after redirect to 404. We found that an issue seriously affecting our application, we require the below fix urgently. Error dispatch does not preserve request parameters https://issues.jboss.org/browse/UNDERTOW-505 May we know when would you release the component undertow-core 1.1.19? or JBoss 8.2.3 with this fix inside? Or Else we would use under-core 1.2.10. integrate to JBoss 8? Please advise. Thanks & Regards, Wai Consultant Enterprise Application, Infrastructure and Services Division Jardine OneSolution (HK) Limited Mobile: (852) 63956870 Email: Wind.Ko at jos.com.hk ________________________________________________________________________ DISCLAIMER:- This email is confidential and intended only for the use of the individual or entity named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message. Thank you. ________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151102/2470bac1/attachment-0001.html From sdouglas at redhat.com Mon Nov 2 03:25:19 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 2 Nov 2015 03:25:19 -0500 (EST) Subject: [undertow-dev] UnderTow-Core component 1.1.19 release In-Reply-To: <507DE66A966E8D4BA754AD4670B001CB1BEF29BF@EXS01HK.corp.jos.com> References: <507DE66A966E8D4BA754AD4670B001CB1BEF29BF@EXS01HK.corp.jos.com> Message-ID: <355686507.697821.1446452719868.JavaMail.zimbra@redhat.com> I just cut 1.1.9.Final. Generally with these older branches I only release when there is a fix someone needs. Stuart ----- Original Message ----- > From: "Wind Ko" > To: undertow-dev at lists.jboss.org > Cc: cwleung4 at censtatd.gov.hk, "Herman Man" , "Andy Hui" , > lkluk at censtatd.gov.hk > Sent: Monday, 2 November, 2015 6:08:29 PM > Subject: [undertow-dev] UnderTow-Core component 1.1.19 release > > > > Hi UnderTow/JBoss devlopement Team, > > > > Our Customer are using JBoss 8.2.0, and found the URL querystring is missing > after redirect to 404. > > We found that an issue seriously affecting our application, we require the > below fix urgently. > > > > Error dispatch does not preserve request parameters > > https://issues.jboss.org/browse/UNDERTOW-505 > > > > > > May we know when would you release the component undertow-core 1.1.19? or > JBoss 8.2.3 with this fix inside? > > > > Or Else we would use under-core 1.2.10. integrate to JBoss 8? Please advise. > > > > Thanks & Regards, > > > > Wai > > Consultant > > Enterprise Application, Infrastructure and Services Division > > Jardine OneSolution (HK) Limited > > Mobile: (852) 63956870 > > Email: Wind.Ko at jos.com.hk > > > > ________________________________________________________________________ > DISCLAIMER:- > This email is confidential and intended only for the use of the individual or > entity named above and may contain information that is privileged. If you > are not the intended recipient, you are notified that any dissemination, > distribution or copying of this email is strictly prohibited. If you have > received this email in error, please notify us immediately by return email > or telephone and destroy the original message. Thank you. > ________________________________________________________________________ > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From Wind.Ko at jos.com.hk Mon Nov 2 03:39:59 2015 From: Wind.Ko at jos.com.hk (Wind Ko) Date: Mon, 2 Nov 2015 08:39:59 +0000 Subject: [undertow-dev] UnderTow-Core component 1.1.19 release In-Reply-To: <355686507.697821.1446452719868.JavaMail.zimbra@redhat.com> References: <507DE66A966E8D4BA754AD4670B001CB1BEF29BF@EXS01HK.corp.jos.com> <355686507.697821.1446452719868.JavaMail.zimbra@redhat.com> Message-ID: <507DE66A966E8D4BA754AD4670B001CB1BEF29EA@EXS01HK.corp.jos.com> Dear Stuart, Thank you for your reply. Could you provide us the fix for 1.1.9? We only need the below fix included. Error dispatch does not preserve request parameters https://issues.jboss.org/browse/UNDERTOW-505 Thanks & Regards, Wai Consultant Enterprise Application,?Infrastructure and Services Division Jardine OneSolution (HK) Limited Mobile: (852) 63956870 Email: Wind.Ko at jos.com.hk -----Original Message----- From: Stuart Douglas [mailto:sdouglas at redhat.com] Sent: Monday, November 02, 2015 4:25 PM To: Wind Ko Cc: undertow-dev at lists.jboss.org; cwleung4 at censtatd.gov.hk; Herman Man; Andy Hui; lkluk at censtatd.gov.hk Subject: Re: [undertow-dev] UnderTow-Core component 1.1.19 release I just cut 1.1.9.Final. Generally with these older branches I only release when there is a fix someone needs. Stuart ----- Original Message ----- > From: "Wind Ko" > To: undertow-dev at lists.jboss.org > Cc: cwleung4 at censtatd.gov.hk, "Herman Man" , "Andy Hui" , > lkluk at censtatd.gov.hk > Sent: Monday, 2 November, 2015 6:08:29 PM > Subject: [undertow-dev] UnderTow-Core component 1.1.19 release > > > > Hi UnderTow/JBoss devlopement Team, > > > > Our Customer are using JBoss 8.2.0, and found the URL querystring is missing > after redirect to 404. > > We found that an issue seriously affecting our application, we require the > below fix urgently. > > > > Error dispatch does not preserve request parameters > > https://issues.jboss.org/browse/UNDERTOW-505 > > > > > > May we know when would you release the component undertow-core 1.1.19? or > JBoss 8.2.3 with this fix inside? > > > > Or Else we would use under-core 1.2.10. integrate to JBoss 8? Please advise. > > > > Thanks & Regards, > > > > Wai > > Consultant > > Enterprise Application, Infrastructure and Services Division > > Jardine OneSolution (HK) Limited > > Mobile: (852) 63956870 > > Email: Wind.Ko at jos.com.hk > > > > ________________________________________________________________________ > DISCLAIMER:- > This email is confidential and intended only for the use of the individual or > entity named above and may contain information that is privileged. If you > are not the intended recipient, you are notified that any dissemination, > distribution or copying of this email is strictly prohibited. If you have > received this email in error, please notify us immediately by return email > or telephone and destroy the original message. Thank you. > ________________________________________________________________________ > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev ________________________________________________________________________ DISCLAIMER:- This email is confidential and intended only for the use of the individual or entity named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message. Thank you. ________________________________________________________________________ From sdouglas at redhat.com Mon Nov 2 03:50:52 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 2 Nov 2015 03:50:52 -0500 (EST) Subject: [undertow-dev] UnderTow-Core component 1.1.19 release In-Reply-To: <355686507.697821.1446452719868.JavaMail.zimbra@redhat.com> References: <507DE66A966E8D4BA754AD4670B001CB1BEF29BF@EXS01HK.corp.jos.com> <355686507.697821.1446452719868.JavaMail.zimbra@redhat.com> Message-ID: <2126782048.723917.1446454252686.JavaMail.zimbra@redhat.com> I already did. Stuart ----- Original Message ----- > From: "Stuart Douglas" > To: "Wind Ko" > Cc: cwleung4 at censtatd.gov.hk, "Herman Man" , "Andy Hui" , > undertow-dev at lists.jboss.org, lkluk at censtatd.gov.hk > Sent: Monday, 2 November, 2015 7:25:19 PM > Subject: Re: [undertow-dev] UnderTow-Core component 1.1.19 release > > I just cut 1.1.9.Final. Generally with these older branches I only > release when there is a fix someone needs. > > > Stuart > > ----- Original Message ----- > > From: "Wind Ko" > > To: undertow-dev at lists.jboss.org > > Cc: cwleung4 at censtatd.gov.hk, "Herman Man" , "Andy > > Hui" , > > lkluk at censtatd.gov.hk > > Sent: Monday, 2 November, 2015 6:08:29 PM > > Subject: [undertow-dev] UnderTow-Core component 1.1.19 release > > > > > > > > Hi UnderTow/JBoss devlopement Team, > > > > > > > > Our Customer are using JBoss 8.2.0, and found the URL querystring is > > missing > > after redirect to 404. > > > > We found that an issue seriously affecting our application, we require the > > below fix urgently. > > > > > > > > Error dispatch does not preserve request parameters > > > > https://issues.jboss.org/browse/UNDERTOW-505 > > > > > > > > > > > > May we know when would you release the component undertow-core 1.1.19? or > > JBoss 8.2.3 with this fix inside? > > > > > > > > Or Else we would use under-core 1.2.10. integrate to JBoss 8? Please > > advise. > > > > > > > > Thanks & Regards, > > > > > > > > Wai > > > > Consultant > > > > Enterprise Application, Infrastructure and Services Division > > > > Jardine OneSolution (HK) Limited > > > > Mobile: (852) 63956870 > > > > Email: Wind.Ko at jos.com.hk > > > > > > > > ________________________________________________________________________ > > DISCLAIMER:- > > This email is confidential and intended only for the use of the individual > > or > > entity named above and may contain information that is privileged. If you > > are not the intended recipient, you are notified that any dissemination, > > distribution or copying of this email is strictly prohibited. If you have > > received this email in error, please notify us immediately by return email > > or telephone and destroy the original message. Thank you. > > ________________________________________________________________________ > > > > _______________________________________________ > > 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 cbsmith at gmail.com Mon Nov 2 23:23:22 2015 From: cbsmith at gmail.com (Christopher Smith) Date: Mon, 2 Nov 2015 20:23:22 -0800 Subject: [undertow-dev] Proxy Protocol/Layer-4 load balancing/AWS ELB Message-ID: I was curious if anyone had set up undertow to work with a layer-4 proxy server with undertow. I'm looking at using undertow behind an AWS ELB, but it's layer-7 load balancing logic kills any shot I have of taking advantage of undertow's awesome HTTP/2 & SPDY support. ELB supports layer-4 load balancing, which would just multiplex inbound TCP connections (with an added bonus of offloading TLS), but I'm concerned about losing client IP addresses. ELB actually has a way to address this with HAProxy's PROXY protocol: http://www.haproxy.org/download/1.6/doc/proxy-protocol.txt However, I haven't found a place for setting up the PROXY protocol support in undertow. Has anyone done this? Is there a way I should be going about it? It feels like I'd just need to wrapper the existing Listener implementation with some kind of delegate that first parsed the PROXY header, extracted the client address/port/protocol/etc., and then passed on the rest of the logic to the HTTP2 handler. Is that about right? -- Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151102/65123786/attachment.html From jason.greene at redhat.com Tue Nov 3 06:59:40 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Tue, 3 Nov 2015 06:59:40 -0500 (EST) Subject: [undertow-dev] Proxy Protocol/Layer-4 load balancing/AWS ELB In-Reply-To: References: Message-ID: Sent from my iPhone > On Nov 2, 2015, at 10:24 PM, Christopher Smith wrote: > > ELB supports layer-4 load balancing, which would just multiplex inbound TCP connections (with an added bonus of offloading TLS), but I'm concerned about losing client IP addresses. ELB actually has a way to address this with HAProxy's PROXY protocol: http://www.haproxy.org/download/1.6/doc/proxy-protocol.txt > > However, I haven't found a place for setting up the PROXY protocol support in undertow. Has anyone done this? Is there a way I should be going about it? We should probably add support for haproxy's protocol if it has wide usage like this. It looks fairly straightforward. -Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151103/021c3341/attachment.html From cbsmith at gmail.com Tue Nov 3 11:36:12 2015 From: cbsmith at gmail.com (Christopher Smith) Date: Tue, 3 Nov 2015 08:36:12 -0800 Subject: [undertow-dev] Proxy Protocol/Layer-4 load balancing/AWS ELB In-Reply-To: References: Message-ID: I think ELB constitutes pretty wide usage. ;-) People do tend to use the layer-7 load balancing, but given undertow's extensive support for http/2 & spdy, the advantages of using layer-4 load balancing are significant. I agree it is a very straightforward implementation. You mostly just parse one line before handing off the logic to some other handler. I'm not familiar with undertow's code base, but I'd be happy to work with someone on it. --Chris On Tue, Nov 3, 2015 at 3:59 AM, Jason T. Greene wrote: > > > Sent from my iPhone > > On Nov 2, 2015, at 10:24 PM, Christopher Smith wrote: > > ELB supports layer-4 load balancing, which would just multiplex inbound > TCP connections (with an added bonus of offloading TLS), but I'm concerned > about losing client IP addresses. ELB actually has a way to address this > with HAProxy's PROXY protocol: > http://www.haproxy.org/download/1.6/doc/proxy-protocol.txt > > However, I haven't found a place for setting up the PROXY protocol support > in undertow. Has anyone done this? Is there a way I should be going about > it? > > > We should probably add support for haproxy's protocol if it has wide usage > like this. It looks fairly straightforward. > > -Jason > -- Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151103/1464538e/attachment.html From sdouglas at redhat.com Tue Nov 3 18:36:15 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 3 Nov 2015 18:36:15 -0500 (EST) Subject: [undertow-dev] Proxy Protocol/Layer-4 load balancing/AWS ELB In-Reply-To: References: Message-ID: <1949493048.2600436.1446593775520.JavaMail.zimbra@redhat.com> I have created a JIRA to track this: https://issues.jboss.org/browse/UNDERTOW-573 Stuart ----- Original Message ----- > From: "Christopher Smith" > To: "Jason T. Greene" > Cc: undertow-dev at lists.jboss.org > Sent: Wednesday, 4 November, 2015 3:36:12 AM > Subject: Re: [undertow-dev] Proxy Protocol/Layer-4 load balancing/AWS ELB > > I think ELB constitutes pretty wide usage. ;-) > > People do tend to use the layer-7 load balancing, but given undertow's > extensive support for http/2 & spdy, the advantages of using layer-4 load > balancing are significant. I agree it is a very straightforward > implementation. You mostly just parse one line before handing off the logic > to some other handler. I'm not familiar with undertow's code base, but I'd > be happy to work with someone on it. > > --Chris > > On Tue, Nov 3, 2015 at 3:59 AM, Jason T. Greene < jason.greene at redhat.com > > wrote: > > > > > > Sent from my iPhone > > On Nov 2, 2015, at 10:24 PM, Christopher Smith < cbsmith at gmail.com > wrote: > > > > > ELB supports layer-4 load balancing, which would just multiplex inbound TCP > connections (with an added bonus of offloading TLS), but I'm concerned about > losing client IP addresses. ELB actually has a way to address this with > HAProxy's PROXY protocol: > http://www.haproxy.org/download/1.6/doc/proxy-protocol.txt > > However, I haven't found a place for setting up the PROXY protocol support in > undertow. Has anyone done this? Is there a way I should be going about it? > > We should probably add support for haproxy's protocol if it has wide usage > like this. It looks fairly straightforward. > > -Jason > > > > -- > Chris > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sven at kubiak.me Thu Nov 5 14:53:02 2015 From: sven at kubiak.me (Sven Kubiak) Date: Thu, 5 Nov 2015 19:53:02 +0000 Subject: [undertow-dev] ServerSentEventConnection async? Message-ID: Hey, I am writing a service where I keep a list of ServerSentEventConnections. Is the .send(String data) method async? Or in other words: Can I loop through the list of connections and call the send method without it blocking the loop? Cheers, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151105/f3546a15/attachment.html From sdouglas at redhat.com Thu Nov 5 18:18:28 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 5 Nov 2015 18:18:28 -0500 (EST) Subject: [undertow-dev] ServerSentEventConnection async? In-Reply-To: References: Message-ID: <295170890.3972853.1446765508948.JavaMail.zimbra@redhat.com> It is async. Stuart ----- Original Message ----- > From: "Sven Kubiak" > To: undertow-dev at lists.jboss.org > Sent: Friday, 6 November, 2015 6:53:02 AM > Subject: [undertow-dev] ServerSentEventConnection async? > > > > Hey, > > > > I am writing a service where I keep a list of ServerSentEventConnections. > > > > Is the .send(String data) method async? Or in other words: Can I loop through > the list of connections and call the send method without it blocking the > loop? > > > > Cheers, > > Sven > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From jorge.ayala2012 at gmail.com Mon Nov 9 12:15:55 2015 From: jorge.ayala2012 at gmail.com (jorge lima) Date: Mon, 9 Nov 2015 14:15:55 -0300 Subject: [undertow-dev] HTTP/2 Response Header in Java Message-ID: Hi, Is there already a way to get the HTTP/2 response header in Java using Undertow? I really need to know. I'm using JDK 7 on my Java Project. Thank you very much! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151109/32875f33/attachment.html From tomaz.cerar at gmail.com Mon Nov 9 14:51:15 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 9 Nov 2015 20:51:15 +0100 Subject: [undertow-dev] HTTP/2 Response Header in Java In-Reply-To: References: Message-ID: It is not just http/2 header :) but yes, undertow supports it, to enable it you will need to upgrade to Java 8 and do some additional setup. see https://developer.jboss.org/message/929048 http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html for how to setup it. -- tomaz On Mon, Nov 9, 2015 at 6:15 PM, jorge lima wrote: > Hi, > > Is there already a way to get the HTTP/2 response header in Java using > Undertow? I really need to know. I'm using JDK 7 on my Java Project. Thank > you very much! > > _______________________________________________ > 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/20151109/c221f37a/attachment.html From jorge.ayala2012 at gmail.com Mon Nov 9 15:12:35 2015 From: jorge.ayala2012 at gmail.com (jorge lima) Date: Mon, 9 Nov 2015 17:12:35 -0300 Subject: [undertow-dev] HTTP/2 Response Header in Java In-Reply-To: References: Message-ID: Hi, thanks for the answer. But what I really need to know is to discover if some website uses HTTP/2 or not, like how we use in URLConnection with Java: URL url = new URL("https://developer.jboss.org/"); Map> map = new HashMap<>(); URL obj = new URL(url.toString()); URLConnection conn = obj.openConnection(); map = conn.getHeaderFields(); ... Thanks again! 2015-11-09 16:51 GMT-03:00 Toma? Cerar : > It is not just http/2 header :) > > but yes, undertow supports it, to enable it you will need to upgrade to > Java 8 and do some additional setup. > > see https://developer.jboss.org/message/929048 > http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html > > for how to setup it. > > -- > tomaz > > > On Mon, Nov 9, 2015 at 6:15 PM, jorge lima > wrote: > >> Hi, >> >> Is there already a way to get the HTTP/2 response header in Java using >> Undertow? I really need to know. I'm using JDK 7 on my Java Project. Thank >> you very much! >> >> _______________________________________________ >> 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/20151109/0174e571/attachment.html From sdouglas at redhat.com Mon Nov 9 15:43:44 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 9 Nov 2015 15:43:44 -0500 (EST) Subject: [undertow-dev] HTTP/2 Response Header in Java In-Reply-To: References: Message-ID: <1686768338.5279621.1447101824941.JavaMail.zimbra@redhat.com> You can do: if(exchange.getConnection().getTransportProtocol().equals("h2")) { } You also need to test for h2c if you are using cleartext HTTP2. Stuart ----- Original Message ----- > From: "jorge lima" > To: "Toma? Cerar" > Cc: undertow-dev at lists.jboss.org > Sent: Tuesday, 10 November, 2015 7:12:35 AM > Subject: Re: [undertow-dev] HTTP/2 Response Header in Java > > Hi, > > thanks for the answer. But what I really need to know is to discover if some > website uses HTTP/2 or not, like how we use in URLConnection with Java: > > URL url = new URL(" https://developer.jboss.org/ "); > Map> map = new HashMap<>(); > URL obj = new URL(url.toString()); > URLConnection conn = obj.openConnection(); > map = conn.getHeaderFields(); > ... > > > Thanks again! > > 2015-11-09 16:51 GMT-03:00 Toma? Cerar < tomaz.cerar at gmail.com > : > > > > It is not just http/2 header :) > > but yes, undertow supports it, to enable it you will need to upgrade to Java > 8 and do some additional setup. > > see https://developer.jboss.org/message/929048 > http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html > > for how to setup it. > > -- > tomaz > > > On Mon, Nov 9, 2015 at 6:15 PM, jorge lima < jorge.ayala2012 at gmail.com > > wrote: > > > > Hi, > > Is there already a way to get the HTTP/2 response header in Java using > Undertow? I really need to know. I'm using JDK 7 on my Java Project. Thank > you very much! > > _______________________________________________ > 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 tomaz.cerar at gmail.com Tue Nov 10 05:34:19 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 10 Nov 2015 11:34:19 +0100 Subject: [undertow-dev] HTTP/2 Response Header in Java In-Reply-To: References: Message-ID: First you will need client api that knows how to handle HTTP2. java's URL/URI currently don't support http2 at all. There is JEP http://openjdk.java.net/jeps/110 to add support for it in JDK 9. AFAK at the moment only https://github.com/square/okhttp client properly supports http2. But there is lots of development going on around this topic, best to look the internet for solution that suits you best. -- tomaz On Mon, Nov 9, 2015 at 9:12 PM, jorge lima wrote: > Hi, > > thanks for the answer. But what I really need to know is to discover if > some website uses HTTP/2 or not, like how we use in URLConnection with Java: > > URL url = new URL("https://developer.jboss.org/"); > Map> map = new HashMap<>(); > URL obj = new URL(url.toString()); > URLConnection conn = obj.openConnection(); > map = conn.getHeaderFields(); > ... > > > Thanks again! > > 2015-11-09 16:51 GMT-03:00 Toma? Cerar : > >> It is not just http/2 header :) >> >> but yes, undertow supports it, to enable it you will need to upgrade to >> Java 8 and do some additional setup. >> >> see https://developer.jboss.org/message/929048 >> http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html >> >> for how to setup it. >> >> -- >> tomaz >> >> >> On Mon, Nov 9, 2015 at 6:15 PM, jorge lima >> wrote: >> >>> Hi, >>> >>> Is there already a way to get the HTTP/2 response header in Java using >>> Undertow? I really need to know. I'm using JDK 7 on my Java Project. Thank >>> you very much! >>> >>> _______________________________________________ >>> 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/20151110/47ed3eab/attachment-0001.html From jorge.ayala2012 at gmail.com Tue Nov 10 12:52:51 2015 From: jorge.ayala2012 at gmail.com (jorge lima) Date: Tue, 10 Nov 2015 14:52:51 -0300 Subject: [undertow-dev] HTTP/2 Response Header in Java In-Reply-To: References: Message-ID: Hi, thanks for the answer again, I'm using now this okhttp and looks very good for me, the problem is that I need to know how to set the proper ALPN boot jar in the bootclasspath (Jetty), I'm having troubles: java -Xbootclasspath/p: ... How I'm gonna put a path to alpn boot jar if I don't have any? Here is the link: https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html If you could help me I would appreciate. 2015-11-10 7:34 GMT-03:00 Toma? Cerar : > First you will need client api that knows how to handle HTTP2. > > java's URL/URI currently don't support http2 at all. > There is JEP http://openjdk.java.net/jeps/110 to add support for it in > JDK 9. > > AFAK at the moment only https://github.com/square/okhttp client properly > supports http2. > But there is lots of development going on around this topic, best to look > the internet > for solution that suits you best. > > -- > tomaz > > > > On Mon, Nov 9, 2015 at 9:12 PM, jorge lima > wrote: > >> Hi, >> >> thanks for the answer. But what I really need to know is to discover if >> some website uses HTTP/2 or not, like how we use in URLConnection with Java: >> >> URL url = new URL("https://developer.jboss.org/"); >> Map> map = new HashMap<>(); >> URL obj = new URL(url.toString()); >> URLConnection conn = obj.openConnection(); >> map = conn.getHeaderFields(); >> ... >> >> >> Thanks again! >> >> 2015-11-09 16:51 GMT-03:00 Toma? Cerar : >> >>> It is not just http/2 header :) >>> >>> but yes, undertow supports it, to enable it you will need to upgrade to >>> Java 8 and do some additional setup. >>> >>> see https://developer.jboss.org/message/929048 >>> http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html >>> >>> for how to setup it. >>> >>> -- >>> tomaz >>> >>> >>> On Mon, Nov 9, 2015 at 6:15 PM, jorge lima >>> wrote: >>> >>>> Hi, >>>> >>>> Is there already a way to get the HTTP/2 response header in Java using >>>> Undertow? I really need to know. I'm using JDK 7 on my Java Project. Thank >>>> you very much! >>>> >>>> _______________________________________________ >>>> 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/20151110/979c1f8d/attachment.html From jason.greene at redhat.com Tue Nov 10 14:06:37 2015 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 10 Nov 2015 13:06:37 -0600 Subject: [undertow-dev] HTTP/2 Response Header in Java In-Reply-To: References: Message-ID: <81356446-F14B-4428-A099-BA1634E34DB0@redhat.com> The ALPN jars are on maven central here: https://repo1.maven.org/maven2/org/mortbay/jetty/alpn/alpn-boot/ You have to match the specific version for the JDK version that you use, which is documented on the alpa-chapter you linked. > On Nov 10, 2015, at 11:52 AM, jorge lima wrote: > > Hi, > > thanks for the answer again, I'm using now this okhttp and looks very good for me, the problem is that I need to know how to set the proper ALPN boot jar in the bootclasspath (Jetty), I'm having troubles: > > java -Xbootclasspath/p: ... > > How I'm gonna put a path to alpn boot jar if I don't have any? > > Here is the link: > > https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html > > If you could help me I would appreciate. > > > > 2015-11-10 7:34 GMT-03:00 Toma? Cerar >: > First you will need client api that knows how to handle HTTP2. > > java's URL/URI currently don't support http2 at all. > There is JEP http://openjdk.java.net/jeps/110 to add support for it in JDK 9. > > AFAK at the moment only https://github.com/square/okhttp client properly supports http2. > But there is lots of development going on around this topic, best to look the internet > for solution that suits you best. > > -- > tomaz > > > > On Mon, Nov 9, 2015 at 9:12 PM, jorge lima > wrote: > Hi, > > thanks for the answer. But what I really need to know is to discover if some website uses HTTP/2 or not, like how we use in URLConnection with Java: > > URL url = new URL("https://developer.jboss.org/ "); > Map> map = new HashMap<>(); > URL obj = new URL(url.toString()); > URLConnection conn = obj.openConnection(); > map = conn.getHeaderFields(); > ... > > > Thanks again! > > 2015-11-09 16:51 GMT-03:00 Toma? Cerar >: > It is not just http/2 header :) > > but yes, undertow supports it, to enable it you will need to upgrade to Java 8 and do some additional setup. > > see https://developer.jboss.org/message/929048 > http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html > > for how to setup it. > > -- > tomaz > > > On Mon, Nov 9, 2015 at 6:15 PM, jorge lima > wrote: > Hi, > > Is there already a way to get the HTTP/2 response header in Java using Undertow? I really need to know. I'm using JDK 7 on my Java Project. Thank you very much! > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151110/da57851e/attachment.html From jason.greene at redhat.com Wed Nov 11 12:12:48 2015 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 11 Nov 2015 11:12:48 -0600 Subject: [undertow-dev] HTTP/2 Response Header in Java In-Reply-To: References: <81356446-F14B-4428-A099-BA1634E34DB0@redhat.com> Message-ID: <90CEE7EF-C2BE-4184-BE89-447777488817@redhat.com> > On Nov 11, 2015, at 11:09 AM, jorge lima wrote: > > Hi, > > now I think I'm almost there, when I run my project, it appears this message on console: > > nov 11, 2015 1:48:07 PM com.squareup.okhttp.internal.Platform$JdkWithJettyBootPlatform getSelectedProtocol > > INFO: ALPN callback dropped: SPDY and HTTP/2 are disabled. Is alpn-boot on the boot class path? > > I've tryed to enable the alpn-boot using the command shown on eclipse jetty website: > > > java -Xbootclasspath/p: ... > > > Then I goes to my cmd, used the command 'cd ' to go to my Java Project and used the following: > > java -Xbootclasspath/p:/libs/alpn-boot-8.1.6.v20151105.jar ... > > So it always print a help list, doesn't execute nothing for real, then I've tried this: > > java -Xbootclasspath/p:/libs/alpn-boot-8.1.6.v20151105.jar Test.class The ? means ?insert your normal JVM arguments here? Assuming that Test.class is in the default package, and in your current directory you would do: java -Xbootclasspath/p:/libs/alpn-boot-8.1.6.v20151105.jar Test > > Where this class have a main method and prints: 'Error: Could not find or load main class Test.class' > > I've tested some things that took me hours to have nothing. Why they put this '...' on their command if they even explain very well how to do, I'm lost here, sadly. > > Do you have some clear example how I have to do to activate the alpn-boot on my boot class path? I would thank you so much man... > > 2015-11-10 16:06 GMT-03:00 Jason Greene >: > The ALPN jars are on maven central here: > > https://repo1.maven.org/maven2/org/mortbay/jetty/alpn/alpn-boot/ > > You have to match the specific version for the JDK version that you use, which is documented on the alpa-chapter you linked. > >> On Nov 10, 2015, at 11:52 AM, jorge lima > wrote: >> >> Hi, >> >> thanks for the answer again, I'm using now this okhttp and looks very good for me, the problem is that I need to know how to set the proper ALPN boot jar in the bootclasspath (Jetty), I'm having troubles: >> >> java -Xbootclasspath/p: ... >> >> How I'm gonna put a path to alpn boot jar if I don't have any? >> >> Here is the link: >> >> https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html >> >> If you could help me I would appreciate. >> >> >> >> 2015-11-10 7:34 GMT-03:00 Toma? Cerar >: >> First you will need client api that knows how to handle HTTP2. >> >> java's URL/URI currently don't support http2 at all. >> There is JEP http://openjdk.java.net/jeps/110 to add support for it in JDK 9. >> >> AFAK at the moment only https://github.com/square/okhttp client properly supports http2. >> But there is lots of development going on around this topic, best to look the internet >> for solution that suits you best. >> >> -- >> tomaz >> >> >> >> On Mon, Nov 9, 2015 at 9:12 PM, jorge lima > wrote: >> Hi, >> >> thanks for the answer. But what I really need to know is to discover if some website uses HTTP/2 or not, like how we use in URLConnection with Java: >> >> URL url = new URL("https://developer.jboss.org/ "); >> Map> map = new HashMap<>(); >> URL obj = new URL(url.toString()); >> URLConnection conn = obj.openConnection(); >> map = conn.getHeaderFields(); >> ... >> >> >> Thanks again! >> >> 2015-11-09 16:51 GMT-03:00 Toma? Cerar >: >> It is not just http/2 header :) >> >> but yes, undertow supports it, to enable it you will need to upgrade to Java 8 and do some additional setup. >> >> see https://developer.jboss.org/message/929048 >> http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html >> >> for how to setup it. >> >> -- >> tomaz >> >> >> On Mon, Nov 9, 2015 at 6:15 PM, jorge lima > wrote: >> Hi, >> >> Is there already a way to get the HTTP/2 response header in Java using Undertow? I really need to know. I'm using JDK 7 on my Java Project. Thank you very much! >> >> _______________________________________________ >> 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 > > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151111/774dc28b/attachment-0001.html From jorge.ayala2012 at gmail.com Wed Nov 11 12:09:17 2015 From: jorge.ayala2012 at gmail.com (jorge lima) Date: Wed, 11 Nov 2015 14:09:17 -0300 Subject: [undertow-dev] HTTP/2 Response Header in Java In-Reply-To: <81356446-F14B-4428-A099-BA1634E34DB0@redhat.com> References: <81356446-F14B-4428-A099-BA1634E34DB0@redhat.com> Message-ID: Hi, now I think I'm almost there, when I run my project, it appears this message on console: *nov 11, 2015 1:48:07 PM com.squareup.okhttp.internal.Platform$JdkWithJettyBootPlatform getSelectedProtocol* *INFO: ALPN callback dropped: SPDY and HTTP/2 are disabled. Is alpn-boot on the boot class path?* I've tryed to enable the alpn-boot using the command shown on eclipse jetty website: java -Xbootclasspath/p: ... Then I goes to my cmd, used the command 'cd ' to go to my Java Project and used the following: java -Xbootclasspath/p:/libs/alpn-boot-8.1.6.v20151105.jar ... So it always print a help list, doesn't execute nothing for real, then I've tried this: java -Xbootclasspath/p:/libs/alpn-boot-8.1.6.v20151105.jar Test.class Where this class have a main method and prints: 'Error: Could not find or load main class Test.class' I've tested some things that took me hours to have nothing. Why they put this '...' on their command if they even explain very well how to do, I'm lost here, sadly. Do you have some clear example how I have to do to activate the alpn-boot on my boot class path? I would thank you so much man... 2015-11-10 16:06 GMT-03:00 Jason Greene : > The ALPN jars are on maven central here: > > https://repo1.maven.org/maven2/org/mortbay/jetty/alpn/alpn-boot/ > > You have to match the specific version for the JDK version that you use, > which is documented on the alpa-chapter you linked. > > On Nov 10, 2015, at 11:52 AM, jorge lima > wrote: > > Hi, > > thanks for the answer again, I'm using now this okhttp and looks very good > for me, the problem is that I need to know how to set the proper ALPN boot > jar in the bootclasspath (Jetty), I'm having troubles: > > java -Xbootclasspath/p: ... > > How I'm gonna put a path to alpn boot jar if I don't have any? > > Here is the link: > > https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html > > If you could help me I would appreciate. > > > > 2015-11-10 7:34 GMT-03:00 Toma? Cerar : > >> First you will need client api that knows how to handle HTTP2. >> >> java's URL/URI currently don't support http2 at all. >> There is JEP http://openjdk.java.net/jeps/110 to add support for it in >> JDK 9. >> >> AFAK at the moment only https://github.com/square/okhttp client properly >> supports http2. >> But there is lots of development going on around this topic, best to look >> the internet >> for solution that suits you best. >> >> -- >> tomaz >> >> >> >> On Mon, Nov 9, 2015 at 9:12 PM, jorge lima >> wrote: >> >>> Hi, >>> >>> thanks for the answer. But what I really need to know is to discover if >>> some website uses HTTP/2 or not, like how we use in URLConnection with Java: >>> >>> URL url = new URL("https://developer.jboss.org/"); >>> Map> map = new HashMap<>(); >>> URL obj = new URL(url.toString()); >>> URLConnection conn = obj.openConnection(); >>> map = conn.getHeaderFields(); >>> ... >>> >>> >>> Thanks again! >>> >>> 2015-11-09 16:51 GMT-03:00 Toma? Cerar : >>> >>>> It is not just http/2 header :) >>>> >>>> but yes, undertow supports it, to enable it you will need to upgrade to >>>> Java 8 and do some additional setup. >>>> >>>> see https://developer.jboss.org/message/929048 >>>> http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html >>>> >>>> for how to setup it. >>>> >>>> -- >>>> tomaz >>>> >>>> >>>> On Mon, Nov 9, 2015 at 6:15 PM, jorge lima >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Is there already a way to get the HTTP/2 response header in Java using >>>>> Undertow? I really need to know. I'm using JDK 7 on my Java Project. Thank >>>>> you very much! >>>>> >>>>> _______________________________________________ >>>>> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151111/a6323b6d/attachment.html From robin.anil at gmail.com Sat Nov 14 13:56:28 2015 From: robin.anil at gmail.com (Robin Anil) Date: Sat, 14 Nov 2015 12:56:28 -0600 Subject: [undertow-dev] Unified SecurityContext/Exchange/Session for Http and Websockets Message-ID: Currently the code path requires separate mechanisms for http and websockets. This means the guice scoping logic gets complicated for all business objects derived from SecurityContext/Exchange For example lets say we are sending a cookie containing a JWT token. For Http we have written an Authentication mechanism which creates a security context and then a guice injector which gets the authenticated data from the security context Principal. Now if we need to support websockets, firstly the authentication mechanism is non existent. Another example is the Headers. In HttpServerExchange the headers are in a HeaderMap but for websockets it is a Map>. The injection code that worked off HeaderMap now no longer work in Websocket context. I feel like this can be improved if there are shared interfaces for these core objects across Http and Websockets so that it becomes easy for downstream code to re-use business object injection logic across the two Thoughts? Robin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151114/40133702/attachment.html From jnethert at redhat.com Tue Nov 17 11:48:22 2015 From: jnethert at redhat.com (James Netherton) Date: Tue, 17 Nov 2015 11:48:22 -0500 (EST) Subject: [undertow-dev] Undertow client and ByteBuffer pools In-Reply-To: <533535377.14347129.1447778446588.JavaMail.zimbra@redhat.com> Message-ID: <2066312242.14353185.1447778902445.JavaMail.zimbra@redhat.com> Hi, I've been tinkering with the Apache Camel Undertow component. The Camel producer makes use of UndertowClient for HTTP requests. I end up getting OutOfMemoryError exceptions when running the test suite where the producer has been invoked around 25 - 30 times. I think the way in which the UndertowClient is being configured is sub-optimal. For example, for each producer that's started it creates a (pretty large) ByteBufferSlicePool. https://github.com/apache/camel/blob/master/components/camel-undertow/src/main/java/org/apache/camel/component/undertow/UndertowProducer.java#L130 Which is then used in the client.connect() call whenever the producer runs: https://github.com/apache/camel/blob/master/components/camel-undertow/src/main/java/org/apache/camel/component/undertow/UndertowProducer.java#L80 What's a better, more efficient way of configuring this? Cheers, James From robin.anil at gmail.com Thu Nov 19 15:12:08 2015 From: robin.anil at gmail.com (Robin Anil) Date: Thu, 19 Nov 2015 14:12:08 -0600 Subject: [undertow-dev] Correctly shutting down a websocket handler Message-ID: When a client disconnects, I see that onClose is not being fired. The only way this seems to be firing if client sents a close frame. Is there any way to detect disconnection and immediately close all the opened resources. Robin Robin Anil | Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151119/f4546d65/attachment.html From dennis at gesker.com Fri Nov 20 11:51:31 2015 From: dennis at gesker.com (Dennis Gesker) Date: Fri, 20 Nov 2015 09:51:31 -0700 Subject: [undertow-dev] Correctly shutting down a websocket handler In-Reply-To: References: Message-ID: Hi Robin: I'm new to WebSockets but I'm glad to share what has been working for me. My use cases are currently via Java SE not the Web so this may not apply. I'm migrating a bunch of data from an old system and really just pounding on Undertow to see how it will behave when I'm ready to build my production application. And, I in no way claim this is a best practice. But, maybe you will find it useful. Anyway, I add three additional methods to each of my deocorated websockets (clients) two of which I call from other objects as needed. With this approach I'm not seeing any data loss. Seem to be getting timely responses from the server side WebSocket. And, always get a nice clean [1000] close codes. setup() tearDown() sendWorktoServer() public void sendWorkToServer(Object obj) { //logger.info(this.getClass().getSimpleName() + " >>> Enter sendWorkToServer"); if (webSocketSession == null || !webSocketSession.isOpen()) { setUp(); } if (obj == null || obj.getId() == null || obj.getId().isEmpty()) { return; } ObjectMapper mapper = new ObjectMapper(); String json = null; try { json = mapper.writerWithDefaultPrettyPrinter().writeValueAsString(obj); logger.info(json); webSocketSession.getAsyncRemote().sendText(json); //messageLatch.await(500, TimeUnit.MILLISECONDS); } catch (JsonProcessingException e) { e.printStackTrace(); } logger.info("Socket is open: " + webSocketSession.isOpen()); logger.info("Exit sendWorkToServer"); } private boolean setUp() { //Called if needed inside sendWorkToServer() method try { websocketServerURI = serverSocketURI.getAddCfgStructureWsUri(); // Get Correct URI Development vs Production logger.info("URI: " + websocketServerURI.toString()); webSocketContainer = ContainerProvider.getWebSocketContainer(); // WebSocket Container webSocketSession = webSocketContainer.connectToServer(this.getClass(), websocketServerURI); // Connect to the Server if (!webSocketSession.isOpen()) { messageLatch.await(10, TimeUnit.SECONDS); } } catch (DeploymentException e) { e.printStackTrace(); return false; } catch (IOException e) { e.printStackTrace(); return false; } catch (InterruptedException e) { e.printStackTrace(); } return true; } public boolean tearDown() { if (webSocketSession != null) { if (webSocketSession.isOpen()) { try { webSocketSession.close(); } catch (IOException e) { e.printStackTrace(); return false; } } } webSocketSession = null; webSocketContainer = null; websocketServerURI = null; serverSocketURI = null; return true; } So, inside my other object the code looks something like... WebSocketClient wcs = new WebSocketClient(); wcs.sendWorkToServer(Object obj); // More work and activities wcs.teardown(); wcs = null; Also, what might be helpful is to add a custom method that just return the status of your websocketclient session and then call teardown() as needed. I hope that helps a bit... In my scenario I take some extra steps to control the life cycle so I don't really have to detect status. Cordially, Dennis On Thu, Nov 19, 2015 at 1:12 PM, Robin Anil wrote: > When a client disconnects, I see that onClose is not being fired. The > only way this seems to be firing if client sents a close frame. > > Is there any way to detect disconnection and immediately close all the > opened resources. > > Robin > > Robin Anil | Software Engineer > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -- [image: LinkedIn] [image: Wordpress] [image: Facebook][image: Twitter] [image: Family Home Page][image: Public Encryption Key] [image: dennis at gesker.com] ?Be without fear in the face of your enemies. Be brave and upright that God may love thee. Speak the truth always, even if it leads to your death. Safeguard the helpless and do no wrong ? that is your oath.?* -The Knight?s Oath (Kingdom of Heaven)* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151120/6d84940d/attachment-0001.html From bburke at redhat.com Fri Nov 20 19:56:34 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 Nov 2015 19:56:34 -0500 Subject: [undertow-dev] way to call sendError within AuthMech? Message-ID: <564FC142.4050307@redhat.com> Is there a way to call HttpServletResponse.sendError() within a AuthenticationMechanism? I'm getting the following after calling sendError and returning AuthenticationMechanismOutcome.NOT_AUTHENTICATED java.lang.IllegalStateException: UT010019: Response already commited at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:124) at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:167) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:61) at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Nov 20 20:02:42 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 Nov 2015 20:02:42 -0500 Subject: [undertow-dev] way to call sendError within AuthMech? In-Reply-To: <564FC142.4050307@redhat.com> References: <564FC142.4050307@redhat.com> Message-ID: <564FC2B2.2080004@redhat.com> Meh, nevermind...Just gotta encapsulate the call within a challenge. On 11/20/2015 7:56 PM, Bill Burke wrote: > Is there a way to call HttpServletResponse.sendError() within a > AuthenticationMechanism? I'm getting the following after calling > sendError and returning AuthenticationMechanismOutcome.NOT_AUTHENTICATED > > > java.lang.IllegalStateException: UT010019: Response already commited > at > io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:124) > at > io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:167) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:61) > at > io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From arjan.tijms at gmail.com Sat Nov 21 11:16:24 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Sat, 21 Nov 2015 17:16:24 +0100 Subject: [undertow-dev] way to call sendError within AuthMech? In-Reply-To: <564FC2B2.2080004@redhat.com> References: <564FC142.4050307@redhat.com> <564FC2B2.2080004@redhat.com> Message-ID: Perhaps a coincidence, but it's pretty much the same error as reported here: https://issues.jboss.org/browse/UNDERTOW-577 And the same error that makes it impossible to call sendError in an authentication module (where there's no such thing as encapsulating within a challenge). The fix has solved those 2 issues, but it's not yet available in a released (or nightly) WildFly build afaik. On Sat, Nov 21, 2015 at 2:02 AM, Bill Burke wrote: > Meh, nevermind...Just gotta encapsulate the call within a challenge. > > On 11/20/2015 7:56 PM, Bill Burke wrote: > > Is there a way to call HttpServletResponse.sendError() within a > > AuthenticationMechanism? I'm getting the following after calling > > sendError and returning AuthenticationMechanismOutcome.NOT_AUTHENTICATED > > > > > > java.lang.IllegalStateException: UT010019: Response already commited > > at > > > io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:124) > > at > > > io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:167) > > at > > > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:61) > > at > > > io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) > > at > > > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > > > > > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > 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/20151121/5aec37fe/attachment.html From sdouglas at redhat.com Sun Nov 22 16:02:11 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 22 Nov 2015 16:02:11 -0500 (EST) Subject: [undertow-dev] Unified SecurityContext/Exchange/Session for Http and Websockets In-Reply-To: References: Message-ID: <1868339567.12259042.1448226131097.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Robin Anil" > To: undertow-dev at lists.jboss.org > Sent: Sunday, 15 November, 2015 5:56:28 AM > Subject: [undertow-dev] Unified SecurityContext/Exchange/Session for Http and Websockets > > Currently the code path requires separate mechanisms for http and websockets. > This means the guice scoping logic gets complicated for all business objects > derived from SecurityContext/Exchange > > For example lets say we are sending a cookie containing a JWT token. For Http > we have written an Authentication mechanism which creates a security context > and then a guice injector which gets the authenticated data from the > security context Principal. > > Now if we need to support websockets, firstly the authentication mechanism is > non existent. Websockets is expected to piggy back on HTTP authentication, i.e. you should authenticate the initial request. The websocket protocol itself does not support authentication. > > Another example is the Headers. In HttpServerExchange the headers are in a > HeaderMap but for websockets it is a Map>. The > injection code that worked off HeaderMap now no longer work in Websocket > context. This representation was chosen because this is how JSR-356 expects the headers (e.g. javax.websocket.server.HandshakeRequest#getHeaders). Stuart > > > I feel like this can be improved if there are shared interfaces for these > core objects across Http and Websockets so that it becomes easy for > downstream code to re-use business object injection logic across the two > > Thoughts? > > > Robin > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Sun Nov 22 16:06:38 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 22 Nov 2015 16:06:38 -0500 (EST) Subject: [undertow-dev] Undertow client and ByteBuffer pools In-Reply-To: <2066312242.14353185.1447778902445.JavaMail.zimbra@redhat.com> References: <2066312242.14353185.1447778902445.JavaMail.zimbra@redhat.com> Message-ID: <1645165179.12259213.1448226398339.JavaMail.zimbra@redhat.com> One possibility is to just use a shared pool between all components (there is no real disadvantage to this, under super high load you may end up with slightly higher contention but this is unlikely to be a problem in reality). You could also try using heap buffers instead of direct buffer (change the 'true' to 'false' when creating the pool). It may be that your JVM does not have a large amount of direct buffer memory available. Stuart ----- Original Message ----- > From: "James Netherton" > To: undertow-dev at lists.jboss.org > Sent: Wednesday, 18 November, 2015 3:48:22 AM > Subject: [undertow-dev] Undertow client and ByteBuffer pools > > Hi, > > I've been tinkering with the Apache Camel Undertow component. The Camel > producer makes use of UndertowClient for HTTP requests. I end up getting > OutOfMemoryError exceptions when running the test suite where the producer > has been invoked around 25 - 30 times. > > I think the way in which the UndertowClient is being configured is > sub-optimal. For example, for each producer that's started it creates a > (pretty large) ByteBufferSlicePool. > > https://github.com/apache/camel/blob/master/components/camel-undertow/src/main/java/org/apache/camel/component/undertow/UndertowProducer.java#L130 > > Which is then used in the client.connect() call whenever the producer runs: > > https://github.com/apache/camel/blob/master/components/camel-undertow/src/main/java/org/apache/camel/component/undertow/UndertowProducer.java#L80 > > What's a better, more efficient way of configuring this? > > Cheers, > > James > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From sdouglas at redhat.com Sun Nov 22 16:07:52 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 22 Nov 2015 16:07:52 -0500 (EST) Subject: [undertow-dev] Correctly shutting down a websocket handler In-Reply-To: References: Message-ID: <24215028.12259349.1448226472095.JavaMail.zimbra@redhat.com> @OnError should be called if @OnClose is not called (if neither is being called this is a bug). Stuart ----- Original Message ----- > From: "Dennis Gesker" > To: "Robin Anil" > Cc: undertow-dev at lists.jboss.org > Sent: Saturday, 21 November, 2015 3:51:31 AM > Subject: Re: [undertow-dev] Correctly shutting down a websocket handler > > Hi Robin: > > I'm new to WebSockets but I'm glad to share what has been working for me. My > use cases are currently via Java SE not the Web so this may not apply. I'm > migrating a bunch of data from an old system and really just pounding on > Undertow to see how it will behave when I'm ready to build my production > application. And, I in no way claim this is a best practice. But, maybe you > will find it useful. > > Anyway, I add three additional methods to each of my deocorated websockets > (clients) two of which I call from other objects as needed. With this > approach I'm not seeing any data loss. Seem to be getting timely responses > from the server side WebSocket. And, always get a nice clean [1000] close > codes. > > setup() > tearDown() > sendWorktoServer() > > > public void sendWorkToServer(Object obj) { > // logger.info (this.getClass().getSimpleName() + " >>> Enter > sendWorkToServer"); > > if (webSocketSession == null || !webSocketSession.isOpen()) { > setUp(); > } > > if (obj == null || obj.getId() == null || obj.getId().isEmpty()) { > return; > } > > ObjectMapper mapper = new ObjectMapper(); > String json = null; > > > > try { > json = mapper.writerWithDefaultPrettyPrinter().writeValueAsString(obj); > logger.info (json); > webSocketSession.getAsyncRemote().sendText(json); > //messageLatch.await(500, TimeUnit.MILLISECONDS); > } catch (JsonProcessingException e) { > e.printStackTrace(); > } > > > logger.info ("Socket is open: " + webSocketSession.isOpen()); > logger.info ("Exit sendWorkToServer"); > } > > private boolean setUp() { //Called if needed inside sendWorkToServer() method > > try { > websocketServerURI = serverSocketURI.getAddCfgStructureWsUri(); // Get > Correct URI Development vs Production > logger.info ("URI: " + websocketServerURI.toString()); > webSocketContainer = ContainerProvider.getWebSocketContainer(); // WebSocket > Container > webSocketSession = webSocketContainer.connectToServer(this.getClass(), > websocketServerURI); // Connect to the Server > if (!webSocketSession.isOpen()) { > messageLatch.await(10, TimeUnit.SECONDS); > } > > } catch (DeploymentException e) { > e.printStackTrace(); > return false; > } catch (IOException e) { > e.printStackTrace(); > return false; > } catch (InterruptedException e) { > e.printStackTrace(); > } > > return true; > > } > > public boolean tearDown() { > > if (webSocketSession != null) { > if (webSocketSession.isOpen()) { > try { > webSocketSession.close(); > } catch (IOException e) { > e.printStackTrace(); > return false; > } > } > } > webSocketSession = null; > webSocketContainer = null; > websocketServerURI = null; > serverSocketURI = null; > return true; > } > > > So, inside my other object the code looks something like... > > WebSocketClient wcs = new WebSocketClient(); > wcs.sendWorkToServer(Object obj); > // More work and activities > wcs.teardown(); > wcs = null; > > Also, what might be helpful is to add a custom method that just return the > status of your websocketclient session and then call teardown() as needed. > I hope that helps a bit... In my scenario I take some extra steps to control > the life cycle so I don't really have to detect status. > > Cordially, > Dennis > > > > > > > > On Thu, Nov 19, 2015 at 1:12 PM, Robin Anil < robin.anil at gmail.com > wrote: > > > > When a client disconnects, I see that onClose is not being fired. The only > way this seems to be firing if client sents a close frame. > > Is there any way to detect disconnection and immediately close all the opened > resources. > > Robin > > Robin Anil | Software Engineer > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > -- > > ?Be without fear in the face of your enemies. Be brave and upright that God > may love thee. Speak the truth always, even if it leads to your death. > Safeguard the helpless and do no wrong ? that is your oath.? -The Knight?s > Oath (Kingdom of Heaven) > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From nel.taurisson at gmail.com Mon Nov 23 01:00:10 2015 From: nel.taurisson at gmail.com (Nel Taurisson) Date: Mon, 23 Nov 2015 07:00:10 +0100 Subject: [undertow-dev] SSE close task Message-ID: Hi, I'm playing with the SSE handler and I can't figure how the close task is working. I thought the close task would be invoked when the client closes the connection but it doesn't seem to be the case. I slightly modified the example code to register a close task when a connection is initiated, here's the code : ServerSentEventConnectionCallback callback = new ServerSentEventConnectionCallback() { @Override public void connected(ServerSentEventConnection connection, String lastEventId) { System.out.println("adding close task on connection..."); connection.addCloseTask(channel -> System.out.println("goodbye cruel world...")); } }; final ServerSentEventHandler sseHandler = Handlers.serverSentEvents(callback); It appears to me that the close task is only invoked when the server stops, but now when the client closes. Is it the expected behavior ? If so, is there any other way to be notified of a client disconnection ? Thanks a lot. Nel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151123/f70dadba/attachment-0001.html From sdouglas at redhat.com Mon Nov 23 01:46:53 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 23 Nov 2015 01:46:53 -0500 (EST) Subject: [undertow-dev] SSE close task In-Reply-To: References: Message-ID: <463914263.12388092.1448261213712.JavaMail.zimbra@redhat.com> This sounds like a bug, can you file a JIRA? https://issues.jboss.org/projects/UNDERTOW Stuart ----- Original Message ----- > From: "Nel Taurisson" > To: undertow-dev at lists.jboss.org > Sent: Monday, 23 November, 2015 5:00:10 PM > Subject: [undertow-dev] SSE close task > > Hi, > > I'm playing with the SSE handler and I can't figure how the close task is > working. I thought the close task would be invoked when the client closes > the connection but it doesn't seem to be the case. > > I slightly modified the example code to register a close task when a > connection is initiated, here's the code : > > ServerSentEventConnectionCallback callback = new > ServerSentEventConnectionCallback() { > @Override > public void connected(ServerSentEventConnection connection, String > lastEventId) { > System.out.println("adding close task on connection..."); > connection.addCloseTask(channel -> System.out.println("goodbye cruel > world...")); > } > }; > final ServerSentEventHandler sseHandler = > Handlers.serverSentEvents(callback); > > It appears to me that the close task is only invoked when the server stops, > but now when the client closes. Is it the expected behavior ? If so, is > there any other way to be notified of a client disconnection ? > > Thanks a lot. > > Nel > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From robin.anil at gmail.com Mon Nov 23 14:37:01 2015 From: robin.anil at gmail.com (Robin Anil) Date: Mon, 23 Nov 2015 13:37:01 -0600 Subject: [undertow-dev] Correctly shutting down a websocket handler In-Reply-To: <24215028.12259349.1448226472095.JavaMail.zimbra@redhat.com> References: <24215028.12259349.1448226472095.JavaMail.zimbra@redhat.com> Message-ID: I can verify that neither onError or onClose is being called however CloseTask is being called. Robin public class WebSocketConnectionHandler extends AbstractReceiveListener implements WebSocketConnectionCallback { @Override public void onConnect(WebSocketHttpExchange exchange, WebSocketChannel webSocketChannel) { System.out.println("onConnect"); webSocketChannel.getReceiveSetter().set(this); webSocketChannel.resumeReceives(); webSocketChannel.addCloseTask(channel -> { System.out.println("Closing"); }); } @Override protected void onFullTextMessage(WebSocketChannel channel, BufferedTextMessage message) { System.out.println("onFullTextMessage"); super.onFullTexMessage(channel, message); } @Override protected void onError(WebSocketChannel channel, Throwable error) { System.out.println("error"); super.onError(channel, error); } @Override protected void onClose(WebSocketChannel webSocketChannel, StreamSourceFrameChannel channel) throws IOException { System.out.println("onClose"); super.onClose(webSocketChannel, channel); } @Override protected void onFullCloseMessage(WebSocketChannel channel, BufferedBinaryMessage message) throws IOException { System.out.println("onFullCloseMessage"); super.onFullCloseMessage(channel, message); } @Override protected void onCloseMessage(CloseMessage cm, WebSocketChannel channel) { System.out.println("onCloseMessage"); super.onCloseMessage(cm, channel); } } Robin Anil | Software Engineer On Sun, Nov 22, 2015 at 3:07 PM, Stuart Douglas wrote: > @OnError should be called if @OnClose is not called (if neither is being > called this is a bug). > > Stuart > > ----- Original Message ----- > > From: "Dennis Gesker" > > To: "Robin Anil" > > Cc: undertow-dev at lists.jboss.org > > Sent: Saturday, 21 November, 2015 3:51:31 AM > > Subject: Re: [undertow-dev] Correctly shutting down a websocket handler > > > > Hi Robin: > > > > I'm new to WebSockets but I'm glad to share what has been working for > me. My > > use cases are currently via Java SE not the Web so this may not apply. > I'm > > migrating a bunch of data from an old system and really just pounding on > > Undertow to see how it will behave when I'm ready to build my production > > application. And, I in no way claim this is a best practice. But, maybe > you > > will find it useful. > > > > Anyway, I add three additional methods to each of my deocorated > websockets > > (clients) two of which I call from other objects as needed. With this > > approach I'm not seeing any data loss. Seem to be getting timely > responses > > from the server side WebSocket. And, always get a nice clean [1000] close > > codes. > > > > setup() > > tearDown() > > sendWorktoServer() > > > > > > public void sendWorkToServer(Object obj) { > > // logger.info (this.getClass().getSimpleName() + " >>> Enter > > sendWorkToServer"); > > > > if (webSocketSession == null || !webSocketSession.isOpen()) { > > setUp(); > > } > > > > if (obj == null || obj.getId() == null || obj.getId().isEmpty()) { > > return; > > } > > > > ObjectMapper mapper = new ObjectMapper(); > > String json = null; > > > > > > > > try { > > json = mapper.writerWithDefaultPrettyPrinter().writeValueAsString(obj); > > logger.info (json); > > webSocketSession.getAsyncRemote().sendText(json); > > //messageLatch.await(500, TimeUnit.MILLISECONDS); > > } catch (JsonProcessingException e) { > > e.printStackTrace(); > > } > > > > > > logger.info ("Socket is open: " + webSocketSession.isOpen()); > > logger.info ("Exit sendWorkToServer"); > > } > > > > private boolean setUp() { //Called if needed inside sendWorkToServer() > method > > > > try { > > websocketServerURI = serverSocketURI.getAddCfgStructureWsUri(); // Get > > Correct URI Development vs Production > > logger.info ("URI: " + websocketServerURI.toString()); > > webSocketContainer = ContainerProvider.getWebSocketContainer(); // > WebSocket > > Container > > webSocketSession = webSocketContainer.connectToServer(this.getClass(), > > websocketServerURI); // Connect to the Server > > if (!webSocketSession.isOpen()) { > > messageLatch.await(10, TimeUnit.SECONDS); > > } > > > > } catch (DeploymentException e) { > > e.printStackTrace(); > > return false; > > } catch (IOException e) { > > e.printStackTrace(); > > return false; > > } catch (InterruptedException e) { > > e.printStackTrace(); > > } > > > > return true; > > > > } > > > > public boolean tearDown() { > > > > if (webSocketSession != null) { > > if (webSocketSession.isOpen()) { > > try { > > webSocketSession.close(); > > } catch (IOException e) { > > e.printStackTrace(); > > return false; > > } > > } > > } > > webSocketSession = null; > > webSocketContainer = null; > > websocketServerURI = null; > > serverSocketURI = null; > > return true; > > } > > > > > > So, inside my other object the code looks something like... > > > > WebSocketClient wcs = new WebSocketClient(); > > wcs.sendWorkToServer(Object obj); > > // More work and activities > > wcs.teardown(); > > wcs = null; > > > > Also, what might be helpful is to add a custom method that just return > the > > status of your websocketclient session and then call teardown() as > needed. > > I hope that helps a bit... In my scenario I take some extra steps to > control > > the life cycle so I don't really have to detect status. > > > > Cordially, > > Dennis > > > > > > > > > > > > > > > > On Thu, Nov 19, 2015 at 1:12 PM, Robin Anil < robin.anil at gmail.com > > wrote: > > > > > > > > When a client disconnects, I see that onClose is not being fired. The > only > > way this seems to be firing if client sents a close frame. > > > > Is there any way to detect disconnection and immediately close all the > opened > > resources. > > > > Robin > > > > Robin Anil | Software Engineer > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > > > > > -- > > > > ?Be without fear in the face of your enemies. Be brave and upright that > God > > may love thee. Speak the truth always, even if it leads to your death. > > Safeguard the helpless and do no wrong ? that is your oath.? -The > Knight?s > > Oath (Kingdom of Heaven) > > > > _______________________________________________ > > 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/20151123/7f81735c/attachment.html From nel.taurisson at gmail.com Mon Nov 23 16:31:35 2015 From: nel.taurisson at gmail.com (Nel Taurisson) Date: Mon, 23 Nov 2015 22:31:35 +0100 Subject: [undertow-dev] SSE close task In-Reply-To: <463914263.12388092.1448261213712.JavaMail.zimbra@redhat.com> References: <463914263.12388092.1448261213712.JavaMail.zimbra@redhat.com> Message-ID: Ok, thanks, here's the JIRA with a failing test attached as a patch: https://issues.jboss.org/browse/UNDERTOW-589 Nel 2015-11-23 7:46 GMT+01:00 Stuart Douglas : > This sounds like a bug, can you file a JIRA? > > https://issues.jboss.org/projects/UNDERTOW > > Stuart > > ----- Original Message ----- > > From: "Nel Taurisson" > > To: undertow-dev at lists.jboss.org > > Sent: Monday, 23 November, 2015 5:00:10 PM > > Subject: [undertow-dev] SSE close task > > > > Hi, > > > > I'm playing with the SSE handler and I can't figure how the close task is > > working. I thought the close task would be invoked when the client closes > > the connection but it doesn't seem to be the case. > > > > I slightly modified the example code to register a close task when a > > connection is initiated, here's the code : > > > > ServerSentEventConnectionCallback callback = new > > ServerSentEventConnectionCallback() { > > @Override > > public void connected(ServerSentEventConnection connection, String > > lastEventId) { > > System.out.println("adding close task on connection..."); > > connection.addCloseTask(channel -> System.out.println("goodbye cruel > > world...")); > > } > > }; > > final ServerSentEventHandler sseHandler = > > Handlers.serverSentEvents(callback); > > > > It appears to me that the close task is only invoked when the server > stops, > > but now when the client closes. Is it the expected behavior ? If so, is > > there any other way to be notified of a client disconnection ? > > > > Thanks a lot. > > > > Nel > > > > > > _______________________________________________ > > 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/20151123/60577821/attachment-0001.html From sdouglas at redhat.com Mon Nov 23 19:16:14 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 23 Nov 2015 19:16:14 -0500 (EST) Subject: [undertow-dev] SSE close task In-Reply-To: References: <463914263.12388092.1448261213712.JavaMail.zimbra@redhat.com> Message-ID: <45158945.13139085.1448324174194.JavaMail.zimbra@redhat.com> I have commented on the JIRA, but will include it here for anyone who is following: The close listener is called, however due to the nature of SSE and TCP this behavior is not super intuitive. Basically when the close() is called on the client side the client sends a FIN to the server, however as the server is not expecting any more data from the client this has no effect (in fact the client may have already sent a FIN if connection:close was sent). >From the servers point of view the socket is still functioning normally, up until the point where it attempts to send some data. When this happens the client will response with an RST. Unfortunately the server still has no idea that the socket is broken, as the RST arrives after the data has been sent (unless the data is very large). When the server attempts to send for the second time after the client has closed the connection it will receive an IOException from the RST, the connection will be closed and the listener invoked. If you want to detect this in a timely manner your only real option is some kind of heartbeat message, due to the way TCP and SSE work there is not really any other options. Stuart ----- Original Message ----- > From: "Nel Taurisson" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Tuesday, 24 November, 2015 8:31:35 AM > Subject: Re: [undertow-dev] SSE close task > > Ok, thanks, here's the JIRA with a failing test attached as a patch: > > https://issues.jboss.org/browse/UNDERTOW-589 > > Nel > > 2015-11-23 7:46 GMT+01:00 Stuart Douglas : > > > This sounds like a bug, can you file a JIRA? > > > > https://issues.jboss.org/projects/UNDERTOW > > > > Stuart > > > > ----- Original Message ----- > > > From: "Nel Taurisson" > > > To: undertow-dev at lists.jboss.org > > > Sent: Monday, 23 November, 2015 5:00:10 PM > > > Subject: [undertow-dev] SSE close task > > > > > > Hi, > > > > > > I'm playing with the SSE handler and I can't figure how the close task is > > > working. I thought the close task would be invoked when the client closes > > > the connection but it doesn't seem to be the case. > > > > > > I slightly modified the example code to register a close task when a > > > connection is initiated, here's the code : > > > > > > ServerSentEventConnectionCallback callback = new > > > ServerSentEventConnectionCallback() { > > > @Override > > > public void connected(ServerSentEventConnection connection, String > > > lastEventId) { > > > System.out.println("adding close task on connection..."); > > > connection.addCloseTask(channel -> System.out.println("goodbye cruel > > > world...")); > > > } > > > }; > > > final ServerSentEventHandler sseHandler = > > > Handlers.serverSentEvents(callback); > > > > > > It appears to me that the close task is only invoked when the server > > stops, > > > but now when the client closes. Is it the expected behavior ? If so, is > > > there any other way to be notified of a client disconnection ? > > > > > > Thanks a lot. > > > > > > Nel > > > > > > > > > _______________________________________________ > > > undertow-dev mailing list > > > undertow-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > From nel.taurisson at gmail.com Mon Nov 23 23:22:02 2015 From: nel.taurisson at gmail.com (Nel Taurisson) Date: Tue, 24 Nov 2015 05:22:02 +0100 Subject: [undertow-dev] SSE close task In-Reply-To: <45158945.13139085.1448324174194.JavaMail.zimbra@redhat.com> References: <463914263.12388092.1448261213712.JavaMail.zimbra@redhat.com> <45158945.13139085.1448324174194.JavaMail.zimbra@redhat.com> Message-ID: Ok, I understand : the only way to figure out that a client connection is closed is by sending a message as sending will eventually fail. Reading what your saying, even if the client is disconnected, the first attempt to send a message will not fail (from the server point of view), is this correct ? Does that mean that the server cannot fully determine that the client received a message ? Thanks Nel 2015-11-24 1:16 GMT+01:00 Stuart Douglas : > I have commented on the JIRA, but will include it here for anyone who is > following: > > The close listener is called, however due to the nature of SSE and TCP > this behavior is not super intuitive. > > Basically when the close() is called on the client side the client sends a > FIN to the server, however as the server is not expecting any more data > from the client this has no effect (in fact the client may have already > sent a FIN if connection:close was sent). > > From the servers point of view the socket is still functioning normally, > up until the point where it attempts to send some data. When this happens > the client will response with an RST. Unfortunately the server still has no > idea that the socket is broken, as the RST arrives after the data has been > sent (unless the data is very large). When the server attempts to send for > the second time after the client has closed the connection it will receive > an IOException from the RST, the connection will be closed and the listener > invoked. > > If you want to detect this in a timely manner your only real option is > some kind of heartbeat message, due to the way TCP and SSE work there is > not really any other options. > > > Stuart > > ----- Original Message ----- > > From: "Nel Taurisson" > > To: "Stuart Douglas" > > Cc: undertow-dev at lists.jboss.org > > Sent: Tuesday, 24 November, 2015 8:31:35 AM > > Subject: Re: [undertow-dev] SSE close task > > > > Ok, thanks, here's the JIRA with a failing test attached as a patch: > > > > https://issues.jboss.org/browse/UNDERTOW-589 > > > > Nel > > > > 2015-11-23 7:46 GMT+01:00 Stuart Douglas : > > > > > This sounds like a bug, can you file a JIRA? > > > > > > https://issues.jboss.org/projects/UNDERTOW > > > > > > Stuart > > > > > > ----- Original Message ----- > > > > From: "Nel Taurisson" > > > > To: undertow-dev at lists.jboss.org > > > > Sent: Monday, 23 November, 2015 5:00:10 PM > > > > Subject: [undertow-dev] SSE close task > > > > > > > > Hi, > > > > > > > > I'm playing with the SSE handler and I can't figure how the close > task is > > > > working. I thought the close task would be invoked when the client > closes > > > > the connection but it doesn't seem to be the case. > > > > > > > > I slightly modified the example code to register a close task when a > > > > connection is initiated, here's the code : > > > > > > > > ServerSentEventConnectionCallback callback = new > > > > ServerSentEventConnectionCallback() { > > > > @Override > > > > public void connected(ServerSentEventConnection connection, String > > > > lastEventId) { > > > > System.out.println("adding close task on connection..."); > > > > connection.addCloseTask(channel -> System.out.println("goodbye cruel > > > > world...")); > > > > } > > > > }; > > > > final ServerSentEventHandler sseHandler = > > > > Handlers.serverSentEvents(callback); > > > > > > > > It appears to me that the close task is only invoked when the server > > > stops, > > > > but now when the client closes. Is it the expected behavior ? If so, > is > > > > there any other way to be notified of a client disconnection ? > > > > > > > > Thanks a lot. > > > > > > > > Nel > > > > > > > > > > > > _______________________________________________ > > > > 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/20151124/9668df5f/attachment.html From sdouglas at redhat.com Mon Nov 23 23:46:56 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 23 Nov 2015 23:46:56 -0500 (EST) Subject: [undertow-dev] SSE close task In-Reply-To: References: <463914263.12388092.1448261213712.JavaMail.zimbra@redhat.com> <45158945.13139085.1448324174194.JavaMail.zimbra@redhat.com> Message-ID: <841432069.13202782.1448340416026.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Nel Taurisson" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Tuesday, 24 November, 2015 3:22:02 PM > Subject: Re: [undertow-dev] SSE close task > > Ok, I understand : the only way to figure out that a client connection is > closed is by sending a message as sending will eventually fail. > > Reading what your saying, even if the client is disconnected, the first > attempt to send a message will not fail (from the server point of view), is > this correct ? Generally no, depending on how the client closed the connection. If the client sends an RST immediately on close then the first write will fail. Otherwise the RST will not be sent till the client receives a message from the server, so from the servers point of view it is the second write that fails. > > Does that mean that the server cannot fully determine that the client > received a message ? No, but you are never going to get the sort of guarantee anyway, as the client could crash in between an sending an ACK and actually processing the data. Stuart > > Thanks > Nel > > > > 2015-11-24 1:16 GMT+01:00 Stuart Douglas : > > > I have commented on the JIRA, but will include it here for anyone who is > > following: > > > > The close listener is called, however due to the nature of SSE and TCP > > this behavior is not super intuitive. > > > > Basically when the close() is called on the client side the client sends a > > FIN to the server, however as the server is not expecting any more data > > from the client this has no effect (in fact the client may have already > > sent a FIN if connection:close was sent). > > > > From the servers point of view the socket is still functioning normally, > > up until the point where it attempts to send some data. When this happens > > the client will response with an RST. Unfortunately the server still has no > > idea that the socket is broken, as the RST arrives after the data has been > > sent (unless the data is very large). When the server attempts to send for > > the second time after the client has closed the connection it will receive > > an IOException from the RST, the connection will be closed and the listener > > invoked. > > > > If you want to detect this in a timely manner your only real option is > > some kind of heartbeat message, due to the way TCP and SSE work there is > > not really any other options. > > > > > > Stuart > > > > ----- Original Message ----- > > > From: "Nel Taurisson" > > > To: "Stuart Douglas" > > > Cc: undertow-dev at lists.jboss.org > > > Sent: Tuesday, 24 November, 2015 8:31:35 AM > > > Subject: Re: [undertow-dev] SSE close task > > > > > > Ok, thanks, here's the JIRA with a failing test attached as a patch: > > > > > > https://issues.jboss.org/browse/UNDERTOW-589 > > > > > > Nel > > > > > > 2015-11-23 7:46 GMT+01:00 Stuart Douglas : > > > > > > > This sounds like a bug, can you file a JIRA? > > > > > > > > https://issues.jboss.org/projects/UNDERTOW > > > > > > > > Stuart > > > > > > > > ----- Original Message ----- > > > > > From: "Nel Taurisson" > > > > > To: undertow-dev at lists.jboss.org > > > > > Sent: Monday, 23 November, 2015 5:00:10 PM > > > > > Subject: [undertow-dev] SSE close task > > > > > > > > > > Hi, > > > > > > > > > > I'm playing with the SSE handler and I can't figure how the close > > task is > > > > > working. I thought the close task would be invoked when the client > > closes > > > > > the connection but it doesn't seem to be the case. > > > > > > > > > > I slightly modified the example code to register a close task when a > > > > > connection is initiated, here's the code : > > > > > > > > > > ServerSentEventConnectionCallback callback = new > > > > > ServerSentEventConnectionCallback() { > > > > > @Override > > > > > public void connected(ServerSentEventConnection connection, String > > > > > lastEventId) { > > > > > System.out.println("adding close task on connection..."); > > > > > connection.addCloseTask(channel -> System.out.println("goodbye cruel > > > > > world...")); > > > > > } > > > > > }; > > > > > final ServerSentEventHandler sseHandler = > > > > > Handlers.serverSentEvents(callback); > > > > > > > > > > It appears to me that the close task is only invoked when the server > > > > stops, > > > > > but now when the client closes. Is it the expected behavior ? If so, > > is > > > > > there any other way to be notified of a client disconnection ? > > > > > > > > > > Thanks a lot. > > > > > > > > > > Nel > > > > > > > > > > > > > > > _______________________________________________ > > > > > undertow-dev mailing list > > > > > undertow-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > > > > > > > From nel.taurisson at gmail.com Tue Nov 24 00:08:14 2015 From: nel.taurisson at gmail.com (Nel Taurisson) Date: Tue, 24 Nov 2015 06:08:14 +0100 Subject: [undertow-dev] SSE close task In-Reply-To: <841432069.13202782.1448340416026.JavaMail.zimbra@redhat.com> References: <463914263.12388092.1448261213712.JavaMail.zimbra@redhat.com> <45158945.13139085.1448324174194.JavaMail.zimbra@redhat.com> <841432069.13202782.1448340416026.JavaMail.zimbra@redhat.com> Message-ID: Ok, thank you Nel 2015-11-24 5:46 GMT+01:00 Stuart Douglas : > > > ----- Original Message ----- > > From: "Nel Taurisson" > > To: "Stuart Douglas" > > Cc: undertow-dev at lists.jboss.org > > Sent: Tuesday, 24 November, 2015 3:22:02 PM > > Subject: Re: [undertow-dev] SSE close task > > > > Ok, I understand : the only way to figure out that a client connection is > > closed is by sending a message as sending will eventually fail. > > > > Reading what your saying, even if the client is disconnected, the first > > attempt to send a message will not fail (from the server point of view), > is > > this correct ? > > Generally no, depending on how the client closed the connection. If the > client sends an RST immediately on close then the first write will fail. > Otherwise the RST will not be sent till the client receives a message from > the server, so from the servers point of view it is the second write that > fails. > > > > > Does that mean that the server cannot fully determine that the client > > received a message ? > > No, but you are never going to get the sort of guarantee anyway, as the > client could crash in between an sending an ACK and actually processing the > data. > > Stuart > > > > > Thanks > > Nel > > > > > > > > 2015-11-24 1:16 GMT+01:00 Stuart Douglas : > > > > > I have commented on the JIRA, but will include it here for anyone who > is > > > following: > > > > > > The close listener is called, however due to the nature of SSE and TCP > > > this behavior is not super intuitive. > > > > > > Basically when the close() is called on the client side the client > sends a > > > FIN to the server, however as the server is not expecting any more data > > > from the client this has no effect (in fact the client may have already > > > sent a FIN if connection:close was sent). > > > > > > From the servers point of view the socket is still functioning > normally, > > > up until the point where it attempts to send some data. When this > happens > > > the client will response with an RST. Unfortunately the server still > has no > > > idea that the socket is broken, as the RST arrives after the data has > been > > > sent (unless the data is very large). When the server attempts to send > for > > > the second time after the client has closed the connection it will > receive > > > an IOException from the RST, the connection will be closed and the > listener > > > invoked. > > > > > > If you want to detect this in a timely manner your only real option is > > > some kind of heartbeat message, due to the way TCP and SSE work there > is > > > not really any other options. > > > > > > > > > Stuart > > > > > > ----- Original Message ----- > > > > From: "Nel Taurisson" > > > > To: "Stuart Douglas" > > > > Cc: undertow-dev at lists.jboss.org > > > > Sent: Tuesday, 24 November, 2015 8:31:35 AM > > > > Subject: Re: [undertow-dev] SSE close task > > > > > > > > Ok, thanks, here's the JIRA with a failing test attached as a patch: > > > > > > > > https://issues.jboss.org/browse/UNDERTOW-589 > > > > > > > > Nel > > > > > > > > 2015-11-23 7:46 GMT+01:00 Stuart Douglas : > > > > > > > > > This sounds like a bug, can you file a JIRA? > > > > > > > > > > https://issues.jboss.org/projects/UNDERTOW > > > > > > > > > > Stuart > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Nel Taurisson" > > > > > > To: undertow-dev at lists.jboss.org > > > > > > Sent: Monday, 23 November, 2015 5:00:10 PM > > > > > > Subject: [undertow-dev] SSE close task > > > > > > > > > > > > Hi, > > > > > > > > > > > > I'm playing with the SSE handler and I can't figure how the close > > > task is > > > > > > working. I thought the close task would be invoked when the > client > > > closes > > > > > > the connection but it doesn't seem to be the case. > > > > > > > > > > > > I slightly modified the example code to register a close task > when a > > > > > > connection is initiated, here's the code : > > > > > > > > > > > > ServerSentEventConnectionCallback callback = new > > > > > > ServerSentEventConnectionCallback() { > > > > > > @Override > > > > > > public void connected(ServerSentEventConnection connection, > String > > > > > > lastEventId) { > > > > > > System.out.println("adding close task on connection..."); > > > > > > connection.addCloseTask(channel -> System.out.println("goodbye > cruel > > > > > > world...")); > > > > > > } > > > > > > }; > > > > > > final ServerSentEventHandler sseHandler = > > > > > > Handlers.serverSentEvents(callback); > > > > > > > > > > > > It appears to me that the close task is only invoked when the > server > > > > > stops, > > > > > > but now when the client closes. Is it the expected behavior ? If > so, > > > is > > > > > > there any other way to be notified of a client disconnection ? > > > > > > > > > > > > Thanks a lot. > > > > > > > > > > > > Nel > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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/20151124/62a466d0/attachment-0001.html From me at bramp.net Wed Nov 25 00:13:03 2015 From: me at bramp.net (Andrew Brampton) Date: Tue, 24 Nov 2015 21:13:03 -0800 Subject: [undertow-dev] Undertow and non-blocking File IO Message-ID: I just started playing with Undertow, but I had a couple of questions about the use of non-blocking operations vs using the worker thread pool. In the ResourceHandler.java it appears to dispatch itself onto a worker thread, and then uses blocking file IO to actually read the file. I'm curious why a AsynchronousFileChannel wasn't used to read from the file in a non-blocking way? This would be in keeping with the non-blocking IO threads. I wrote a quick HttpHandler that used the AsynchronousFileChannel and it worked really well. However, when creating AsynchronousFileChannel you have to specify the ExecutorService to be used to schedule the completion handler callback on. I was able to use exchange.getIoThread().getWorker(), but I'm curious if there is a way to schedule it back on the IO Threads? It just seems "purer" keeping everything on a single IO thread per core. thanks Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151124/649ada98/attachment.html From sdouglas at redhat.com Wed Nov 25 16:27:42 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 25 Nov 2015 16:27:42 -0500 (EST) Subject: [undertow-dev] Undertow and non-blocking File IO In-Reply-To: References: Message-ID: <1393288337.14894380.1448486862356.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Andrew Brampton" > To: undertow-dev at lists.jboss.org > Sent: Wednesday, 25 November, 2015 4:13:03 PM > Subject: [undertow-dev] Undertow and non-blocking File IO > > I just started playing with Undertow, but I had a couple of questions about > the use of non-blocking operations vs using the worker thread pool. > > In the ResourceHandler.java it appears to dispatch itself onto a worker > thread, and then uses blocking file IO to actually read the file. I'm > curious why a AsynchronousFileChannel wasn't used to read from the file in a > non-blocking way? This would be in keeping with the non-blocking IO threads. This is something we should look at, however this only has an actual benefit on Windows AFAIK. Other platforms use SimpleAsynchronousFileChannelImpl which simply delegates to a thread pool. > > I wrote a quick HttpHandler that used the AsynchronousFileChannel and it > worked really well. However, when creating AsynchronousFileChannel you have > to specify the ExecutorService to be used to schedule the completion handler > callback on. I was able to use exchange.getIoThread().getWorker(), but I'm > curious if there is a way to schedule it back on the IO Threads? It just > seems "purer" keeping everything on a single IO thread per core. The IO threads implement Executor not ExecutorService, you could write a wrapper, but if you used it on non Windows platforms you would block the IO thread. Stuart > > thanks > Andrew > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From jason.greene at redhat.com Wed Nov 25 16:50:58 2015 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 25 Nov 2015 15:50:58 -0600 Subject: [undertow-dev] Undertow and non-blocking File IO In-Reply-To: <1393288337.14894380.1448486862356.JavaMail.zimbra@redhat.com> References: <1393288337.14894380.1448486862356.JavaMail.zimbra@redhat.com> Message-ID: <1095EDC2-B3C8-4603-BC03-9D66B01FB86F@redhat.com> > On Nov 25, 2015, at 3:27 PM, Stuart Douglas wrote: > > > > ----- Original Message ----- >> From: "Andrew Brampton" >> To: undertow-dev at lists.jboss.org >> Sent: Wednesday, 25 November, 2015 4:13:03 PM >> Subject: [undertow-dev] Undertow and non-blocking File IO >> >> I just started playing with Undertow, but I had a couple of questions about >> the use of non-blocking operations vs using the worker thread pool. >> >> In the ResourceHandler.java it appears to dispatch itself onto a worker >> thread, and then uses blocking file IO to actually read the file. I'm >> curious why a AsynchronousFileChannel wasn't used to read from the file in a >> non-blocking way? This would be in keeping with the non-blocking IO threads. > > This is something we should look at, however this only has an actual benefit on Windows AFAIK. Other platforms use SimpleAsynchronousFileChannelImpl which simply delegates to a thread pool. The major issue that prevents this is that Linux filesystems (in combination with the kernel) can sometimes block in io_submit (e.g. during certain metadata operations). You also have to open a file aligned and in O_DIRECT which Java NIO does not support. If you look at what the glibc impl does, it actually ends up creating a thread pool of its own. > >> >> I wrote a quick HttpHandler that used the AsynchronousFileChannel and it >> worked really well. However, when creating AsynchronousFileChannel you have >> to specify the ExecutorService to be used to schedule the completion handler >> callback on. I was able to use exchange.getIoThread().getWorker(), but I'm >> curious if there is a way to schedule it back on the IO Threads? It just >> seems "purer" keeping everything on a single IO thread per core. > > The IO threads implement Executor not ExecutorService, you could write a wrapper, but if you used it on non Windows platforms you would block the IO thread. > > Stuart > >> >> thanks >> Andrew >> >> _______________________________________________ >> 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 me at bramp.net Wed Nov 25 17:53:15 2015 From: me at bramp.net (Andrew Brampton) Date: Wed, 25 Nov 2015 14:53:15 -0800 Subject: [undertow-dev] Undertow and non-blocking File IO In-Reply-To: <1095EDC2-B3C8-4603-BC03-9D66B01FB86F@redhat.com> References: <1393288337.14894380.1448486862356.JavaMail.zimbra@redhat.com> <1095EDC2-B3C8-4603-BC03-9D66B01FB86F@redhat.com> Message-ID: Thanks all, my mind is blown that the async file IO is actually using threads under the hood. I just spent a little while reading through the SimpleAsynchronousFileChannelImpl source code, as well as reading up on Linux's AIO. Thanks Andrew On 25 November 2015 at 13:50, Jason Greene wrote: > > > On Nov 25, 2015, at 3:27 PM, Stuart Douglas wrote: > > > > > > > > ----- Original Message ----- > >> From: "Andrew Brampton" > >> To: undertow-dev at lists.jboss.org > >> Sent: Wednesday, 25 November, 2015 4:13:03 PM > >> Subject: [undertow-dev] Undertow and non-blocking File IO > >> > >> I just started playing with Undertow, but I had a couple of questions > about > >> the use of non-blocking operations vs using the worker thread pool. > >> > >> In the ResourceHandler.java it appears to dispatch itself onto a worker > >> thread, and then uses blocking file IO to actually read the file. I'm > >> curious why a AsynchronousFileChannel wasn't used to read from the file > in a > >> non-blocking way? This would be in keeping with the non-blocking IO > threads. > > > > This is something we should look at, however this only has an actual > benefit on Windows AFAIK. Other platforms use > SimpleAsynchronousFileChannelImpl which simply delegates to a thread pool. > > The major issue that prevents this is that Linux filesystems (in > combination with the kernel) can sometimes block in io_submit (e.g. during > certain metadata operations). You also have to open a file aligned and in > O_DIRECT which Java NIO does not support. If you look at what the glibc > impl does, it actually ends up creating a thread pool of its own. > > > >> > >> I wrote a quick HttpHandler that used the AsynchronousFileChannel and it > >> worked really well. However, when creating AsynchronousFileChannel you > have > >> to specify the ExecutorService to be used to schedule the completion > handler > >> callback on. I was able to use exchange.getIoThread().getWorker(), but > I'm > >> curious if there is a way to schedule it back on the IO Threads? It just > >> seems "purer" keeping everything on a single IO thread per core. > > > > The IO threads implement Executor not ExecutorService, you could write a > wrapper, but if you used it on non Windows platforms you would block the IO > thread. > > > > Stuart > > > >> > >> thanks > >> Andrew > >> > >> _______________________________________________ > >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151125/a7b93eb9/attachment.html