From shanloid at gmail.com Tue Sep 2 19:33:24 2014 From: shanloid at gmail.com (Shannon Lloyd) Date: Wed, 3 Sep 2014 09:33:24 +1000 Subject: [undertow-dev] Checking if an exchange has been dispatched Message-ID: Hi, If I dispatch an exchange within a handler, and later confirm that it is being executed by one of the "task" threads, should I expect exchange.isDispatched() to return true? Because I'm not seeing this behaviour (using 1.0.15.Final). If I pause execution in the debugger, I can see that the executing thread is XNIO-1 task-1, but exchange.isDispatched() returns false. If it helps, exchange.state == 151752. Does isDispatched() not mean what I think it means (i.e. that execution has actually commenced via the task pool)? Thanks, Shannon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140903/d0cdcde6/attachment.html From sdouglas at redhat.com Tue Sep 2 20:53:15 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 03 Sep 2014 10:53:15 +1000 Subject: [undertow-dev] Checking if an exchange has been dispatched In-Reply-To: References: Message-ID: <5406667B.7050806@redhat.com> isDispatched() will only return true if a dispatch is going to happen when the call stack returns. So when you are in the IO thread and call the dispatch() method from that point on isDispatched() will be true, however as soon as the call stack returns and the dispatch happens this goes back to false (as it is possible to dispatch multiple times). The check you are probably looking for is exchange.isInIoThread(), which will return true if the current thread is the IO thread. Stuart Shannon Lloyd wrote: > Hi, > > If I dispatch an exchange within a handler, and later confirm that it is > being executed by one of the "task" threads, should I expect > exchange.isDispatched() to return true? > > Because I'm not seeing this behaviour (using 1.0.15.Final). If I pause > execution in the debugger, I can see that the executing thread is XNIO-1 > task-1, but exchange.isDispatched() returns false. If it helps, > exchange.state == 151752. > > Does isDispatched() not mean what I think it means (i.e. that execution > has actually commenced via the task pool)? > > Thanks, > Shannon > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From Andrew.Schmidt at impactmobile.com Thu Sep 4 10:59:06 2014 From: Andrew.Schmidt at impactmobile.com (Andrew Schmidt) Date: Thu, 4 Sep 2014 14:59:06 +0000 Subject: [undertow-dev] InMemorySessionManager.java performance Message-ID: My company is currently switching from jboss 4 => wildfly 8.1, jsf + hibernate + richfaces. (We develop on Windows) After profiling our application, I've found some major performance penalties in the InMemorySessionManager.java in undertow. Specifically in the bumpTimeout() that gets called on every getAttribute call. Each of these calls takes 15 ms, which when called 100 times during the course of a jsf request, adds up. (The 15 ms occurs when the execute.executeAfter in netty tries to wake up another thread) Looking over the code: io/undertow/server/session/InMemorySessionManager.java -- snip synchronized void bumpTimeout() { final int maxInactiveInterval = getMaxInactiveInterval(); if (maxInactiveInterval > 0) { long newExpireTime = System.currentTimeMillis() + (maxInactiveInterval * 1000); if(timerCancelKey != null && (newExpireTime < expireTime)) { // We have to re-schedule as the new maxInactiveInterval is lower than the old one if (!timerCancelKey.remove()) { return; } timerCancelKey = null; } expireTime = newExpireTime; if(timerCancelKey == null) { //+1 second, to make sure that the time has actually expired //we don't re-schedule every time, as it is expensive //instead when it expires we check if the timeout has been bumped, and if so we re-schedule timerCancelKey = executor.executeAfter(cancelTask, maxInactiveInterval + 1, TimeUnit.SECONDS); -- snip If the time changes by 1ms, then the expiration task is cancelled and a new one is scheduled. But this new scheduling takes 15ms. Therefore every call to getAttribute (which in turn calls bumpTimeout) will constantly cancel and reschedule the expiration tasks. This seems heavy handed. Also the comment seems to imply that the developer who wrote this was aware that rescheduling is expensive, yet it happens on every call. Disabling session expiration causes our application to run twice as fast. (5.5 second page load goes down to 2.5) From Andrew.Schmidt at impactmobile.com Thu Sep 4 11:11:15 2014 From: Andrew.Schmidt at impactmobile.com (Andrew Schmidt) Date: Thu, 4 Sep 2014 15:11:15 +0000 Subject: [undertow-dev] InMemorySessionManager.java performance In-Reply-To: References: Message-ID: It appears to be this changeset that caused the performance degradation: https://github.com/undertow-io/undertow/commit/636590a011ad8497286ef01f19dc9551a16eef79 > -----Original Message----- > From: undertow-dev-bounces at lists.jboss.org [mailto:undertow-dev- > bounces at lists.jboss.org] On Behalf Of Andrew Schmidt > Sent: September-04-2014 10:59 AM > To: undertow-dev at lists.jboss.org > Subject: [undertow-dev] InMemorySessionManager.java performance > > My company is currently switching from jboss 4 => wildfly 8.1, jsf + > hibernate + richfaces. (We develop on Windows) > > After profiling our application, I've found some major performance penalties > in the InMemorySessionManager.java in undertow. Specifically in the > bumpTimeout() that gets called on every getAttribute call. Each of these calls > takes 15 ms, which when called 100 times during the course of a jsf request, > adds up. (The 15 ms occurs when the execute.executeAfter in netty tries to > wake up another thread) > > Looking over the code: > io/undertow/server/session/InMemorySessionManager.java > > -- snip > synchronized void bumpTimeout() { > final int maxInactiveInterval = getMaxInactiveInterval(); > if (maxInactiveInterval > 0) { > long newExpireTime = System.currentTimeMillis() + > (maxInactiveInterval * 1000); > if(timerCancelKey != null && (newExpireTime < expireTime)) { > // We have to re-schedule as the new maxInactiveInterval is lower > than the old one > if (!timerCancelKey.remove()) { > return; > } > timerCancelKey = null; > } > expireTime = newExpireTime; > if(timerCancelKey == null) { > //+1 second, to make sure that the time has actually expired > //we don't re-schedule every time, as it is expensive > //instead when it expires we check if the timeout has been > bumped, and if so we re-schedule > timerCancelKey = executor.executeAfter(cancelTask, > maxInactiveInterval + 1, TimeUnit.SECONDS); > -- snip > > If the time changes by 1ms, then the expiration task is cancelled and a new > one is scheduled. But this new scheduling takes 15ms. Therefore every call > to getAttribute (which in turn calls bumpTimeout) will constantly cancel and > reschedule the expiration tasks. This seems heavy handed. Also the > comment seems to imply that the developer who wrote this was aware that > rescheduling is expensive, yet it happens on every call. > > Disabling session expiration causes our application to run twice as fast. (5.5 > second page load goes down to 2.5) > > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From rob.nikander at gmail.com Thu Sep 4 17:00:23 2014 From: rob.nikander at gmail.com (Robert Nikander) Date: Thu, 4 Sep 2014 17:00:23 -0400 Subject: [undertow-dev] war+web.xml? Message-ID: <4E2FC047-BAFA-441C-ABEB-248CD5587798@gmail.com> Hi, I see the servlet example here: http://undertow.io/documentation/servlet/deployment.html. Am I correct this servlet package does not parse any web.xml files, so if I want to take an existing war and deploy it in undertow, I would need to translate the web.xml to this builder API? thanks, Rob From sdouglas at redhat.com Thu Sep 4 23:27:10 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 05 Sep 2014 13:27:10 +1000 Subject: [undertow-dev] InMemorySessionManager.java performance In-Reply-To: References: Message-ID: <54092D8E.40706@redhat.com> This seems really odd. This should only be re-scheduled if the condition newExpireTime < expireTime is true, which should only happen if the max inactive interval has been decreased. I have tested this out locally and it seems to be working as expected (i.e. only one executeAfter call). Do you have a simple way to reproduce this? Stuart Andrew Schmidt wrote: > My company is currently switching from jboss 4 => wildfly 8.1, jsf + hibernate + richfaces. (We develop on Windows) > > After profiling our application, I've found some major performance penalties in the InMemorySessionManager.java in undertow. Specifically in the bumpTimeout() that gets called on every getAttribute call. Each of these calls takes 15 ms, which when called 100 times during the course of a jsf request, adds up. (The 15 ms occurs when the execute.executeAfter in netty tries to wake up another thread) > > Looking over the code: > io/undertow/server/session/InMemorySessionManager.java > > -- snip > synchronized void bumpTimeout() { > final int maxInactiveInterval = getMaxInactiveInterval(); > if (maxInactiveInterval> 0) { > long newExpireTime = System.currentTimeMillis() + (maxInactiveInterval * 1000); > if(timerCancelKey != null&& (newExpireTime< expireTime)) { > // We have to re-schedule as the new maxInactiveInterval is lower than the old one > if (!timerCancelKey.remove()) { > return; > } > timerCancelKey = null; > } > expireTime = newExpireTime; > if(timerCancelKey == null) { > //+1 second, to make sure that the time has actually expired > //we don't re-schedule every time, as it is expensive > //instead when it expires we check if the timeout has been bumped, and if so we re-schedule > timerCancelKey = executor.executeAfter(cancelTask, maxInactiveInterval + 1, TimeUnit.SECONDS); > -- snip > > If the time changes by 1ms, then the expiration task is cancelled and a new one is scheduled. But this new scheduling takes 15ms. Therefore every call to getAttribute (which in turn calls bumpTimeout) will constantly cancel and reschedule the expiration tasks. This seems heavy handed. Also the comment seems to imply that the developer who wrote this was aware that rescheduling is expensive, yet it happens on every call. > > Disabling session expiration causes our application to run twice as fast. (5.5 second page load goes down to 2.5) > > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Thu Sep 4 23:30:27 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 05 Sep 2014 13:30:27 +1000 Subject: [undertow-dev] war+web.xml? In-Reply-To: <4E2FC047-BAFA-441C-ABEB-248CD5587798@gmail.com> References: <4E2FC047-BAFA-441C-ABEB-248CD5587798@gmail.com> Message-ID: <54092E53.80909@redhat.com> Yes, the web and annotation parsing code all lives in Wildfly, rather than Undertow. In the near future we should be releasing a cut down version of Wildfly which basically just contains Undertow, that will allow you to deploy war files directly. At some point we may also provide some glue code for Undertow to do this parsing so it can deploy war files directly, however it is not a high priority (although if you wanted to have a go at this most of the code already exists, in the JBoss Metadata and Wildfly code base). Stuart Robert Nikander wrote: > Hi, > > I see the servlet example here: http://undertow.io/documentation/servlet/deployment.html. > > Am I correct this servlet package does not parse any web.xml files, so if I want to take an existing war and deploy it in undertow, I would need to translate the web.xml to this builder API? > > thanks, > Rob > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From vworld4u at gmail.com Fri Sep 5 00:30:03 2014 From: vworld4u at gmail.com (Venkatesha T R) Date: Fri, 5 Sep 2014 10:00:03 +0530 Subject: [undertow-dev] Does ClassPathResourceManager work to serve a html file which is inside a packaged jar Message-ID: Hi, I am seeing this behavior in undertow - I have written a simple web application using undertow which processes 3 requests and provides a single (may be two in future) page (s) to see. These pages are just html pages and 3 requests are GET/POST requests. I am using ClassPathResourceManager class to serve the index.html file which is present inside classpath in one of my package (I am using a maven project). It works fine when I run this application in the Eclipse environment (where there is no jar used for running). But when I package this application as a jar file and run it in standalone mode, ClassPathResourceManager fails to pick the resource and serve it. ClassPathResourceManager reports Resource instance, but I see a blank page (404) error when I see it in browser. If somebody has any clue about what is going on, or knows about this possible bug, please let me know. It will help me a lot. Thanks in advance.. -- *Thanks and Regards* *--------------------------------------------------------------------------------------------------------------------* *Venkatesh T R* *9945040858* A Man with Many Dimensions... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140905/cebd9095/attachment.html From bill at dartalley.com Fri Sep 5 00:56:46 2014 From: bill at dartalley.com (Bill O'Neil) Date: Fri, 5 Sep 2014 00:56:46 -0400 Subject: [undertow-dev] Does ClassPathResourceManager work to serve a html file which is inside a packaged jar In-Reply-To: References: Message-ID: Could you provide a little more info. 1. Are the html pages in a non standard location that may not be added to the class path in the jar? 2. Are you setting a resource base path? I just tested serving files from an executable jar and it works as expected for me. On Fri, Sep 5, 2014 at 12:30 AM, Venkatesha T R wrote: > Hi, > > I am seeing this behavior in undertow - I have written a simple web > application using undertow which processes 3 requests and provides a single > (may be two in future) page (s) to see. These pages are just html pages and > 3 requests are GET/POST requests. I am using ClassPathResourceManager class > to serve the index.html file which is present inside classpath in one of my > package (I am using a maven project). It works fine when I run this > application in the Eclipse environment (where there is no jar used for > running). But when I package this application as a jar file and run it in > standalone mode, ClassPathResourceManager fails to pick the resource and > serve it. > > ClassPathResourceManager reports Resource instance, but I see a blank page > (404) error when I see it in browser. If somebody has any clue about what > is going on, or knows about this possible bug, please let me know. It will > help me a lot. > > Thanks in advance.. > > -- > > *Thanks and Regards* > > *--------------------------------------------------------------------------------------------------------------------* > *Venkatesh T R* > *9945040858* > A Man with Many Dimensions... > > > _______________________________________________ > 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/20140905/96f3cb18/attachment.html From tomaz.cerar at gmail.com Fri Sep 5 05:50:40 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 5 Sep 2014 11:50:40 +0200 Subject: [undertow-dev] Does ClassPathResourceManager work to serve a html file which is inside a packaged jar In-Reply-To: References: Message-ID: Maybe problem is that you are not properly packaging resources in your jar. For maven project that should be in main/java/resources (standard jar module type) otherwise you can easily add any custom path as resource that will be packed into your war. In short, open the resulting jar and see if resources are there. On Fri, Sep 5, 2014 at 6:56 AM, Bill O'Neil wrote: > Could you provide a little more info. > > 1. Are the html pages in a non standard location that may not be added to > the class path in the jar? > 2. Are you setting a resource base path? > > I just tested serving files from an executable jar and it works as > expected for me. > > > On Fri, Sep 5, 2014 at 12:30 AM, Venkatesha T R > wrote: > >> Hi, >> >> I am seeing this behavior in undertow - I have written a simple web >> application using undertow which processes 3 requests and provides a single >> (may be two in future) page (s) to see. These pages are just html pages and >> 3 requests are GET/POST requests. I am using ClassPathResourceManager class >> to serve the index.html file which is present inside classpath in one of my >> package (I am using a maven project). It works fine when I run this >> application in the Eclipse environment (where there is no jar used for >> running). But when I package this application as a jar file and run it in >> standalone mode, ClassPathResourceManager fails to pick the resource and >> serve it. >> >> ClassPathResourceManager reports Resource instance, but I see a blank >> page (404) error when I see it in browser. If somebody has any clue about >> what is going on, or knows about this possible bug, please let me know. It >> will help me a lot. >> >> Thanks in advance.. >> >> -- >> >> *Thanks and Regards* >> >> *--------------------------------------------------------------------------------------------------------------------* >> *Venkatesh T R* >> *9945040858* >> A Man with Many Dimensions... >> >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140905/b2c4c79a/attachment.html From vworld4u at gmail.com Fri Sep 5 05:52:44 2014 From: vworld4u at gmail.com (Venkatesha T R) Date: Fri, 5 Sep 2014 15:22:44 +0530 Subject: [undertow-dev] Does ClassPathResourceManager work to serve a html file which is inside a packaged jar In-Reply-To: References: Message-ID: Hi Tomaz, I have seen and confirmed that resources are present in right packages inside the packaged jar. But I am not able to get the resource served! :( Thanks, Venkatesha T R On Fri, Sep 5, 2014 at 3:20 PM, Toma? Cerar wrote: > Maybe problem is that you are not properly packaging resources in your jar. > For maven project that should be in main/java/resources (standard jar > module type) > otherwise you can easily add any custom path as resource that will be > packed into your war. > > In short, open the resulting jar and see if resources are there. > > > On Fri, Sep 5, 2014 at 6:56 AM, Bill O'Neil wrote: > >> Could you provide a little more info. >> >> 1. Are the html pages in a non standard location that may not be added to >> the class path in the jar? >> 2. Are you setting a resource base path? >> >> I just tested serving files from an executable jar and it works as >> expected for me. >> >> >> On Fri, Sep 5, 2014 at 12:30 AM, Venkatesha T R >> wrote: >> >>> Hi, >>> >>> I am seeing this behavior in undertow - I have written a simple web >>> application using undertow which processes 3 requests and provides a single >>> (may be two in future) page (s) to see. These pages are just html pages and >>> 3 requests are GET/POST requests. I am using ClassPathResourceManager class >>> to serve the index.html file which is present inside classpath in one of my >>> package (I am using a maven project). It works fine when I run this >>> application in the Eclipse environment (where there is no jar used for >>> running). But when I package this application as a jar file and run it in >>> standalone mode, ClassPathResourceManager fails to pick the resource and >>> serve it. >>> >>> ClassPathResourceManager reports Resource instance, but I see a blank >>> page (404) error when I see it in browser. If somebody has any clue about >>> what is going on, or knows about this possible bug, please let me know. It >>> will help me a lot. >>> >>> Thanks in advance.. >>> >>> -- >>> >>> *Thanks and Regards* >>> >>> *--------------------------------------------------------------------------------------------------------------------* >>> *Venkatesh T R* >>> *9945040858* >>> A Man with Many Dimensions... >>> >>> >>> _______________________________________________ >>> 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 >> > > -- *Thanks and Regards* *--------------------------------------------------------------------------------------------------------------------* *Venkatesh T R* *9945040858* A Man with Many Dimensions... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140905/97a1fb02/attachment.html From tomaz.cerar at gmail.com Fri Sep 5 06:24:04 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 5 Sep 2014 12:24:04 +0200 Subject: [undertow-dev] Does ClassPathResourceManager work to serve a html file which is inside a packaged jar In-Reply-To: References: Message-ID: So show as the code that you use to setup ClassPAthResourceManager also some locations of classes / resources would be welcome. On Fri, Sep 5, 2014 at 11:52 AM, Venkatesha T R wrote: > Hi Tomaz, > > I have seen and confirmed that resources are present in right packages > inside the packaged jar. But I am not able to get the resource served! :( > > Thanks, > Venkatesha T R > > > On Fri, Sep 5, 2014 at 3:20 PM, Toma? Cerar wrote: > >> Maybe problem is that you are not properly packaging resources in your >> jar. >> For maven project that should be in main/java/resources (standard jar >> module type) >> otherwise you can easily add any custom path as resource that will be >> packed into your war. >> >> In short, open the resulting jar and see if resources are there. >> >> >> On Fri, Sep 5, 2014 at 6:56 AM, Bill O'Neil wrote: >> >>> Could you provide a little more info. >>> >>> 1. Are the html pages in a non standard location that may not be added >>> to the class path in the jar? >>> 2. Are you setting a resource base path? >>> >>> I just tested serving files from an executable jar and it works as >>> expected for me. >>> >>> >>> On Fri, Sep 5, 2014 at 12:30 AM, Venkatesha T R >>> wrote: >>> >>>> Hi, >>>> >>>> I am seeing this behavior in undertow - I have written a simple web >>>> application using undertow which processes 3 requests and provides a single >>>> (may be two in future) page (s) to see. These pages are just html pages and >>>> 3 requests are GET/POST requests. I am using ClassPathResourceManager class >>>> to serve the index.html file which is present inside classpath in one of my >>>> package (I am using a maven project). It works fine when I run this >>>> application in the Eclipse environment (where there is no jar used for >>>> running). But when I package this application as a jar file and run it in >>>> standalone mode, ClassPathResourceManager fails to pick the resource and >>>> serve it. >>>> >>>> ClassPathResourceManager reports Resource instance, but I see a blank >>>> page (404) error when I see it in browser. If somebody has any clue about >>>> what is going on, or knows about this possible bug, please let me know. It >>>> will help me a lot. >>>> >>>> Thanks in advance.. >>>> >>>> -- >>>> >>>> *Thanks and Regards* >>>> >>>> *--------------------------------------------------------------------------------------------------------------------* >>>> *Venkatesh T R* >>>> *9945040858* >>>> A Man with Many Dimensions... >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> > > > -- > > *Thanks and Regards* > > *--------------------------------------------------------------------------------------------------------------------* > *Venkatesh T R* > *9945040858* > A Man with Many Dimensions... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140905/a4e444c5/attachment-0001.html From vworld4u at gmail.com Fri Sep 5 06:25:19 2014 From: vworld4u at gmail.com (Venkatesha T R) Date: Fri, 5 Sep 2014 15:55:19 +0530 Subject: [undertow-dev] Does ClassPathResourceManager work to serve a html file which is inside a packaged jar In-Reply-To: References: Message-ID: Hi Tomaz, I have the following structure in my maven project Classes are in src/main/java folder in the package com.xxx.yyy.zzz and the html is there inside the src/main/resources folder inside the folder com/xxx/yyy/zzz folder itself. I have checked the jar file also in which the html is packaged into correct classpath too. I am using the following code to set the Resource path : ClassPathResourceManager resourceManager = new ClassPathResourceManager(MyUndertowServer.class.getClassLoader(), MyUndertowServer.class.getPackage()); // MyUndertowServer is in same com.xxx.yyy.zzz path then I am creating ResourceHandler resourceHandler = Handlers.resource(resourceManager).addWelcomeFiles("index.html").setDirectoryListingEnabled(true); & then finally adding deploymentInfo.setResourceManager(resourceManager); Can you please figure out whether I am doing something wrong above? Please paste a sample working code for this part so that I can check it out. Thanks a lot for your patience and time On Fri, Sep 5, 2014 at 3:54 PM, Toma? Cerar wrote: > So show as the code that you use to setup ClassPAthResourceManager > also some locations of classes / resources would be welcome. > > > On Fri, Sep 5, 2014 at 11:52 AM, Venkatesha T R > wrote: > >> Hi Tomaz, >> >> I have seen and confirmed that resources are present in right packages >> inside the packaged jar. But I am not able to get the resource served! :( >> >> Thanks, >> Venkatesha T R >> >> >> On Fri, Sep 5, 2014 at 3:20 PM, Toma? Cerar >> wrote: >> >>> Maybe problem is that you are not properly packaging resources in your >>> jar. >>> For maven project that should be in main/java/resources (standard jar >>> module type) >>> otherwise you can easily add any custom path as resource that will be >>> packed into your war. >>> >>> In short, open the resulting jar and see if resources are there. >>> >>> >>> On Fri, Sep 5, 2014 at 6:56 AM, Bill O'Neil wrote: >>> >>>> Could you provide a little more info. >>>> >>>> 1. Are the html pages in a non standard location that may not be added >>>> to the class path in the jar? >>>> 2. Are you setting a resource base path? >>>> >>>> I just tested serving files from an executable jar and it works as >>>> expected for me. >>>> >>>> >>>> On Fri, Sep 5, 2014 at 12:30 AM, Venkatesha T R >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I am seeing this behavior in undertow - I have written a simple web >>>>> application using undertow which processes 3 requests and provides a single >>>>> (may be two in future) page (s) to see. These pages are just html pages and >>>>> 3 requests are GET/POST requests. I am using ClassPathResourceManager class >>>>> to serve the index.html file which is present inside classpath in one of my >>>>> package (I am using a maven project). It works fine when I run this >>>>> application in the Eclipse environment (where there is no jar used for >>>>> running). But when I package this application as a jar file and run it in >>>>> standalone mode, ClassPathResourceManager fails to pick the resource and >>>>> serve it. >>>>> >>>>> ClassPathResourceManager reports Resource instance, but I see a blank >>>>> page (404) error when I see it in browser. If somebody has any clue about >>>>> what is going on, or knows about this possible bug, please let me know. It >>>>> will help me a lot. >>>>> >>>>> Thanks in advance.. >>>>> >>>>> -- >>>>> >>>>> *Thanks and Regards* >>>>> >>>>> *--------------------------------------------------------------------------------------------------------------------* >>>>> *Venkatesh T R* >>>>> *9945040858* >>>>> A Man with Many Dimensions... >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >> >> >> -- >> >> *Thanks and Regards* >> >> *--------------------------------------------------------------------------------------------------------------------* >> *Venkatesh T R* >> *9945040858* >> A Man with Many Dimensions... >> >> > -- *Thanks and Regards* *--------------------------------------------------------------------------------------------------------------------* *Venkatesh T R* *9945040858* A Man with Many Dimensions... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140905/a4fc6a58/attachment.html From Andrew.Schmidt at impactmobile.com Fri Sep 5 10:55:16 2014 From: Andrew.Schmidt at impactmobile.com (Andrew Schmidt) Date: Fri, 5 Sep 2014 14:55:16 +0000 Subject: [undertow-dev] InMemorySessionManager.java performance In-Reply-To: <54092D8E.40706@redhat.com> References: <54092D8E.40706@redhat.com> Message-ID: Well on windows, scheduling a new task takes more than 1 ms. Therefore every call to bumptimeout cause the next bumpTimeout to reschedule. (Since the ''if(newExpireTime < expireTime)'' is comparing ms) I'm going to test this out on linux and determine if if the same problem exists. Are you testing on linux ? But even still, over the course of a jsf request, which takes anywhere from 100ms to 1second, there could be upwards of 100 getAttribute calls which would be on different ms's. And that means 100+ cancel's / reschedule's . > -----Original Message----- > From: Stuart Douglas [mailto:sdouglas at redhat.com] > Sent: September-04-2014 11:27 PM > To: Andrew Schmidt > Cc: undertow-dev at lists.jboss.org > Subject: Re: [undertow-dev] InMemorySessionManager.java performance > > This seems really odd. This should only be re-scheduled if the condition > newExpireTime < expireTime is true, which should only happen if the max > inactive interval has been decreased. I have tested this out locally and it > seems to be working as expected (i.e. only one executeAfter call). > > Do you have a simple way to reproduce this? > > Stuart > > Andrew Schmidt wrote: > > My company is currently switching from jboss 4 => wildfly 8.1, jsf + > hibernate + richfaces. (We develop on Windows) > > > > After profiling our application, I've found some major performance > penalties in the InMemorySessionManager.java in undertow. Specifically in > the bumpTimeout() that gets called on every getAttribute call. Each of these > calls takes 15 ms, which when called 100 times during the course of a jsf > request, adds up. (The 15 ms occurs when the execute.executeAfter in > netty tries to wake up another thread) > > > > Looking over the code: > > io/undertow/server/session/InMemorySessionManager.java > > > > -- snip > > synchronized void bumpTimeout() { > > final int maxInactiveInterval = getMaxInactiveInterval(); > > if (maxInactiveInterval> 0) { > > long newExpireTime = System.currentTimeMillis() + > (maxInactiveInterval * 1000); > > if(timerCancelKey != null&& (newExpireTime< expireTime)) { > > // We have to re-schedule as the new maxInactiveInterval is > lower than the old one > > if (!timerCancelKey.remove()) { > > return; > > } > > timerCancelKey = null; > > } > > expireTime = newExpireTime; > > if(timerCancelKey == null) { > > //+1 second, to make sure that the time has actually expired > > //we don't re-schedule every time, as it is expensive > > //instead when it expires we check if the timeout has been > bumped, and if so we re-schedule > > timerCancelKey = > > executor.executeAfter(cancelTask, maxInactiveInterval + 1, > > TimeUnit.SECONDS); > > -- snip > > > > If the time changes by 1ms, then the expiration task is cancelled and a new > one is scheduled. But this new scheduling takes 15ms. Therefore every call > to getAttribute (which in turn calls bumpTimeout) will constantly cancel and > reschedule the expiration tasks. This seems heavy handed. Also the > comment seems to imply that the developer who wrote this was aware that > rescheduling is expensive, yet it happens on every call. > > > > Disabling session expiration causes our application to run twice as > > fast. (5.5 second page load goes down to 2.5) > > > > > > > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Fri Sep 5 17:08:35 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Sat, 06 Sep 2014 07:08:35 +1000 Subject: [undertow-dev] InMemorySessionManager.java performance In-Reply-To: References: <54092D8E.40706@redhat.com> Message-ID: <540A2653.8090506@redhat.com> Andrew Schmidt wrote: > Well on windows, scheduling a new task takes more than 1 ms. Therefore every call > to bumptimeout cause the next bumpTimeout to reschedule. > (Since the ''if(newExpireTime< expireTime)'' is comparing ms) newExpireTime and expireTime are both calculated before the task is scheduled, so it should not matter how long the scheduling takes. I still can't see the problem with the logic. System.currentTimeMillis() should always increase or stay the same, so newExpireTime should always be larger than or equal to expireTime. Stuart > > I'm going to test this out on linux and determine if if the same problem exists. Are you > testing on linux ? > > But even still, over the course of a jsf request, which takes anywhere from 100ms to > 1second, there could be upwards of 100 getAttribute calls which would be on > different ms's. And that means 100+ cancel's / reschedule's . > > >> -----Original Message----- >> From: Stuart Douglas [mailto:sdouglas at redhat.com] >> Sent: September-04-2014 11:27 PM >> To: Andrew Schmidt >> Cc: undertow-dev at lists.jboss.org >> Subject: Re: [undertow-dev] InMemorySessionManager.java performance >> >> This seems really odd. This should only be re-scheduled if the condition >> newExpireTime< expireTime is true, which should only happen if the max >> inactive interval has been decreased. I have tested this out locally and it >> seems to be working as expected (i.e. only one executeAfter call). >> >> Do you have a simple way to reproduce this? >> >> Stuart >> >> Andrew Schmidt wrote: >>> My company is currently switching from jboss 4 => wildfly 8.1, jsf + >> hibernate + richfaces. (We develop on Windows) >>> After profiling our application, I've found some major performance >> penalties in the InMemorySessionManager.java in undertow. Specifically in >> the bumpTimeout() that gets called on every getAttribute call. Each of these >> calls takes 15 ms, which when called 100 times during the course of a jsf >> request, adds up. (The 15 ms occurs when the execute.executeAfter in >> netty tries to wake up another thread) >>> Looking over the code: >>> io/undertow/server/session/InMemorySessionManager.java >>> >>> -- snip >>> synchronized void bumpTimeout() { >>> final int maxInactiveInterval = getMaxInactiveInterval(); >>> if (maxInactiveInterval> 0) { >>> long newExpireTime = System.currentTimeMillis() + >> (maxInactiveInterval * 1000); >>> if(timerCancelKey != null&& (newExpireTime< expireTime)) { >>> // We have to re-schedule as the new maxInactiveInterval is >> lower than the old one >>> if (!timerCancelKey.remove()) { >>> return; >>> } >>> timerCancelKey = null; >>> } >>> expireTime = newExpireTime; >>> if(timerCancelKey == null) { >>> //+1 second, to make sure that the time has actually expired >>> //we don't re-schedule every time, as it is expensive >>> //instead when it expires we check if the timeout has been >> bumped, and if so we re-schedule >>> timerCancelKey = >>> executor.executeAfter(cancelTask, maxInactiveInterval + 1, >>> TimeUnit.SECONDS); >>> -- snip >>> >>> If the time changes by 1ms, then the expiration task is cancelled and a new >> one is scheduled. But this new scheduling takes 15ms. Therefore every call >> to getAttribute (which in turn calls bumpTimeout) will constantly cancel and >> reschedule the expiration tasks. This seems heavy handed. Also the >> comment seems to imply that the developer who wrote this was aware that >> rescheduling is expensive, yet it happens on every call. >>> Disabling session expiration causes our application to run twice as >>> fast. (5.5 second page load goes down to 2.5) >>> >>> >>> >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Sun Sep 7 17:50:14 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 08 Sep 2014 07:50:14 +1000 Subject: [undertow-dev] Does ClassPathResourceManager work to serve a html file which is inside a packaged jar In-Reply-To: References: Message-ID: <540CD316.2030606@redhat.com> io.undertow.examples.chat.ChatServer does something similar to what you are talking about, and it definitely works in jar form. Do you have some kind of reproducer that I can debug? Stuart Venkatesha T R wrote: > Hi Tomaz, > > I have the following structure in my maven project > > Classes are in src/main/java folder in the package com.xxx.yyy.zzz and > the html is there inside the src/main/resources folder inside the folder > com/xxx/yyy/zzz folder itself. I have checked the jar file also in which > the html is packaged into correct classpath too. > > I am using the following code to set the Resource path : > > ClassPathResourceManager resourceManager = new > ClassPathResourceManager(MyUndertowServer.class.getClassLoader(), MyUndertowServer.class.getPackage()); > // MyUndertowServer is in same com.xxx.yyy.zzz path > > then I am creating > > ResourceHandler resourceHandler = > Handlers.resource(resourceManager).addWelcomeFiles("index.html").setDirectoryListingEnabled(true); > > > & then finally adding > deploymentInfo.setResourceManager(resourceManager); > > > Can you please figure out whether I am doing something wrong above? > Please paste a sample working code for this part so that I can check it out. > > Thanks a lot for your patience and time > > > On Fri, Sep 5, 2014 at 3:54 PM, Toma? Cerar > wrote: > > So show as the code that you use to setup ClassPAthResourceManager > also some locations of classes / resources would be welcome. > > > On Fri, Sep 5, 2014 at 11:52 AM, Venkatesha T R > wrote: > > Hi Tomaz, > > I have seen and confirmed that resources are present in right > packages inside the packaged jar. But I am not able to get the > resource served! :( > > Thanks, > Venkatesha T R > > > On Fri, Sep 5, 2014 at 3:20 PM, Toma? Cerar > > wrote: > > Maybe problem is that you are not properly packaging > resources in your jar. > For maven project that should be in main/java/resources > (standard jar module type) > otherwise you can easily add any custom path as resource > that will be packed into your war. > > In short, open the resulting jar and see if resources are there. > > > On Fri, Sep 5, 2014 at 6:56 AM, Bill O'Neil > > wrote: > > Could you provide a little more info. > > 1. Are the html pages in a non standard location that > may not be added to the class path in the jar? > 2. Are you setting a resource base path? > > I just tested serving files from an executable jar and > it works as expected for me. > > > On Fri, Sep 5, 2014 at 12:30 AM, Venkatesha T R > > wrote: > > Hi, > > I am seeing this behavior in undertow - I have > written a simple web application using undertow > which processes 3 requests and provides a single > (may be two in future) page (s) to see. These pages > are just html pages and 3 requests are GET/POST > requests. I am using ClassPathResourceManager class > to serve the index.html file which is present inside > classpath in one of my package (I am using a maven > project). It works fine when I run this application > in the Eclipse environment (where there is no jar > used for running). But when I package this > application as a jar file and run it in standalone > mode, ClassPathResourceManager fails to pick the > resource and serve it. > > ClassPathResourceManager reports Resource instance, > but I see a blank page (404) error when I see it in > browser. If somebody has any clue about what is > going on, or knows about this possible bug, please > let me know. It will help me a lot. > > Thanks in advance.. > > -- > > *Thanks and Regards* > *--------------------------------------------------------------------------------------------------------------------* > *Venkatesh T R* > *9945040858* > A Man with Many Dimensions... > > > _______________________________________________ > 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 > > > > > > -- > > *Thanks and Regards* > *--------------------------------------------------------------------------------------------------------------------* > *Venkatesh T R* > *9945040858* > A Man with Many Dimensions... > > > > > > -- > > *Thanks and Regards* > *--------------------------------------------------------------------------------------------------------------------* > *Venkatesh T R* > *9945040858* > A Man with Many Dimensions... > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From vworld4u at gmail.com Mon Sep 8 13:19:17 2014 From: vworld4u at gmail.com (Venkatesha T R) Date: Mon, 8 Sep 2014 22:49:17 +0530 Subject: [undertow-dev] Does ClassPathResourceManager work to serve a html file which is inside a packaged jar In-Reply-To: <540CD316.2030606@redhat.com> References: <540CD316.2030606@redhat.com> Message-ID: Hi Stuart, I am able to get it working finally! I was trying to write a sample application as Suart suggested and I tried using the latest undertow-core version (1.1.0.Beta7) and it worked magically! :) It was a bug in earlier version (1.0.1.Final) it seems! I confirmed the bug by reverting to older version (1.0.1.Final) and got the same issue (it was not serving the index.html). I really wish to thank all who guided me in this - special thanks to Stuart, Tomaz and Bill! Note: Anybody who wish to use a sample application to test the file serve from classpath can use https://github.com/vworld4u/undertow-fileserve-sample *Thanks and Regards,* Venkatesha T R On Mon, Sep 8, 2014 at 3:20 AM, Stuart Douglas wrote: > io.undertow.examples.chat.ChatServer does something similar to what you > are talking about, and it definitely works in jar form. > > Do you have some kind of reproducer that I can debug? > > Stuart > > Venkatesha T R wrote: > >> Hi Tomaz, >> >> I have the following structure in my maven project >> >> Classes are in src/main/java folder in the package com.xxx.yyy.zzz and >> the html is there inside the src/main/resources folder inside the folder >> com/xxx/yyy/zzz folder itself. I have checked the jar file also in which >> the html is packaged into correct classpath too. >> >> I am using the following code to set the Resource path : >> >> ClassPathResourceManager resourceManager = new >> ClassPathResourceManager(MyUndertowServer.class.getClassLoader(), >> MyUndertowServer.class.getPackage()); >> // MyUndertowServer is in same com.xxx.yyy.zzz path >> >> then I am creating >> >> ResourceHandler resourceHandler = >> Handlers.resource(resourceManager).addWelcomeFiles("index.html"). >> setDirectoryListingEnabled(true); >> >> >> & then finally adding >> deploymentInfo.setResourceManager(resourceManager); >> >> >> Can you please figure out whether I am doing something wrong above? >> Please paste a sample working code for this part so that I can check it >> out. >> >> Thanks a lot for your patience and time >> >> >> On Fri, Sep 5, 2014 at 3:54 PM, Toma? Cerar > > wrote: >> >> So show as the code that you use to setup ClassPAthResourceManager >> also some locations of classes / resources would be welcome. >> >> >> On Fri, Sep 5, 2014 at 11:52 AM, Venkatesha T R > > wrote: >> >> Hi Tomaz, >> >> I have seen and confirmed that resources are present in right >> packages inside the packaged jar. But I am not able to get the >> resource served! :( >> >> Thanks, >> Venkatesha T R >> >> >> On Fri, Sep 5, 2014 at 3:20 PM, Toma? Cerar >> > wrote: >> >> Maybe problem is that you are not properly packaging >> resources in your jar. >> For maven project that should be in main/java/resources >> (standard jar module type) >> otherwise you can easily add any custom path as resource >> that will be packed into your war. >> >> In short, open the resulting jar and see if resources are >> there. >> >> >> On Fri, Sep 5, 2014 at 6:56 AM, Bill O'Neil >> > wrote: >> >> Could you provide a little more info. >> >> 1. Are the html pages in a non standard location that >> may not be added to the class path in the jar? >> 2. Are you setting a resource base path? >> >> I just tested serving files from an executable jar and >> it works as expected for me. >> >> >> On Fri, Sep 5, 2014 at 12:30 AM, Venkatesha T R >> > wrote: >> >> Hi, >> >> I am seeing this behavior in undertow - I have >> written a simple web application using undertow >> which processes 3 requests and provides a single >> (may be two in future) page (s) to see. These pages >> are just html pages and 3 requests are GET/POST >> requests. I am using ClassPathResourceManager class >> to serve the index.html file which is present inside >> classpath in one of my package (I am using a maven >> project). It works fine when I run this application >> in the Eclipse environment (where there is no jar >> used for running). But when I package this >> application as a jar file and run it in standalone >> mode, ClassPathResourceManager fails to pick the >> resource and serve it. >> >> ClassPathResourceManager reports Resource instance, >> but I see a blank page (404) error when I see it in >> browser. If somebody has any clue about what is >> going on, or knows about this possible bug, please >> let me know. It will help me a lot. >> >> Thanks in advance.. >> >> -- >> >> *Thanks and Regards* >> *----------------------------- >> ------------------------------------------------------------ >> ---------------------------* >> *Venkatesh T R* >> *9945040858* >> A Man with Many Dimensions... >> >> >> _______________________________________________ >> 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 >> >> >> >> >> >> -- >> >> *Thanks and Regards* >> *----------------------------------------------------------- >> ---------------------------------------------------------* >> *Venkatesh T R* >> *9945040858* >> A Man with Many Dimensions... >> >> >> >> >> >> -- >> >> *Thanks and Regards* >> *----------------------------------------------------------- >> ---------------------------------------------------------* >> *Venkatesh T R* >> *9945040858* >> A Man with Many Dimensions... >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> > -- *Thanks and Regards* *--------------------------------------------------------------------------------------------------------------------* *Venkatesh T R* *9945040858* A Man with Many Dimensions... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140908/f2867cb0/attachment.html From jim at crossleys.org Tue Sep 16 12:20:34 2014 From: jim at crossleys.org (Jim Crossley) Date: Tue, 16 Sep 2014 12:20:34 -0400 Subject: [undertow-dev] Async sending of NIO objects thru a ServletOutputStream? Message-ID: Hi guys, I'm looking to promote Undertow as a preferred alternative to Jetty for the Pedestal [1] framework. One Jetty feature it relies on is the async sending of ByteBuffers and ReadableByteChannels in Jetty's impl of ServletOutputStream [2]. Two methods, in particular: sendContent(ByteBuffer, Callback) and sendContent(ReadableByteChannel, Callback). I was hoping someone might point me in the right direction of replicating this behavior with Undertow's ServletOutputStreamImpl. It does have a write(ByteBuffer) method, but it appears to be blocking. And I was hoping there might be some XNIO abstraction for dealing with the ReadableByteChannel, perhaps some example code somewhere? Any and all help/advice is appreciated! Jim [1]: https://github.com/pedestal/pedestal [2]: http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-server/9.2.0.v20140526/org/eclipse/jetty/server/HttpOutput.java -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140916/9e5ba469/attachment.html From sdouglas at redhat.com Tue Sep 16 18:00:07 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 17 Sep 2014 08:00:07 +1000 Subject: [undertow-dev] Async sending of NIO objects thru a ServletOutputStream? In-Reply-To: References: Message-ID: <5418B2E7.70507@redhat.com> Jim Crossley wrote: > Hi guys, > > I'm looking to promote Undertow as a preferred alternative to Jetty for > the Pedestal [1] framework. > > One Jetty feature it relies on is the async sending of ByteBuffers and > ReadableByteChannels in Jetty's impl of ServletOutputStream [2]. Two > methods, in particular: sendContent(ByteBuffer, Callback) and > sendContent(ReadableByteChannel, Callback). If you have enabled async mode on the ServletOutputStream then write(ByteBuffer) will write using async IO, and invoke the write listener when done. Basically it will work the same as standard servlet async IO, but with byte buffers. Stuart > > I was hoping someone might point me in the right direction of > replicating this behavior with Undertow's ServletOutputStreamImpl. It > does have a write(ByteBuffer) method, but it appears to be blocking. And > I was hoping there might be some XNIO abstraction for dealing with the > ReadableByteChannel, perhaps some example code somewhere? > > Any and all help/advice is appreciated! > Jim > > [1]: https://github.com/pedestal/pedestal > [2]: > http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-server/9.2.0.v20140526/org/eclipse/jetty/server/HttpOutput.java > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From jim at crossleys.org Tue Sep 16 20:18:13 2014 From: jim at crossleys.org (Jim Crossley) Date: Tue, 16 Sep 2014 20:18:13 -0400 Subject: [undertow-dev] Async sending of NIO objects thru a ServletOutputStream? In-Reply-To: <5418B2E7.70507@redhat.com> References: <5418B2E7.70507@redhat.com> Message-ID: I actually figured that out, Stuart, thanks. So I have writing a ByteBuffer covered. Any thoughts on handling the ReadableByteChannel? Looking at the Jetty impl, it appears I need to read it into one or more ByteBuffers and then write them out. Should I use the Pooled from the exhange's connection? Jim On Tue, Sep 16, 2014 at 6:00 PM, Stuart Douglas wrote: > > > Jim Crossley wrote: > >> Hi guys, >> >> I'm looking to promote Undertow as a preferred alternative to Jetty for >> the Pedestal [1] framework. >> >> One Jetty feature it relies on is the async sending of ByteBuffers and >> ReadableByteChannels in Jetty's impl of ServletOutputStream [2]. Two >> methods, in particular: sendContent(ByteBuffer, Callback) and >> sendContent(ReadableByteChannel, Callback). >> > > If you have enabled async mode on the ServletOutputStream then > write(ByteBuffer) will write using async IO, and invoke the write listener > when done. Basically it will work the same as standard servlet async IO, > but with byte buffers. > > Stuart > > >> I was hoping someone might point me in the right direction of >> replicating this behavior with Undertow's ServletOutputStreamImpl. It >> does have a write(ByteBuffer) method, but it appears to be blocking. And >> I was hoping there might be some XNIO abstraction for dealing with the >> ReadableByteChannel, perhaps some example code somewhere? >> >> Any and all help/advice is appreciated! >> Jim >> >> [1]: https://github.com/pedestal/pedestal >> [2]: >> http://grepcode.com/file/repo1.maven.org/maven2/org. >> eclipse.jetty/jetty-server/9.2.0.v20140526/org/eclipse/ >> jetty/server/HttpOutput.java >> >> _______________________________________________ >> 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/20140916/c1730987/attachment-0001.html From sdouglas at redhat.com Tue Sep 16 20:37:05 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 17 Sep 2014 10:37:05 +1000 Subject: [undertow-dev] Async sending of NIO objects thru a ServletOutputStream? In-Reply-To: References: <5418B2E7.70507@redhat.com> Message-ID: <5418D7B1.8090805@redhat.com> Jim Crossley wrote: > I actually figured that out, Stuart, thanks. So I have writing a > ByteBuffer covered. Any thoughts on handling the ReadableByteChannel? > Looking at the Jetty impl, it appears I need to read it into one or more > ByteBuffers and then write them out. Should I use the Pooled > from the exhange's connection? Yea, we don't have an easy way to just do that transfer at this stage, you will need to read into the pooled buffer then write it out. Is this an async or a blocking transfer? The problem with ReadableByteChannel is that it can be a blocking channel, and as a result reading from it in the IO thread will result in crappy performance. Stuart > > Jim > > On Tue, Sep 16, 2014 at 6:00 PM, Stuart Douglas > wrote: > > > > Jim Crossley wrote: > > Hi guys, > > I'm looking to promote Undertow as a preferred alternative to > Jetty for > the Pedestal [1] framework. > > One Jetty feature it relies on is the async sending of > ByteBuffers and > ReadableByteChannels in Jetty's impl of ServletOutputStream [2]. Two > methods, in particular: sendContent(ByteBuffer, Callback) and > sendContent(__ReadableByteChannel, Callback). > > > If you have enabled async mode on the ServletOutputStream then > write(ByteBuffer) will write using async IO, and invoke the write > listener when done. Basically it will work the same as standard > servlet async IO, but with byte buffers. > > Stuart > > > I was hoping someone might point me in the right direction of > replicating this behavior with Undertow's > ServletOutputStreamImpl. It > does have a write(ByteBuffer) method, but it appears to be > blocking. And > I was hoping there might be some XNIO abstraction for dealing > with the > ReadableByteChannel, perhaps some example code somewhere? > > Any and all help/advice is appreciated! > Jim > > [1]: https://github.com/pedestal/__pedestal > > [2]: > http://grepcode.com/file/__repo1.maven.org/maven2/org.__eclipse.jetty/jetty-server/9.__2.0.v20140526/org/eclipse/__jetty/server/HttpOutput.java > > > _________________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/__mailman/listinfo/undertow-dev > > > From jim at crossleys.org Tue Sep 16 21:18:24 2014 From: jim at crossleys.org (Jim Crossley) Date: Tue, 16 Sep 2014 21:18:24 -0400 Subject: [undertow-dev] Async sending of NIO objects thru a ServletOutputStream? In-Reply-To: <5418D7B1.8090805@redhat.com> References: <5418B2E7.70507@redhat.com> <5418D7B1.8090805@redhat.com> Message-ID: Stuart Douglas writes: [...] > Yea, we don't have an easy way to just do that transfer at this stage, > you will need to read into the pooled buffer then write it out. > > Is this an async or a blocking transfer? The problem with > ReadableByteChannel is that it can be a blocking channel, and as a > result reading from it in the IO thread will result in crappy > performance. Because of the way they're using it (with Clojure's core.async library) I expect the transfer to be async, but I'll verify that with them. You wouldn't happen to have an example of reading one into and out of a pooled buffer you could point me to, would you? :) Jim On Tue, Sep 16, 2014 at 8:37 PM, Stuart Douglas wrote: > > > Jim Crossley wrote: > >> I actually figured that out, Stuart, thanks. So I have writing a >> ByteBuffer covered. Any thoughts on handling the ReadableByteChannel? >> Looking at the Jetty impl, it appears I need to read it into one or more >> ByteBuffers and then write them out. Should I use the Pooled >> from the exhange's connection? >> > > Yea, we don't have an easy way to just do that transfer at this stage, you > will need to read into the pooled buffer then write it out. > > Is this an async or a blocking transfer? The problem with > ReadableByteChannel is that it can be a blocking channel, and as a result > reading from it in the IO thread will result in crappy performance. > > Stuart > > >> Jim >> >> On Tue, Sep 16, 2014 at 6:00 PM, Stuart Douglas > > wrote: >> >> >> >> Jim Crossley wrote: >> >> Hi guys, >> >> I'm looking to promote Undertow as a preferred alternative to >> Jetty for >> the Pedestal [1] framework. >> >> One Jetty feature it relies on is the async sending of >> ByteBuffers and >> ReadableByteChannels in Jetty's impl of ServletOutputStream [2]. >> Two >> methods, in particular: sendContent(ByteBuffer, Callback) and >> sendContent(__ReadableByteChannel, Callback). >> >> >> If you have enabled async mode on the ServletOutputStream then >> write(ByteBuffer) will write using async IO, and invoke the write >> listener when done. Basically it will work the same as standard >> servlet async IO, but with byte buffers. >> >> Stuart >> >> >> I was hoping someone might point me in the right direction of >> replicating this behavior with Undertow's >> ServletOutputStreamImpl. It >> does have a write(ByteBuffer) method, but it appears to be >> blocking. And >> I was hoping there might be some XNIO abstraction for dealing >> with the >> ReadableByteChannel, perhaps some example code somewhere? >> >> Any and all help/advice is appreciated! >> Jim >> >> [1]: https://github.com/pedestal/__pedestal >> >> [2]: >> http://grepcode.com/file/__repo1.maven.org/maven2/org.__ >> eclipse.jetty/jetty-server/9.__2.0.v20140526/org/eclipse/__ >> jetty/server/HttpOutput.java >> > eclipse.jetty/jetty-server/9.2.0.v20140526/org/eclipse/ >> jetty/server/HttpOutput.java> >> >> _________________________________________________ >> 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/20140916/2a5a45d4/attachment.html From sdouglas at redhat.com Tue Sep 16 21:24:00 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 17 Sep 2014 11:24:00 +1000 Subject: [undertow-dev] Async sending of NIO objects thru a ServletOutputStream? In-Reply-To: References: <5418B2E7.70507@redhat.com> <5418D7B1.8090805@redhat.com> Message-ID: <5418E2B0.3020604@redhat.com> Generally we use org.xnio.ChannelListeners#initiateTransfer, however that is when we are just transfering between two channels, without any ServletOutputStream in use. Basically you just read from the channel, if read returns >0 then call buffer.flip() and write it to the channel. When the callback is invoked clear the buffer, and repeat until read returns -1. I don't know what you do if read returns 0, generally you will just use whatever async capability the channel has to register some kind of listener, but that is not provided by the ReadableByteChannel contract. You do have to make sure that that buffer is freed when you are done with it though, as buffer leaks are bad news. Stuart Jim Crossley wrote: > Stuart Douglas > writes: > > [...] > > > Yea, we don't have an easy way to just do that transfer at this stage, > > you will need to read into the pooled buffer then write it out. > > > > Is this an async or a blocking transfer? The problem with > > ReadableByteChannel is that it can be a blocking channel, and as a > > result reading from it in the IO thread will result in crappy > > performance. > > Because of the way they're using it (with Clojure's core.async library) > I expect the transfer to be async, but I'll verify that with them. > > You wouldn't happen to have an example of reading one into and out of a > pooled buffer you could point me to, would you? :) > > Jim > > > On Tue, Sep 16, 2014 at 8:37 PM, Stuart Douglas > wrote: > > > > Jim Crossley wrote: > > I actually figured that out, Stuart, thanks. So I have writing a > ByteBuffer covered. Any thoughts on handling the > ReadableByteChannel? > Looking at the Jetty impl, it appears I need to read it into one > or more > ByteBuffers and then write them out. Should I use the > Pooled > from the exhange's connection? > > > Yea, we don't have an easy way to just do that transfer at this > stage, you will need to read into the pooled buffer then write it out. > > Is this an async or a blocking transfer? The problem with > ReadableByteChannel is that it can be a blocking channel, and as a > result reading from it in the IO thread will result in crappy > performance. > > Stuart > > > Jim > > On Tue, Sep 16, 2014 at 6:00 PM, Stuart Douglas > > >> wrote: > > > > Jim Crossley wrote: > > Hi guys, > > I'm looking to promote Undertow as a preferred > alternative to > Jetty for > the Pedestal [1] framework. > > One Jetty feature it relies on is the async sending of > ByteBuffers and > ReadableByteChannels in Jetty's impl of > ServletOutputStream [2]. Two > methods, in particular: sendContent(ByteBuffer, > Callback) and > sendContent(____ReadableByteChannel, Callback). > > > If you have enabled async mode on the ServletOutputStream then > write(ByteBuffer) will write using async IO, and invoke the > write > listener when done. Basically it will work the same as standard > servlet async IO, but with byte buffers. > > Stuart > > > I was hoping someone might point me in the right > direction of > replicating this behavior with Undertow's > ServletOutputStreamImpl. It > does have a write(ByteBuffer) method, but it appears to be > blocking. And > I was hoping there might be some XNIO abstraction for > dealing > with the > ReadableByteChannel, perhaps some example code somewhere? > > Any and all help/advice is appreciated! > Jim > > [1]: https://github.com/pedestal/____pedestal > > > > [2]: > http://grepcode.com/file/____repo1.maven.org/maven2/org.____eclipse.jetty/jetty-server/9.____2.0.v20140526/org/eclipse/____jetty/server/HttpOutput.java > > > > > ___________________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > > > > https://lists.jboss.org/____mailman/listinfo/undertow-dev > > > > > > From ecki at zusammenkunft.net Tue Sep 16 21:38:27 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 17 Sep 2014 03:38:27 +0200 Subject: [undertow-dev] NoSuchMethod in 9ea-b30 getRawHostnameSE Message-ID: <20140917033827.00002df6.ecki@zusammenkunft.net> Hello JDK security team, (cced the Undertow guys cause I mentioned this on the IRC channel) when trying to run the JBoss Undertow build tests with JDK9ea-b30 a lot of tests fail with the same "NosuchMethodError", and I am not sure why. It looks like an internal inconsitency in the JSSE? However I tries the simple SSLEngine demo code and that one compiles and runs. Undertow master 79daf29 https://github.com/undertow-io/undertow/tree/79daf29322940f93a42f736a2cd959f6d0a7a5de maven 3.2.3 Windows x64 7 this is using xnio-api and xnio-nio 3.3.0.Beta3 (from jboss-public-repository-group) One of the observed exceptions (but not related to SPDY IMHO): 03:26:29,211 ERROR (XNIO-1 I/O-2) [org.xnio.listener] XNIO001007: A channel event listener threw an exception: java.lang.NoSuchMethodError: sun.security.ssl.ClientHandshaker.getRawHostnameSE()Ljava/lang/String; at sun.security.ssl.ClientHandshaker.getKickstartMessage(ClientHandshaker.java:1294) at sun.security.ssl.Handshaker.kickstart(Handshaker.java:972) at sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:728) at sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:750) at org.xnio.ssl.JsseSslConduitEngine.beginHandshake(JsseSslConduitEngine.java:177) at org.xnio.ssl.JsseSslStreamConnection.startHandshake(JsseSslStreamConnection.java:85) at io.undertow.client.spdy.SpdyClientProvider.handlePotentialSpdyConnection(SpdyClientProvider.java:222) at io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:132) at io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:49) at io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:123) at io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:120) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:283) at org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:265) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:324) at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) As xnio (the NIO abstraction used by undertow) uses asm and some unsafe functions it might not be the cleanest test, however the stacktrace looks like the problem is all inside javax.ssl / JSSE? I am not sure where to look for the right JDK source version, is this before or after the modular split? The latest code does not seem to match the stacktrace: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/40c3a5ce8047/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java Gruss Bernd From sdouglas at redhat.com Tue Sep 16 22:14:05 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 17 Sep 2014 12:14:05 +1000 Subject: [undertow-dev] NoSuchMethod in 9ea-b30 getRawHostnameSE In-Reply-To: <20140917033827.00002df6.ecki@zusammenkunft.net> References: <20140917033827.00002df6.ecki@zusammenkunft.net> Message-ID: <5418EE6D.6010004@redhat.com> This is because Undertow is testing SPDY and HTTP2, which use Jetty ALPN. This jar resides on the boot class path, and you need to use a specific version of it for a given JVM. Undertow uses profiles to select between JDK 7 and 8, however it looks like it will attempt to use the 8 jar if you test on 9. I will look at updating the build to just ignore these tests if the appropriate version of the ALPN jar is not available. Stuart Bernd Eckenfels wrote: > Hello JDK security team, > (cced the Undertow guys cause I mentioned this on the IRC channel) > > > when trying to run the JBoss Undertow build tests with JDK9ea-b30 a lot > of tests fail with the same "NosuchMethodError", and I am not sure why. > > It looks like an internal inconsitency in the JSSE? However I tries the simple SSLEngine demo code and that one compiles and runs. > > Undertow master 79daf29 > https://github.com/undertow-io/undertow/tree/79daf29322940f93a42f736a2cd959f6d0a7a5de > > maven 3.2.3 Windows x64 7 > this is using xnio-api and xnio-nio 3.3.0.Beta3 (from jboss-public-repository-group) > > > One of the observed exceptions (but not related to SPDY IMHO): > > 03:26:29,211 ERROR (XNIO-1 I/O-2) [org.xnio.listener] XNIO001007: A channel event listener threw an exception: > > java.lang.NoSuchMethodError: sun.security.ssl.ClientHandshaker.getRawHostnameSE()Ljava/lang/String; > at sun.security.ssl.ClientHandshaker.getKickstartMessage(ClientHandshaker.java:1294) > at sun.security.ssl.Handshaker.kickstart(Handshaker.java:972) > at sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:728) > at sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:750) > > at org.xnio.ssl.JsseSslConduitEngine.beginHandshake(JsseSslConduitEngine.java:177) > at org.xnio.ssl.JsseSslStreamConnection.startHandshake(JsseSslStreamConnection.java:85) > at io.undertow.client.spdy.SpdyClientProvider.handlePotentialSpdyConnection(SpdyClientProvider.java:222) > at io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:132) > at io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:49) > at io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:123) > at io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:120) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:283) > at org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:265) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:324) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > > > As xnio (the NIO abstraction used by undertow) uses asm and some > unsafe functions it might not be the cleanest test, however the > stacktrace looks like the problem is all inside javax.ssl / JSSE? > > I am not sure where to look for the right JDK source version, is this before or after the modular split? The latest code does not seem to match the stacktrace: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/40c3a5ce8047/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java > > Gruss > Bernd > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From jgreene at redhat.com Tue Sep 16 22:33:57 2014 From: jgreene at redhat.com (Jason T. Greene) Date: Tue, 16 Sep 2014 22:33:57 -0400 (EDT) Subject: [undertow-dev] Async sending of NIO objects thru a ServletOutputStream? In-Reply-To: References: <5418B2E7.70507@redhat.com> <5418D7B1.8090805@redhat.com> Message-ID: <53D76506-5609-4CA6-94A6-12449250F907@redhat.com> Sent from my iPhone > On Sep 16, 2014, at 8:19 PM, Jim Crossley wrote: > > Is this an async or a blocking transfer? The problem with > > ReadableByteChannel is that it can be a blocking channel, and as a > > result reading from it in the IO thread will result in crappy > > performance. > > Because of the way they're using it (with Clojure's core.async library) > I expect the transfer to be async, but I'll verify that with them. I just looked at the Jetty impl, and the code assumes blocking behavior with that method. Anything using it will be blocking reads with non blocking writes. From jim at crossleys.org Tue Sep 16 23:00:27 2014 From: jim at crossleys.org (Jim Crossley) Date: Tue, 16 Sep 2014 23:00:27 -0400 Subject: [undertow-dev] Async sending of NIO objects thru a ServletOutputStream? In-Reply-To: <53D76506-5609-4CA6-94A6-12449250F907@redhat.com> References: <5418B2E7.70507@redhat.com> <5418D7B1.8090805@redhat.com> <53D76506-5609-4CA6-94A6-12449250F907@redhat.com> Message-ID: Thanks, Jason. To me, the Jetty code looks like it's doing pretty much what Stuart told me to do. Can you tell me which part exactly assumes the blocking behavior so I can relay that to the Pedestal guys? On Tue, Sep 16, 2014 at 10:33 PM, Jason T. Greene wrote: > > > Sent from my iPhone > > > On Sep 16, 2014, at 8:19 PM, Jim Crossley wrote: > > > > Is this an async or a blocking transfer? The problem with > > > ReadableByteChannel is that it can be a blocking channel, and as a > > > result reading from it in the IO thread will result in crappy > > > performance. > > > > Because of the way they're using it (with Clojure's core.async library) > > I expect the transfer to be async, but I'll verify that with them. > > I just looked at the Jetty impl, and the code assumes blocking behavior > with that method. Anything using it will be blocking reads with non > blocking writes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140916/ce42800e/attachment.html From sdouglas at redhat.com Tue Sep 16 23:03:32 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 17 Sep 2014 13:03:32 +1000 Subject: [undertow-dev] Async sending of NIO objects thru a ServletOutputStream? In-Reply-To: References: <5418B2E7.70507@redhat.com> <5418D7B1.8090805@redhat.com> <53D76506-5609-4CA6-94A6-12449250F907@redhat.com> Message-ID: <5418FA04.5020102@redhat.com> 1068 // Read from stream until buffer full or EOF 1069 _buffer.clear(); 1070 while (_buffer.hasRemaining() && !_eof) 1071 _eof = (_in.read(_buffer)) < 0; That pattern for reading from the stream only works for blocking IO. If you are using a non blocking channel this will basically wait in a busy loop till data becomes available. Stuart Jim Crossley wrote: > Thanks, Jason. To me, the Jetty code looks like it's doing pretty much > what Stuart told me to do. Can you tell me which part exactly assumes > the blocking behavior so I can relay that to the Pedestal guys? > > On Tue, Sep 16, 2014 at 10:33 PM, Jason T. Greene > wrote: > > > > Sent from my iPhone > > > On Sep 16, 2014, at 8:19 PM, Jim Crossley > wrote: > > > > Is this an async or a blocking transfer? The problem with > > > ReadableByteChannel is that it can be a blocking channel, and as a > > > result reading from it in the IO thread will result in crappy > > > performance. > > > > Because of the way they're using it (with Clojure's core.async > library) > > I expect the transfer to be async, but I'll verify that with them. > > I just looked at the Jetty impl, and the code assumes blocking > behavior with that method. Anything using it will be blocking reads > with non blocking writes. > > From jim at crossleys.org Tue Sep 16 23:27:22 2014 From: jim at crossleys.org (Jim Crossley) Date: Tue, 16 Sep 2014 23:27:22 -0400 Subject: [undertow-dev] Async sending of NIO objects thru a ServletOutputStream? In-Reply-To: <5418FA04.5020102@redhat.com> References: <5418B2E7.70507@redhat.com> <5418D7B1.8090805@redhat.com> <53D76506-5609-4CA6-94A6-12449250F907@redhat.com> <5418FA04.5020102@redhat.com> Message-ID: Interesting. Is the non-blocking alternative to change the "while..." to "if (!_eof)"? There's no problem with writing _buffer when hasRemaining() is true, is there? On Tue, Sep 16, 2014 at 11:03 PM, Stuart Douglas wrote: > > 1068 // Read from stream until buffer full or EOF > 1069 _buffer.clear(); > 1070 while (_buffer.hasRemaining() && !_eof) > 1071 _eof = (_in.read(_buffer)) < 0; > > That pattern for reading from the stream only works for blocking IO. If > you are using a non blocking channel this will basically wait in a busy > loop till data becomes available. > > Stuart > > Jim Crossley wrote: > >> Thanks, Jason. To me, the Jetty code looks like it's doing pretty much >> what Stuart told me to do. Can you tell me which part exactly assumes >> the blocking behavior so I can relay that to the Pedestal guys? >> >> On Tue, Sep 16, 2014 at 10:33 PM, Jason T. Greene > > wrote: >> >> >> >> Sent from my iPhone >> >> > On Sep 16, 2014, at 8:19 PM, Jim Crossley > > wrote: >> > >> > Is this an async or a blocking transfer? The problem with >> > > ReadableByteChannel is that it can be a blocking channel, and as >> a >> > > result reading from it in the IO thread will result in crappy >> > > performance. >> > >> > Because of the way they're using it (with Clojure's core.async >> library) >> > I expect the transfer to be async, but I'll verify that with them. >> >> I just looked at the Jetty impl, and the code assumes blocking >> behavior with that method. Anything using it will be blocking reads >> with non blocking writes. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140916/91091c78/attachment.html From sdouglas at redhat.com Tue Sep 16 23:28:53 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 17 Sep 2014 13:28:53 +1000 Subject: [undertow-dev] Async sending of NIO objects thru a ServletOutputStream? In-Reply-To: References: <5418B2E7.70507@redhat.com> <5418D7B1.8090805@redhat.com> <53D76506-5609-4CA6-94A6-12449250F907@redhat.com> <5418FA04.5020102@redhat.com> Message-ID: <5418FFF5.3080307@redhat.com> That is not really is issue, the issue is that non blocking channels require some way of registering a listener, so that you can be notified when more data is available. Without some form of listener all you can do is read in a busy loop :-( Stuart Jim Crossley wrote: > Interesting. Is the non-blocking alternative to change the "while..." to > "if (!_eof)"? There's no problem with writing _buffer when > hasRemaining() is true, is there? > > On Tue, Sep 16, 2014 at 11:03 PM, Stuart Douglas > wrote: > > > 1068 // Read from stream until buffer full or EOF > 1069 _buffer.clear(); > 1070 while (_buffer.hasRemaining() && !_eof) > 1071 _eof = (_in.read(_buffer)) < 0; > > That pattern for reading from the stream only works for blocking IO. > If you are using a non blocking channel this will basically wait in > a busy loop till data becomes available. > > Stuart > > Jim Crossley wrote: > > Thanks, Jason. To me, the Jetty code looks like it's doing > pretty much > what Stuart told me to do. Can you tell me which part exactly > assumes > the blocking behavior so I can relay that to the Pedestal guys? > > On Tue, Sep 16, 2014 at 10:33 PM, Jason T. Greene > > >> wrote: > > > > Sent from my iPhone > > > On Sep 16, 2014, at 8:19 PM, Jim Crossley > >> wrote: > > > > Is this an async or a blocking transfer? The problem with > > > ReadableByteChannel is that it can be a blocking channel, > and as a > > > result reading from it in the IO thread will result in crappy > > > performance. > > > > Because of the way they're using it (with Clojure's core.async > library) > > I expect the transfer to be async, but I'll verify that with > them. > > I just looked at the Jetty impl, and the code assumes blocking > behavior with that method. Anything using it will be > blocking reads > with non blocking writes. > > > From ecki at zusammenkunft.net Wed Sep 17 11:04:34 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 17 Sep 2014 17:04:34 +0200 Subject: [undertow-dev] NoSuchMethod in 9ea-b30 getRawHostnameSE In-Reply-To: <5418EE6D.6010004@redhat.com> References: <20140917033827.00002df6.ecki@zusammenkunft.net> <5418EE6D.6010004@redhat.com> Message-ID: <20140917170434.00000e0e.ecki@zusammenkunft.net> Hello, thanks Stuart, I should have known to look for this. I mentioned before, that this is a quite important thing for JSSE to support (or actually the SSL API). But I did not expect that the JEtty workaround is already used. Hopefully Simone can influence the JDK to make stuff like this less painfull and keep Java as recent as protocol support as one would expect. (And sorry for the "false" alert, rory :) Gruss Bernd Am Wed, 17 Sep 2014 12:14:05 +1000 schrieb Stuart Douglas : > This is because Undertow is testing SPDY and HTTP2, which use Jetty > ALPN. This jar resides on the boot class path, and you need to use a > specific version of it for a given JVM. > > Undertow uses profiles to select between JDK 7 and 8, however it > looks like it will attempt to use the 8 jar if you test on 9. I will > look at updating the build to just ignore these tests if the > appropriate version of the ALPN jar is not available. > > Stuart > > Bernd Eckenfels wrote: > > Hello JDK security team, > > (cced the Undertow guys cause I mentioned this on the IRC channel) > > > > > > when trying to run the JBoss Undertow build tests with JDK9ea-b30 a > > lot of tests fail with the same "NosuchMethodError", and I am not > > sure why. > > > > It looks like an internal inconsitency in the JSSE? However I tries > > the simple SSLEngine demo code and that one compiles and runs. > > > > Undertow master 79daf29 > > https://github.com/undertow-io/undertow/tree/79daf29322940f93a42f736a2cd959f6d0a7a5de > > > > maven 3.2.3 Windows x64 7 > > this is using xnio-api and xnio-nio 3.3.0.Beta3 (from > > jboss-public-repository-group) > > > > > > One of the observed exceptions (but not related to SPDY IMHO): > > > > 03:26:29,211 ERROR (XNIO-1 I/O-2) > > [org.xnio.listener] XNIO001007: A > > channel event listener threw an exception: > > > > java.lang.NoSuchMethodError: > > sun.security.ssl.ClientHandshaker.getRawHostnameSE()Ljava/lang/String; > > at > > sun.security.ssl.ClientHandshaker.getKickstartMessage(ClientHandshaker.java:1294) > > at sun.security.ssl.Handshaker.kickstart(Handshaker.java:972) at > > sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:728) > > at > > sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:750) > > > > at > > org.xnio.ssl.JsseSslConduitEngine.beginHandshake(JsseSslConduitEngine.java:177) > > at > > org.xnio.ssl.JsseSslStreamConnection.startHandshake(JsseSslStreamConnection.java:85) > > at > > io.undertow.client.spdy.SpdyClientProvider.handlePotentialSpdyConnection(SpdyClientProvider.java:222) > > at > > io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:132) > > at > > io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:49) > > at > > io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:123) > > at > > io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:120) > > at > > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > > at > > org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:283) > > at > > org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:265) > > at > > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > > at > > org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:324) > > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > > > > > > As xnio (the NIO abstraction used by undertow) uses asm and some > > unsafe functions it might not be the cleanest test, however the > > stacktrace looks like the problem is all inside javax.ssl / JSSE? > > > > I am not sure where to look for the right JDK source version, is > > this before or after the modular split? The latest code does not > > seem to match the stacktrace: > > > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/40c3a5ce8047/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java > > > > Gruss > > Bernd > > > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev From bill at dartalley.com Wed Sep 17 11:29:42 2014 From: bill at dartalley.com (Bill O'Neil) Date: Wed, 17 Sep 2014 11:29:42 -0400 Subject: [undertow-dev] Dispatching to non IO threads Message-ID: I have come across a few Handlers that dispatch to a worker thread these include blocking handler, resource handler and the form parsing handler. My specific use case was with the form parsing handler. I had a bunch of handlers chained together basically as follows. Blocking handler -> ExceptionHandler -> FormParsingHandler -> MyBlockingHandler The form parsing handler would cause the handler to be dispatched a second time to a new executor. This made me lose the stack trace, and the Exception handler was not catching an exception being thrown inside of MyBlockingHandler. I resolved this by basically cloning the form parsing handler and calling the parseBlocking() instead of the non blocking parse(). This is acceptable because I already dispatched to a non IO thread. Should any handler that attempts to dispatch first check if the exchange is in an IO thread before dispatching or is there a specific use case for some handlers to always dispatch? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140917/41b1b947/attachment.html From jgreene at redhat.com Wed Sep 17 17:26:41 2014 From: jgreene at redhat.com (Jason T. Greene) Date: Wed, 17 Sep 2014 17:26:41 -0400 (EDT) Subject: [undertow-dev] Dispatching to non IO threads In-Reply-To: References: Message-ID: <0CAF0B07-03DF-4991-9652-78B007E7D839@redhat.com> > On Sep 17, 2014, at 10:32 AM, "Bill O'Neil" wrote: > > I have come across a few Handlers that dispatch to a worker thread these include blocking handler, resource handler and the form parsing handler. > > My specific use case was with the form parsing handler. I had a bunch of handlers chained together basically as follows. > > Blocking handler -> ExceptionHandler -> FormParsingHandler -> MyBlockingHandler > > The form parsing handler would cause the handler to be dispatched a second time to a new executor. This made me lose the stack trace, and the Exception handler was not catching an exception being thrown inside of MyBlockingHandler. > > I resolved this by basically cloning the form parsing handler and calling the parseBlocking() instead of the non blocking parse(). This is acceptable because I already dispatched to a non IO thread. > > Should any handler that attempts to dispatch first check if the exchange is in an IO thread before dispatching or is there a specific use case for some handlers to always dispatch? Yes all handler that dispatch should check that. It's a performance hit not to. > > Thanks, > Bill > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Wed Sep 17 18:59:52 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 18 Sep 2014 08:59:52 +1000 Subject: [undertow-dev] Dispatching to non IO threads In-Reply-To: References: Message-ID: <541A1268.6080001@redhat.com> I will change EagerFormParsingHandler to call parseBlocking() if the exchange is in blocking mode. Stuart Bill O'Neil wrote: > I have come across a few Handlers that dispatch to a worker thread these > include blocking handler, resource handler and the form parsing handler. > > My specific use case was with the form parsing handler. I had a bunch > of handlers chained together basically as follows. > > Blocking handler -> ExceptionHandler -> FormParsingHandler -> > MyBlockingHandler > > The form parsing handler would cause the handler to be dispatched a > second time to a new executor. This made me lose the stack trace, and > the Exception handler was not catching an exception being thrown inside > of MyBlockingHandler. > > I resolved this by basically cloning the form parsing handler and > calling the parseBlocking() instead of the non blocking parse(). This > is acceptable because I already dispatched to a non IO thread. > > Should any handler that attempts to dispatch first check if the exchange > is in an IO thread before dispatching or is there a specific use case > for some handlers to always dispatch? > > Thanks, > Bill > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From bill at dartalley.com Wed Sep 17 19:03:41 2014 From: bill at dartalley.com (Bill O'Neil) Date: Wed, 17 Sep 2014 19:03:41 -0400 Subject: [undertow-dev] Dispatching to non IO threads In-Reply-To: <541A1268.6080001@redhat.com> References: <541A1268.6080001@redhat.com> Message-ID: Thanks, I will submit a pull request if I notice it anywhere else. On Wednesday, September 17, 2014, Stuart Douglas wrote: > I will change EagerFormParsingHandler to call parseBlocking() if the > exchange is in blocking mode. > > Stuart > > Bill O'Neil wrote: > >> I have come across a few Handlers that dispatch to a worker thread these >> include blocking handler, resource handler and the form parsing handler. >> >> My specific use case was with the form parsing handler. I had a bunch >> of handlers chained together basically as follows. >> >> Blocking handler -> ExceptionHandler -> FormParsingHandler -> >> MyBlockingHandler >> >> The form parsing handler would cause the handler to be dispatched a >> second time to a new executor. This made me lose the stack trace, and >> the Exception handler was not catching an exception being thrown inside >> of MyBlockingHandler. >> >> I resolved this by basically cloning the form parsing handler and >> calling the parseBlocking() instead of the non blocking parse(). This >> is acceptable because I already dispatched to a non IO thread. >> >> Should any handler that attempts to dispatch first check if the exchange >> is in an IO thread before dispatching or is there a specific use case >> for some handlers to always dispatch? >> >> Thanks, >> Bill >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140917/175d758a/attachment.html From bclozel at pivotal.io Fri Sep 19 12:41:55 2014 From: bclozel at pivotal.io (Brian Clozel) Date: Fri, 19 Sep 2014 18:41:55 +0200 Subject: [undertow-dev] undertow http client - howto long polling xhr? Message-ID: Hi, I'd like to build an HTTP client that receives chunks of data as part of a long polling HTTP request, using Undertow's HTTP client. So in a way, I'd need callback methods like "onHeader" and "onContent". >From what I read in UndertowClient and HttpClientConnection, it looks like the http client is parsing the *whole* HTTP response and does not provide those callbacks. Is there a way to achieve this? If not, does this qualify as an interesting feature for undertow's HTTP client? Thanks, -- Brian Clozel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140919/ed4e3628/attachment.html From sdouglas at redhat.com Fri Sep 19 19:56:31 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Sat, 20 Sep 2014 09:56:31 +1000 Subject: [undertow-dev] undertow http client - howto long polling xhr? In-Reply-To: References: Message-ID: <541CC2AF.8030406@redhat.com> io.undertow.client.ClientExchange#setResponseListener() lets you set a callback that will be invoked once the response headers have been parsed. You then use the io.undertow.client.ClientExchange#getResponseChannel() method to read the body. Because this is an XNIO channel it supports async IO via the use of a read listener, which gives you a callback when more data arrives. Stuart Brian Clozel wrote: > Hi, > > I'd like to build an HTTP client that receives chunks of data as part of > a long polling HTTP request, using Undertow's HTTP client. So in a way, > I'd need callback methods like "onHeader" and "onContent". > > From what I read in UndertowClient and HttpClientConnection, it looks > like the http client is parsing the *whole* HTTP response and does not > provide those callbacks. > > Is there a way to achieve this? > If not, does this qualify as an interesting feature for undertow's HTTP > client? > > Thanks, > -- > Brian Clozel > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From mattias.nilsson.grip at redpill-linpro.com Tue Sep 23 11:29:00 2014 From: mattias.nilsson.grip at redpill-linpro.com (Mattias Nilsson Grip) Date: Tue, 23 Sep 2014 17:29:00 +0200 (CEST) Subject: [undertow-dev] single-sign-on and reauthenticate=false In-Reply-To: <1952992066.2490670.1411485708619.JavaMail.zimbra@redpill-linpro.com> Message-ID: <2112134791.2490800.1411486140396.JavaMail.zimbra@redpill-linpro.com> Hi, I see in a commit message from February "Drop superfluous re-authenticate attribute of ." Looks like re-authenticate=true is still the default behaviour? In previous JBoss versions it was possible to use re-authenticate=false to do single-sign-on for two web applications in different security domains without the need to reauthenticate. What is the proper way to do that now? Should we configure an identity provider? Regards, Mattias From tomaz.cerar at gmail.com Tue Sep 23 16:24:35 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 23 Sep 2014 22:24:35 +0200 Subject: [undertow-dev] single-sign-on and reauthenticate=false In-Reply-To: <2112134791.2490800.1411486140396.JavaMail.zimbra@redpill-linpro.com> References: <1952992066.2490670.1411485708619.JavaMail.zimbra@redpill-linpro.com> <2112134791.2490800.1411486140396.JavaMail.zimbra@redpill-linpro.com> Message-ID: This is discussion that is more appropriate for wildfly-dev mailing list. (cced now) On Tue, Sep 23, 2014 at 5:29 PM, Mattias Nilsson Grip < mattias.nilsson.grip at redpill-linpro.com> wrote: > Hi, > > I see in a commit message from February "Drop superfluous re-authenticate > attribute of ." > > Looks like re-authenticate=true is still the default behaviour? In > previous JBoss versions it was possible to use re-authenticate=false to do > single-sign-on for two web applications in different security domains > without the need to reauthenticate. What is the proper way to do that now? > Should we configure an identity provider? > > Regards, > Mattias > _______________________________________________ > 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/20140923/5e1e4992/attachment-0001.html From sdouglas at redhat.com Tue Sep 23 16:33:11 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 24 Sep 2014 06:33:11 +1000 Subject: [undertow-dev] Undertow versioning Message-ID: <5421D907.80208@redhat.com> Hi all, Soon I am going to create a 1.1 branch, and move master to 1.2. Wildfly 8.2 is due for release soon and I would like it to use 1.1, however I am not comfortable having our new and fairly untested mod_cluster load balancer (i.e. frontend) and HTTP2 code in a final release, as this code is still very much under development. These features will be removed from the 1.1 branch, and 1.1 final should be released soon, while development on these features will continue in the 1.2 branch. Stuart From miere.teixeira at gmail.com Wed Sep 24 08:04:43 2014 From: miere.teixeira at gmail.com (Miere Teixeira) Date: Wed, 24 Sep 2014 09:04:43 -0300 Subject: [undertow-dev] Undertow versioning In-Reply-To: <5421D907.80208@redhat.com> References: <5421D907.80208@redhat.com> Message-ID: Hi Stuart, Thank you for sharing the next steps on undertow with us, and for preserve undertow stable. Is there any doc where I could keep up with roadmap next steps. Once I used Undertow in a customer and it make my job easier, I would like to contribute back with it in some way. These features will be removed from the 1.1 branch, and 1.1 final should > be released soon, while development on these features will continue in > the 1.2 branch. > Have you ever considered to use git flow as development process? It may lead you to a simpler way to keep unfinished features away from your releases. Regards, Miere On Tue, Sep 23, 2014 at 5:33 PM, Stuart Douglas wrote: > Hi all, > > Soon I am going to create a 1.1 branch, and move master to 1.2. Wildfly > 8.2 is due for release soon and I would like it to use 1.1, however I am > not comfortable having our new and fairly untested mod_cluster load > balancer (i.e. frontend) and HTTP2 code in a final release, as this code > is still very much under development. > > These features will be removed from the 1.1 branch, and 1.1 final should > be released soon, while development on these features will continue in > the 1.2 branch. > > Stuart > _______________________________________________ > 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/20140924/bc9f1bc0/attachment.html From gryzlaw at hotmail.com Wed Sep 24 04:04:12 2014 From: gryzlaw at hotmail.com (Luke Ambrogio) Date: Wed, 24 Sep 2014 10:04:12 +0200 Subject: [undertow-dev] How do I handle HTTP Methods in Undertow? Message-ID: So I've decided to start using Undertow, both as an experiment and due to the great results it achieved in benchmark tests. And while I think it's fantastic there's a feature which is either missing or I can't find. I want to develop a RESTful web service so it's important for me to identify which HTTP method is being called. Now I can get this from RequestMethod in the HttpServerExchange parameter but if had to that for every handler that would become tedious. My solution, which works but feels wrong, is this: Created an annotation interface called HTTPMethod: @Retention(RetentionPolicy.RUNTIME)@Target(ElementType.METHOD) public @interface HTTPMethod { public enum Method { OTHER, GET, PUT, POST, DELETE} Method method() default Method.OTHER; an "abstract" class (which is not abstract): public abstract class RESTfulHandler implements HttpHandler { @Overridepublic void handleRequest(HttpServerExchange hse) throws Exception { for (Method method : this.getClass().getDeclaredMethods()) { // if method is annotated with @Test if (method.isAnnotationPresent(HTTPMethod.class)) { Annotation annotation = method.getAnnotation(HTTPMethod.class); HTTPMethod test = (HTTPMethod) annotation; switch (test.method()) { case PUT: if (hse.getRequestMethod().toString().equals("PUT")) { method.invoke(this); } break; case POST: if (hse.getRequestMethod().toString().equals("POST")) { method.invoke(this); } break; case GET: if (hse.getRequestMethod().toString().equals("GET")) { method.invoke(this); } break; case DELETE: if (hse.getRequestMethod().toString().equals("DELETE")) { method.invoke(this); } break; case OTHER: if (hse.getRequestMethod().toString().equals("OTHER")) { method.invoke(this); } break; } if (test.method() == HTTPMethod.Method.PUT) { method.invoke(this); } } }} } and an implementation of both the above: public class ItemHandler extends RESTfulHandler{ @HTTPMethod(method=GET)public void getAllItems(){ System.out.println("GET");} @HTTPMethod(method=POST)public void addItem(){ System.out.println("POST"); } @HTTPMethodpublic void doNothing(){ System.out.println("OTHERS"); } } Now as I said, it works, but I'm sure that the abstract class and it's implementation have something missing so that they glue correctly. So my question is two fold: 1) Is there a better / proper way to filter HTTP requests in Undertow? 2) What is the correct way of using annotations correctly correctly in the above case? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140924/309ad4fe/attachment-0001.html From sdouglas at redhat.com Wed Sep 24 20:00:32 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 25 Sep 2014 10:00:32 +1000 Subject: [undertow-dev] How do I handle HTTP Methods in Undertow? In-Reply-To: References: Message-ID: <54235B20.40204@redhat.com> Undertow is intended to be a lightweight web server rather than a container, so it does not really have any annotation processing facilities built in, however it should be fairly easy to implement something similar on top of Undertow. Undertow has a handler called io.undertow.server.RoutingHandler, that routes requests based on method and path. If you use this handler it should be possible to build a handler chain based on annotations on the handler classes. Note that you don't want to be using reflection in the handleRequest method, as reflection is relatively slow. Instead the best approach is to read the annotations and boot time and build up the routing map while the server is starting. Stuart Luke Ambrogio wrote: > So I've decided to start using Undertow, both as an experiment and due > to the great results it achieved in benchmark tests. And while I think > it's fantastic there's a feature which is either missing or I can't find. > > I want to develop a RESTful web service so it's important for me to > identify which HTTP method is being called. Now I can get this from > RequestMethod in the HttpServerExchange parameter but if had to that for > every handler that would become tedious. > > My solution, which works but feels wrong, is this: > > Created an annotation interface called HTTPMethod: > > |@Retention(RetentionPolicy.RUNTIME) > @Target(ElementType.METHOD) > public @interface HTTPMethod { > > public enum Method { > > OTHER, GET, PUT, POST, DELETE > } > > Method method() default Method.OTHER;| > > an "abstract" class (which is not abstract): > > |public abstract class RESTfulHandler implements HttpHandler { > > @Override > public void handleRequest(HttpServerExchange hse) throws Exception { > > for (Method method: this.getClass().getDeclaredMethods()) { > > // if method is annotated with @Test > if (method.isAnnotationPresent(HTTPMethod.class)) { > > Annotation annotation= method.getAnnotation(HTTPMethod.class); > HTTPMethod test= (HTTPMethod) annotation; > > switch (test.method()) { > case PUT: > if (hse.getRequestMethod().toString().equals("PUT")) { > method.invoke(this); > } > break; > > case POST: > if (hse.getRequestMethod().toString().equals("POST")) { > method.invoke(this); > } > break; > > case GET: > if (hse.getRequestMethod().toString().equals("GET")) { > method.invoke(this); > } > break; > > case DELETE: > if (hse.getRequestMethod().toString().equals("DELETE")) { > method.invoke(this); > } > break; > case OTHER: > if (hse.getRequestMethod().toString().equals("OTHER")) { > method.invoke(this); > } > break; > } > if (test.method() == HTTPMethod.Method.PUT) { > method.invoke(this); > } > } > } > }| > > } > > and an implementation of both the above: > > |public class ItemHandler extends RESTfulHandler{ > > @HTTPMethod(method=GET) > public void getAllItems() > { > System.out.println("GET"); > } > > @HTTPMethod(method=POST) > public void addItem() > { > System.out.println("POST"); > } > > @HTTPMethod > public void doNothing() > { > System.out.println("OTHERS"); > }| > > } > > Now as I said, it works, but I'm sure that the abstract class and it's > implementation have something missing so that they glue correctly. So my > question is two fold: > > 1) Is there a better / proper way to filter HTTP requests in Undertow? > 2) What is the correct way of using annotations correctly correctly in > the above case? > > Thanks > > > _______________________________________________ > 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 Sep 24 20:02:29 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 24 Sep 2014 19:02:29 -0500 Subject: [undertow-dev] How do I handle HTTP Methods in Undertow? In-Reply-To: References: Message-ID: This looks nice to me. Although for efficiency you would want to initialize the methods and cache them. If you prefer you could use the servlet API which allows you to filter methods with annotations as well. On Sep 24, 2014, at 3:04 AM, Luke Ambrogio wrote: > So I've decided to start using Undertow, both as an experiment and due to the great results it achieved in benchmark tests. And while I think it's fantastic there's a feature which is either missing or I can't find. > > I want to develop a RESTful web service so it's important for me to identify which HTTP method is being called. Now I can get this from RequestMethod in the HttpServerExchange parameter but if had to that for every handler that would become tedious. > > My solution, which works but feels wrong, is this: > > Created an annotation interface called HTTPMethod: > > @Retention(RetentionPolicy.RUNTIME) > @Target(ElementType.METHOD) > > > public @interface HTTPMethod { > > > > public enum Method { > > > OTHER > , GET, PUT, POST, > DELETE > > } > > > > Method method() default Method.OTHER; > an "abstract" class (which is not abstract): > > public abstract class RESTfulHandler implements HttpHandler { > > > > @Override > public void handleRequest(HttpServerExchange hse) throws Exception { > > > > for (Method method : this.getClass().getDeclaredMethods()) { > > > > // if method is annotated with @Test > > > if (method.isAnnotationPresent(HTTPMethod.class)) { > > > > Annotation annotation = method.getAnnotation(HTTPMethod.class); > > > HTTPMethod test = (HTTPMethod) annotation; > > > > switch (test.method()) { > > > case PUT: > > > if (hse.getRequestMethod().toString().equals("PUT")) { > > method > .invoke(this); > > > } > > > break; > > > > case POST: > > > if (hse.getRequestMethod().toString().equals("POST")) { > > method > .invoke(this); > > > } > > > break; > > > > case GET: > > > if (hse.getRequestMethod().toString().equals("GET")) { > > method > .invoke(this); > > > } > > > break; > > > > case DELETE: > > > if (hse.getRequestMethod().toString().equals("DELETE")) { > > method > .invoke(this); > > > } > > > break; > > > case OTHER: > > > if (hse.getRequestMethod().toString().equals("OTHER")) { > > method > .invoke(this); > > > } > > > break; > > > } > > > if (test.method() == HTTPMethod.Method.PUT) { > > method > .invoke(this); > > > } > > > } > > > } > } > } > > and an implementation of both the above: > > public class ItemHandler extends RESTfulHandler{ > > > > @HTTPMethod(method=GET) > public void getAllItems() > { > > > System.out.println("GET"); > } > > > > @HTTPMethod(method=POST) > public void addItem() > { > > > System.out.println("POST"); > > > } > > > > @HTTPMethod > public void doNothing() > { > > > System.out.println("OTHERS"); > > > } > } > > Now as I said, it works, but I'm sure that the abstract class and it's implementation have something missing so that they glue correctly. So my question is two fold: > > 1) Is there a better / proper way to filter HTTP requests in Undertow? 2) What is the correct way of using annotations correctly correctly in the above case? > > Thanks > > > > _______________________________________________ > 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 lanabe.lanabe at gmail.com Wed Sep 24 20:26:34 2014 From: lanabe.lanabe at gmail.com (lanabe) Date: Thu, 25 Sep 2014 09:26:34 +0900 Subject: [undertow-dev] How do I handle HTTP Methods in Undertow? In-Reply-To: References: Message-ID: Hi, Luke. How about using JAX-RS? Hammock(RESTEasy + Weld + Undertow) might be helpful for your RESTful APIs, however, it hasn't been updated recently. https://github.com/johnament/hammock On Wed, Sep 24, 2014 at 5:04 PM, Luke Ambrogio wrote: > So I've decided to start using Undertow, both as an experiment and due to > the great results it achieved in benchmark tests. And while I think it's > fantastic there's a feature which is either missing or I can't find. > > I want to develop a RESTful web service so it's important for me to > identify which HTTP method is being called. Now I can get this from > RequestMethod in the HttpServerExchange parameter but if had to that for > every handler that would become tedious. > > My solution, which works but feels wrong, is this: > > Created an annotation interface called HTTPMethod: > > @Retention(RetentionPolicy.RUNTIME)@Target(ElementType.METHOD) public @interface HTTPMethod { > public enum Method { > > OTHER, GET, PUT, POST, DELETE} > Method method() default Method.OTHER; > > an "abstract" class (which is not abstract): > > public abstract class RESTfulHandler implements HttpHandler { > @Overridepublic void handleRequest(HttpServerExchange hse) throws Exception { > > for (Method method : this.getClass().getDeclaredMethods()) { > > // if method is annotated with @Test > if (method.isAnnotationPresent(HTTPMethod.class)) { > > Annotation annotation = method.getAnnotation(HTTPMethod.class); > HTTPMethod test = (HTTPMethod) annotation; > > switch (test.method()) { > case PUT: > if (hse.getRequestMethod().toString().equals("PUT")) { > method.invoke(this); > } > break; > > case POST: > if (hse.getRequestMethod().toString().equals("POST")) { > method.invoke(this); > } > break; > > case GET: > if (hse.getRequestMethod().toString().equals("GET")) { > method.invoke(this); > } > break; > > case DELETE: > if (hse.getRequestMethod().toString().equals("DELETE")) { > method.invoke(this); > } > break; > case OTHER: > if (hse.getRequestMethod().toString().equals("OTHER")) { > method.invoke(this); > } > break; > } > if (test.method() == HTTPMethod.Method.PUT) { > method.invoke(this); > } > } > }} > > } > > and an implementation of both the above: > > public class ItemHandler extends RESTfulHandler{ > @HTTPMethod(method=GET)public void getAllItems(){ > System.out.println("GET");} > @HTTPMethod(method=POST)public void addItem(){ > System.out.println("POST"); } > @HTTPMethodpublic void doNothing(){ > System.out.println("OTHERS"); } > > } > > Now as I said, it works, but I'm sure that the abstract class and it's > implementation have something missing so that they glue correctly. So my > question is two fold: > > 1) Is there a better / proper way to filter HTTP requests in Undertow? 2) > What is the correct way of using annotations correctly correctly in the > above case? > > Thanks > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140925/948c1c64/attachment-0001.html From gryzlaw at hotmail.com Thu Sep 25 04:19:55 2014 From: gryzlaw at hotmail.com (Luke Ambrogio) Date: Thu, 25 Sep 2014 10:19:55 +0200 Subject: [undertow-dev] How do I handle HTTP Methods in Undertow? In-Reply-To: <54235B20.40204@redhat.com> References: <54235B20.40204@redhat.com> Message-ID: Thanks Stuart, I think that's exactly what I need, since annotation as you say might not be necessary. Can you specify which version I would need to include in the pom please? Since the one I am using (1.0.14.Final) doesn't seem to include it and maven doesn't seem to know about 1.2.0.Beta1-SNAPSHOT. Cheers On Thu, Sep 25, 2014 at 2:00 AM, Stuart Douglas wrote: > Undertow is intended to be a lightweight web server rather than a > container, so it does not really have any annotation processing facilities > built in, however it should be fairly easy to implement something similar > on top of Undertow. > > Undertow has a handler called io.undertow.server.RoutingHandler, that > routes requests based on method and path. If you use this handler it should > be possible to build a handler chain based on annotations on the handler > classes. > > Note that you don't want to be using reflection in the handleRequest > method, as reflection is relatively slow. Instead the best approach is to > read the annotations and boot time and build up the routing map while the > server is starting. > > Stuart > > Luke Ambrogio wrote: > >> So I've decided to start using Undertow, both as an experiment and due >> to the great results it achieved in benchmark tests. And while I think >> it's fantastic there's a feature which is either missing or I can't find. >> >> I want to develop a RESTful web service so it's important for me to >> identify which HTTP method is being called. Now I can get this from >> RequestMethod in the HttpServerExchange parameter but if had to that for >> every handler that would become tedious. >> >> My solution, which works but feels wrong, is this: >> >> Created an annotation interface called HTTPMethod: >> >> |@Retention(RetentionPolicy.RUNTIME) >> @Target(ElementType.METHOD) >> public @interface HTTPMethod { >> >> public enum Method { >> >> OTHER, GET, PUT, POST, DELETE >> } >> >> Method method() default Method.OTHER;| >> >> an "abstract" class (which is not abstract): >> >> |public abstract class RESTfulHandler implements HttpHandler { >> >> @Override >> public void handleRequest(HttpServerExchange hse) throws Exception >> { >> >> for (Method method: this.getClass().getDeclaredMethods()) { >> >> // if method is annotated with @Test >> if (method.isAnnotationPresent(HTTPMethod.class)) { >> >> Annotation annotation= method.getAnnotation( >> HTTPMethod.class); >> HTTPMethod test= (HTTPMethod) annotation; >> >> >> switch (test.method()) { >> case PUT: >> if (hse.getRequestMethod().toString().equals("PUT")) >> { >> method.invoke(this); >> } >> break; >> >> case POST: >> if (hse.getRequestMethod().toString().equals("POST")) >> { >> method.invoke(this); >> } >> break; >> >> case GET: >> if (hse.getRequestMethod().toString().equals("GET")) >> { >> method.invoke(this); >> } >> break; >> >> case DELETE: >> if (hse.getRequestMethod().toString().equals("DELETE")) >> { >> method.invoke(this); >> } >> break; >> case OTHER: >> if (hse.getRequestMethod().toString().equals("OTHER")) >> { >> method.invoke(this); >> } >> break; >> } >> if (test.method() == HTTPMethod.Method.PUT) { >> method.invoke(this); >> } >> } >> } >> }| >> >> } >> >> and an implementation of both the above: >> >> |public class ItemHandler extends RESTfulHandler{ >> >> @HTTPMethod(method=GET) >> public void getAllItems() >> { >> System.out.println("GET"); >> } >> >> @HTTPMethod(method=POST) >> public void addItem() >> { >> System.out.println("POST"); >> } >> >> @HTTPMethod >> public void doNothing() >> { >> System.out.println("OTHERS"); >> }| >> >> } >> >> Now as I said, it works, but I'm sure that the abstract class and it's >> implementation have something missing so that they glue correctly. So my >> question is two fold: >> >> 1) Is there a better / proper way to filter HTTP requests in Undertow? >> 2) What is the correct way of using annotations correctly correctly in >> the above case? >> >> Thanks >> >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140925/3144f064/attachment.html From gryzlaw at hotmail.com Thu Sep 25 04:28:44 2014 From: gryzlaw at hotmail.com (Luke Ambrogio) Date: Thu, 25 Sep 2014 10:28:44 +0200 Subject: [undertow-dev] How do I handle HTTP Methods in Undertow? In-Reply-To: References: Message-ID: Hi Jason, thanks for your feedback, there seems to be several solutions better than mine :) Cheers On Thu, Sep 25, 2014 at 2:02 AM, Jason Greene wrote: > This looks nice to me. Although for efficiency you would want to > initialize the methods and cache them. If you prefer you could use the > servlet API which allows you to filter methods with annotations as well. > > On Sep 24, 2014, at 3:04 AM, Luke Ambrogio wrote: > > > So I've decided to start using Undertow, both as an experiment and due > to the great results it achieved in benchmark tests. And while I think it's > fantastic there's a feature which is either missing or I can't find. > > > > I want to develop a RESTful web service so it's important for me to > identify which HTTP method is being called. Now I can get this from > RequestMethod in the HttpServerExchange parameter but if had to that for > every handler that would become tedious. > > > > My solution, which works but feels wrong, is this: > > > > Created an annotation interface called HTTPMethod: > > > > @Retention(RetentionPolicy.RUNTIME) > > @Target(ElementType.METHOD) > > > > > > public @interface HTTPMethod { > > > > > > > > public enum Method { > > > > > > OTHER > > , GET, PUT, POST, > > DELETE > > > > } > > > > > > > > Method method() default Method.OTHER; > > an "abstract" class (which is not abstract): > > > > public abstract class RESTfulHandler implements HttpHandler { > > > > > > > > @Override > > public void handleRequest(HttpServerExchange hse) throws Exception { > > > > > > > > for (Method method : this.getClass().getDeclaredMethods()) { > > > > > > > > // if method is annotated with @Test > > > > > > if (method.isAnnotationPresent(HTTPMethod.class)) { > > > > > > > > Annotation annotation = method.getAnnotation(HTTPMethod.class); > > > > > > HTTPMethod test = (HTTPMethod) annotation; > > > > > > > > switch (test.method()) { > > > > > > case PUT: > > > > > > if (hse.getRequestMethod().toString().equals("PUT")) { > > > > method > > .invoke(this); > > > > > > } > > > > > > break; > > > > > > > > case POST: > > > > > > if (hse.getRequestMethod().toString().equals("POST")) { > > > > method > > .invoke(this); > > > > > > } > > > > > > break; > > > > > > > > case GET: > > > > > > if (hse.getRequestMethod().toString().equals("GET")) { > > > > method > > .invoke(this); > > > > > > } > > > > > > break; > > > > > > > > case DELETE: > > > > > > if (hse.getRequestMethod().toString().equals("DELETE")) { > > > > method > > .invoke(this); > > > > > > } > > > > > > break; > > > > > > case OTHER: > > > > > > if (hse.getRequestMethod().toString().equals("OTHER")) { > > > > method > > .invoke(this); > > > > > > } > > > > > > break; > > > > > > } > > > > > > if (test.method() == HTTPMethod.Method.PUT) { > > > > method > > .invoke(this); > > > > > > } > > > > > > } > > > > > > } > > } > > } > > > > and an implementation of both the above: > > > > public class ItemHandler extends RESTfulHandler{ > > > > > > > > @HTTPMethod(method=GET) > > public void getAllItems() > > { > > > > > > System.out.println("GET"); > > } > > > > > > > > @HTTPMethod(method=POST) > > public void addItem() > > { > > > > > > System.out.println("POST"); > > > > > > } > > > > > > > > @HTTPMethod > > public void doNothing() > > { > > > > > > System.out.println("OTHERS"); > > > > > > } > > } > > > > Now as I said, it works, but I'm sure that the abstract class and it's > implementation have something missing so that they glue correctly. So my > question is two fold: > > > > 1) Is there a better / proper way to filter HTTP requests in Undertow? > 2) What is the correct way of using annotations correctly correctly in the > above case? > > > > Thanks > > > > > > > > _______________________________________________ > > 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/20140925/8da958ca/attachment.html From jonathan.hart at gmail.com Thu Sep 25 05:49:50 2014 From: jonathan.hart at gmail.com (Jonathan Hart) Date: Thu, 25 Sep 2014 02:49:50 -0700 Subject: [undertow-dev] How do I handle HTTP Methods in Undertow? In-Reply-To: References: Message-ID: Here is a code example of how to use a RouterHandler in a way that I think you are looking for... https://gist.github.com/jonathanhart/0aeef8f72b9ef3a4ea78 How you handle the HTTPHandler part is entirely up to you, but this is how I chose to do it.. but it does illustrate how to use RouterHandler with HTTP verbs.. You can obviously have the same URL template for different verbs and route them to different behaviors, as I do by passing in a custom constructor.. Jonathan On Thu, Sep 25, 2014 at 1:28 AM, Luke Ambrogio wrote: > Hi Jason, > > thanks for your feedback, there seems to be several solutions better than > mine :) > > Cheers > > On Thu, Sep 25, 2014 at 2:02 AM, Jason Greene > wrote: > >> This looks nice to me. Although for efficiency you would want to >> initialize the methods and cache them. If you prefer you could use the >> servlet API which allows you to filter methods with annotations as well. >> >> On Sep 24, 2014, at 3:04 AM, Luke Ambrogio wrote: >> >> > So I've decided to start using Undertow, both as an experiment and due >> to the great results it achieved in benchmark tests. And while I think it's >> fantastic there's a feature which is either missing or I can't find. >> > >> > I want to develop a RESTful web service so it's important for me to >> identify which HTTP method is being called. Now I can get this from >> RequestMethod in the HttpServerExchange parameter but if had to that for >> every handler that would become tedious. >> > >> > My solution, which works but feels wrong, is this: >> > >> > Created an annotation interface called HTTPMethod: >> > >> > @Retention(RetentionPolicy.RUNTIME) >> > @Target(ElementType.METHOD) >> > >> > >> > public @interface HTTPMethod { >> > >> > >> > >> > public enum Method { >> > >> > >> > OTHER >> > , GET, PUT, POST, >> > DELETE >> > >> > } >> > >> > >> > >> > Method method() default Method.OTHER; >> > an "abstract" class (which is not abstract): >> > >> > public abstract class RESTfulHandler implements HttpHandler { >> > >> > >> > >> > @Override >> > public void handleRequest(HttpServerExchange hse) throws Exception { >> > >> > >> > >> > for (Method method : this.getClass().getDeclaredMethods()) { >> > >> > >> > >> > // if method is annotated with @Test >> > >> > >> > if (method.isAnnotationPresent(HTTPMethod.class)) { >> > >> > >> > >> > Annotation annotation = method.getAnnotation(HTTPMethod.class); >> > >> > >> > HTTPMethod test = (HTTPMethod) annotation; >> > >> > >> > >> > switch (test.method()) { >> > >> > >> > case PUT: >> > >> > >> > if (hse.getRequestMethod().toString().equals("PUT")) { >> > >> > method >> > .invoke(this); >> > >> > >> > } >> > >> > >> > break; >> > >> > >> > >> > case POST: >> > >> > >> > if (hse.getRequestMethod().toString().equals("POST")) { >> > >> > method >> > .invoke(this); >> > >> > >> > } >> > >> > >> > break; >> > >> > >> > >> > case GET: >> > >> > >> > if (hse.getRequestMethod().toString().equals("GET")) { >> > >> > method >> > .invoke(this); >> > >> > >> > } >> > >> > >> > break; >> > >> > >> > >> > case DELETE: >> > >> > >> > if (hse.getRequestMethod().toString().equals("DELETE")) { >> > >> > method >> > .invoke(this); >> > >> > >> > } >> > >> > >> > break; >> > >> > >> > case OTHER: >> > >> > >> > if (hse.getRequestMethod().toString().equals("OTHER")) { >> > >> > method >> > .invoke(this); >> > >> > >> > } >> > >> > >> > break; >> > >> > >> > } >> > >> > >> > if (test.method() == HTTPMethod.Method.PUT) { >> > >> > method >> > .invoke(this); >> > >> > >> > } >> > >> > >> > } >> > >> > >> > } >> > } >> > } >> > >> > and an implementation of both the above: >> > >> > public class ItemHandler extends RESTfulHandler{ >> > >> > >> > >> > @HTTPMethod(method=GET) >> > public void getAllItems() >> > { >> > >> > >> > System.out.println("GET"); >> > } >> > >> > >> > >> > @HTTPMethod(method=POST) >> > public void addItem() >> > { >> > >> > >> > System.out.println("POST"); >> > >> > >> > } >> > >> > >> > >> > @HTTPMethod >> > public void doNothing() >> > { >> > >> > >> > System.out.println("OTHERS"); >> > >> > >> > } >> > } >> > >> > Now as I said, it works, but I'm sure that the abstract class and it's >> implementation have something missing so that they glue correctly. So my >> question is two fold: >> > >> > 1) Is there a better / proper way to filter HTTP requests in Undertow? >> 2) What is the correct way of using annotations correctly correctly in the >> above case? >> > >> > Thanks >> > >> > >> > >> > _______________________________________________ >> > undertow-dev mailing list >> > undertow-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140925/f57f6953/attachment-0001.html From miere.teixeira at gmail.com Thu Sep 25 06:39:36 2014 From: miere.teixeira at gmail.com (Miere Teixeira) Date: Thu, 25 Sep 2014 07:39:36 -0300 Subject: [undertow-dev] Could not handle the same URL to GET and POST with RoutingHandler Message-ID: Hi Devs, I'm facing a new situation with RoutingHandler. I have two HttpHandler's, one responsible to retrieve all users registered in my database. The second one is responsible to include an user into my database. Both handler was registered with RoutingHandler, both registered with '/users/' URL but the first one registered for GET and the second for POST. After upgrade to 1.1.0.Beta7 version, this behavior was broken and throws the exception described bellow. I've made this simple unit test that simulates the same error when running in 1.1.0.Beta7, but works perfectly in 1.1.0.Beta6. https://gist.github.com/miere/3ef15b916cdaaae1896c Let me know if it is a bug or the wrong way to achieve this goal. Also, let me know if I could in some way. Miere -- java.lang.IllegalStateException: UT000071: Cannot add path template /sameurl, matcher already contains an equivalent pattern /sameurl at io.undertow.util.PathTemplateMatcher.add(PathTemplateMatcher.java:112) at io.undertow.util.PathTemplateMatcher.add(PathTemplateMatcher.java:148) at io.undertow.server.RoutingHandler.add(RoutingHandler.java:112) at io.undertow.server.RoutingHandler.add(RoutingHandler.java:99) at kikaha.core.RoutingHandlerTest.ensureItsPossibleToHandlePostAndGetToSameURL(RoutingHandlerTest.java:16) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140925/197648d8/attachment.html From sdouglas at redhat.com Thu Sep 25 17:12:17 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 26 Sep 2014 07:12:17 +1000 Subject: [undertow-dev] How do I handle HTTP Methods in Undertow? In-Reply-To: References: <54235B20.40204@redhat.com> Message-ID: <54248531.20108@redhat.com> 1.1.CR2 1.1.Final should be out soon. Stuart Luke Ambrogio wrote: > Thanks Stuart, > > I think that's exactly what I need, since annotation as you say might > not be necessary. > > Can you specify which version I would need to include in the pom please? > Since the one I am using (1.0.14.Final) doesn't seem to include it and > maven doesn't seem to know about 1.2.0.Beta1-SNAPSHOT. > > Cheers > > On Thu, Sep 25, 2014 at 2:00 AM, Stuart Douglas > wrote: > > Undertow is intended to be a lightweight web server rather than a > container, so it does not really have any annotation processing > facilities built in, however it should be fairly easy to implement > something similar on top of Undertow. > > Undertow has a handler called io.undertow.server.__RoutingHandler, > that routes requests based on method and path. If you use this > handler it should be possible to build a handler chain based on > annotations on the handler classes. > > Note that you don't want to be using reflection in the handleRequest > method, as reflection is relatively slow. Instead the best approach > is to read the annotations and boot time and build up the routing > map while the server is starting. > > Stuart > > Luke Ambrogio wrote: > > So I've decided to start using Undertow, both as an experiment > and due > to the great results it achieved in benchmark tests. And while I > think > it's fantastic there's a feature which is either missing or I > can't find. > > I want to develop a RESTful web service so it's important for me to > identify which HTTP method is being called. Now I can get this from > RequestMethod in the HttpServerExchange parameter but if had to > that for > every handler that would become tedious. > > My solution, which works but feels wrong, is this: > > Created an annotation interface called HTTPMethod: > > |@Retention(RetentionPolicy.__RUNTIME) > @Target(ElementType.METHOD) > public @interface HTTPMethod { > > public enum Method { > > OTHER, GET, PUT, POST, DELETE > } > > Method method() default Method.OTHER;| > > an "abstract" class (which is not abstract): > > |public abstract class RESTfulHandler implements HttpHandler { > > @Override > public void handleRequest(__HttpServerExchange hse) throws > Exception { > > for (Method method: > this.getClass().__getDeclaredMethods()) { > > // if method is annotated with @Test > if (method.isAnnotationPresent(__HTTPMethod.class)) { > > Annotation annotation= > method.getAnnotation(__HTTPMethod.class); > HTTPMethod test= (HTTPMethod) annotation; > > > switch (test.method()) { > case PUT: > if > (hse.getRequestMethod().__toString().equals("PUT")) { > method.invoke(this); > } > break; > > case POST: > if > (hse.getRequestMethod().__toString().equals("POST")) { > method.invoke(this); > } > break; > > case GET: > if > (hse.getRequestMethod().__toString().equals("GET")) { > method.invoke(this); > } > break; > > case DELETE: > if > (hse.getRequestMethod().__toString().equals("DELETE")) { > method.invoke(this); > } > break; > case OTHER: > if > (hse.getRequestMethod().__toString().equals("OTHER")) { > method.invoke(this); > } > break; > } > if (test.method() == HTTPMethod.Method.PUT) { > method.invoke(this); > } > } > } > }| > > } > > and an implementation of both the above: > > |public class ItemHandler extends RESTfulHandler{ > > @HTTPMethod(method=GET) > public void getAllItems() > { > System.out.println("GET"); > } > > @HTTPMethod(method=POST) > public void addItem() > { > System.out.println("POST"); > } > > @HTTPMethod > public void doNothing() > { > System.out.println("OTHERS"); > }| > > } > > Now as I said, it works, but I'm sure that the abstract class > and it's > implementation have something missing so that they glue > correctly. So my > question is two fold: > > 1) Is there a better / proper way to filter HTTP requests in > Undertow? > 2) What is the correct way of using annotations correctly > correctly in > the above case? > > Thanks > > > _________________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/__mailman/listinfo/undertow-dev > > > > From sdouglas at redhat.com Thu Sep 25 23:31:10 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 26 Sep 2014 13:31:10 +1000 Subject: [undertow-dev] How do I handle HTTP Methods in Undertow? In-Reply-To: <54248531.20108@redhat.com> References: <54235B20.40204@redhat.com> <54248531.20108@redhat.com> Message-ID: <5424DDFE.8030109@redhat.com> Oops, this should read 1.1.0.CR2 and 1.1.0.Final Stuart Stuart Douglas wrote: > 1.1.CR2 > > 1.1.Final should be out soon. > > Stuart > > Luke Ambrogio wrote: >> Thanks Stuart, >> >> I think that's exactly what I need, since annotation as you say might >> not be necessary. >> >> Can you specify which version I would need to include in the pom please? >> Since the one I am using (1.0.14.Final) doesn't seem to include it and >> maven doesn't seem to know about 1.2.0.Beta1-SNAPSHOT. >> >> Cheers >> >> On Thu, Sep 25, 2014 at 2:00 AM, Stuart Douglas> > wrote: >> >> Undertow is intended to be a lightweight web server rather than a >> container, so it does not really have any annotation processing >> facilities built in, however it should be fairly easy to implement >> something similar on top of Undertow. >> >> Undertow has a handler called io.undertow.server.__RoutingHandler, >> that routes requests based on method and path. If you use this >> handler it should be possible to build a handler chain based on >> annotations on the handler classes. >> >> Note that you don't want to be using reflection in the handleRequest >> method, as reflection is relatively slow. Instead the best approach >> is to read the annotations and boot time and build up the routing >> map while the server is starting. >> >> Stuart >> >> Luke Ambrogio wrote: >> >> So I've decided to start using Undertow, both as an experiment >> and due >> to the great results it achieved in benchmark tests. And while I >> think >> it's fantastic there's a feature which is either missing or I >> can't find. >> >> I want to develop a RESTful web service so it's important for me to >> identify which HTTP method is being called. Now I can get this from >> RequestMethod in the HttpServerExchange parameter but if had to >> that for >> every handler that would become tedious. >> >> My solution, which works but feels wrong, is this: >> >> Created an annotation interface called HTTPMethod: >> >> |@Retention(RetentionPolicy.__RUNTIME) >> @Target(ElementType.METHOD) >> public @interface HTTPMethod { >> >> public enum Method { >> >> OTHER, GET, PUT, POST, DELETE >> } >> >> Method method() default Method.OTHER;| >> >> an "abstract" class (which is not abstract): >> >> |public abstract class RESTfulHandler implements HttpHandler { >> >> @Override >> public void handleRequest(__HttpServerExchange hse) throws >> Exception { >> >> for (Method method: >> this.getClass().__getDeclaredMethods()) { >> >> // if method is annotated with @Test >> if (method.isAnnotationPresent(__HTTPMethod.class)) { >> >> Annotation annotation= >> method.getAnnotation(__HTTPMethod.class); >> HTTPMethod test= (HTTPMethod) annotation; >> >> >> switch (test.method()) { >> case PUT: >> if >> (hse.getRequestMethod().__toString().equals("PUT")) { >> method.invoke(this); >> } >> break; >> >> case POST: >> if >> (hse.getRequestMethod().__toString().equals("POST")) { >> method.invoke(this); >> } >> break; >> >> case GET: >> if >> (hse.getRequestMethod().__toString().equals("GET")) { >> method.invoke(this); >> } >> break; >> >> case DELETE: >> if >> (hse.getRequestMethod().__toString().equals("DELETE")) { >> method.invoke(this); >> } >> break; >> case OTHER: >> if >> (hse.getRequestMethod().__toString().equals("OTHER")) { >> method.invoke(this); >> } >> break; >> } >> if (test.method() == HTTPMethod.Method.PUT) { >> method.invoke(this); >> } >> } >> } >> }| >> >> } >> >> and an implementation of both the above: >> >> |public class ItemHandler extends RESTfulHandler{ >> >> @HTTPMethod(method=GET) >> public void getAllItems() >> { >> System.out.println("GET"); >> } >> >> @HTTPMethod(method=POST) >> public void addItem() >> { >> System.out.println("POST"); >> } >> >> @HTTPMethod >> public void doNothing() >> { >> System.out.println("OTHERS"); >> }| >> >> } >> >> Now as I said, it works, but I'm sure that the abstract class >> and it's >> implementation have something missing so that they glue >> correctly. So my >> question is two fold: >> >> 1) Is there a better / proper way to filter HTTP requests in >> Undertow? >> 2) What is the correct way of using annotations correctly >> correctly in >> the above case? >> >> Thanks >> >> >> _________________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/__mailman/listinfo/undertow-dev >> >> >> >> > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From miere.teixeira at gmail.com Fri Sep 26 09:13:11 2014 From: miere.teixeira at gmail.com (Miere Teixeira) Date: Fri, 26 Sep 2014 10:13:11 -0300 Subject: [undertow-dev] Could not handle the same URL to GET and POST with RoutingHandler In-Reply-To: References: Message-ID: up On Thu, Sep 25, 2014 at 7:39 AM, Miere Teixeira wrote: > Hi Devs, > > I'm facing a new situation with RoutingHandler. I have two HttpHandler's, > one responsible to retrieve all users registered in my database. The second > one is responsible to include an user into my database. > > Both handler was registered with RoutingHandler, both registered with > '/users/' URL but the first one registered for GET and the second for POST. > > After upgrade to 1.1.0.Beta7 version, this behavior was broken and throws > the exception described bellow. > > I've made this simple unit test that simulates the same error when running > in 1.1.0.Beta7, but works perfectly in 1.1.0.Beta6. > https://gist.github.com/miere/3ef15b916cdaaae1896c > > Let me know if it is a bug or the wrong way to achieve this goal. Also, > let me know if I could in some way. > > Miere > -- > > java.lang.IllegalStateException: UT000071: Cannot add path template > /sameurl, matcher already contains an equivalent pattern /sameurl > at > io.undertow.util.PathTemplateMatcher.add(PathTemplateMatcher.java:112) > at > io.undertow.util.PathTemplateMatcher.add(PathTemplateMatcher.java:148) > at io.undertow.server.RoutingHandler.add(RoutingHandler.java:112) > at io.undertow.server.RoutingHandler.add(RoutingHandler.java:99) > at > kikaha.core.RoutingHandlerTest.ensureItsPossibleToHandlePostAndGetToSameURL(RoutingHandlerTest.java:16) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140926/bd159395/attachment-0001.html From bill at dartalley.com Fri Sep 26 10:19:03 2014 From: bill at dartalley.com (Bill O'Neil) Date: Fri, 26 Sep 2014 10:19:03 -0400 Subject: [undertow-dev] Could not handle the same URL to GET and POST with RoutingHandler In-Reply-To: References: Message-ID: Hi Miere, I think this is related to the issue you reported back in June that we talked about. At the following line trailing /'s are being stripped from PathTemplates. This causes it to compare /sameurl to /sameurl/ which does not match. https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/util/PathTemplateMatcher.java#L207 Here is the ticket showing when the behavior changed and that it should be fixed. https://issues.jboss.org/browse/UNDERTOW-267 If you remove the trailing slash from the first two urls it will work, however that is not really a fix. On Fri, Sep 26, 2014 at 9:13 AM, Miere Teixeira wrote: > up > > On Thu, Sep 25, 2014 at 7:39 AM, Miere Teixeira > wrote: > >> Hi Devs, >> >> I'm facing a new situation with RoutingHandler. I have two HttpHandler's, >> one responsible to retrieve all users registered in my database. The second >> one is responsible to include an user into my database. >> >> Both handler was registered with RoutingHandler, both registered with >> '/users/' URL but the first one registered for GET and the second for POST. >> >> After upgrade to 1.1.0.Beta7 version, this behavior was broken and throws >> the exception described bellow. >> >> I've made this simple unit test that simulates the same error when >> running in 1.1.0.Beta7, but works perfectly in 1.1.0.Beta6. >> https://gist.github.com/miere/3ef15b916cdaaae1896c >> >> Let me know if it is a bug or the wrong way to achieve this goal. Also, >> let me know if I could in some way. >> >> Miere >> -- >> >> java.lang.IllegalStateException: UT000071: Cannot add path template >> /sameurl, matcher already contains an equivalent pattern /sameurl >> at >> io.undertow.util.PathTemplateMatcher.add(PathTemplateMatcher.java:112) >> at >> io.undertow.util.PathTemplateMatcher.add(PathTemplateMatcher.java:148) >> at io.undertow.server.RoutingHandler.add(RoutingHandler.java:112) >> at io.undertow.server.RoutingHandler.add(RoutingHandler.java:99) >> at >> kikaha.core.RoutingHandlerTest.ensureItsPossibleToHandlePostAndGetToSameURL(RoutingHandlerTest.java:16) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:606) >> at >> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) >> at >> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) >> at >> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) >> at >> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) >> at >> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) >> at >> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) >> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) >> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) >> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:300) >> at >> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) >> at >> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) >> >> >> > > _______________________________________________ > 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/20140926/f4d51c3f/attachment.html From marcos.asgarcia at gmail.com Fri Sep 26 10:19:56 2014 From: marcos.asgarcia at gmail.com (Marcos Garcia) Date: Fri, 26 Sep 2014 16:19:56 +0200 Subject: [undertow-dev] Could not handle the same URL to GET and POST with RoutingHandler Message-ID: Hey guys, I was just looking into the same issue. Anyone have any ideas? Marcos Garcia Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140926/3a1cf73b/attachment.html From bill at dartalley.com Fri Sep 26 10:23:54 2014 From: bill at dartalley.com (Bill O'Neil) Date: Fri, 26 Sep 2014 10:23:54 -0400 Subject: [undertow-dev] Could not handle the same URL to GET and POST with RoutingHandler In-Reply-To: References: Message-ID: Actually my commit here probably broke the current behavior but I think it is related to trailing slashes. https://github.com/undertow-io/undertow/commit/f0cef748edf8a25245ddb745832da2beac8d9ec3#diff-9cceccd755f4dab058534fd7efa3549f On Fri, Sep 26, 2014 at 10:19 AM, Bill O'Neil wrote: > Hi Miere, > > I think this is related to the issue you reported back in June that we > talked about. At the following line trailing /'s are being stripped from > PathTemplates. This causes it to compare /sameurl to /sameurl/ which does > not match. > > > https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/util/PathTemplateMatcher.java#L207 > > Here is the ticket showing when the behavior changed and that it should be > fixed. https://issues.jboss.org/browse/UNDERTOW-267 > > If you remove the trailing slash from the first two urls it will work, > however that is not really a fix. > > On Fri, Sep 26, 2014 at 9:13 AM, Miere Teixeira > wrote: > >> up >> >> On Thu, Sep 25, 2014 at 7:39 AM, Miere Teixeira > > wrote: >> >>> Hi Devs, >>> >>> I'm facing a new situation with RoutingHandler. I have two >>> HttpHandler's, one responsible to retrieve all users registered in my >>> database. The second one is responsible to include an user into my database. >>> >>> Both handler was registered with RoutingHandler, both registered with >>> '/users/' URL but the first one registered for GET and the second for POST. >>> >>> After upgrade to 1.1.0.Beta7 version, this behavior was broken and >>> throws the exception described bellow. >>> >>> I've made this simple unit test that simulates the same error when >>> running in 1.1.0.Beta7, but works perfectly in 1.1.0.Beta6. >>> https://gist.github.com/miere/3ef15b916cdaaae1896c >>> >>> Let me know if it is a bug or the wrong way to achieve this goal. Also, >>> let me know if I could in some way. >>> >>> Miere >>> -- >>> >>> java.lang.IllegalStateException: UT000071: Cannot add path template >>> /sameurl, matcher already contains an equivalent pattern /sameurl >>> at >>> io.undertow.util.PathTemplateMatcher.add(PathTemplateMatcher.java:112) >>> at >>> io.undertow.util.PathTemplateMatcher.add(PathTemplateMatcher.java:148) >>> at io.undertow.server.RoutingHandler.add(RoutingHandler.java:112) >>> at io.undertow.server.RoutingHandler.add(RoutingHandler.java:99) >>> at >>> kikaha.core.RoutingHandlerTest.ensureItsPossibleToHandlePostAndGetToSameURL(RoutingHandlerTest.java:16) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:606) >>> at >>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) >>> at >>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) >>> at >>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) >>> at >>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) >>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) >>> at >>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) >>> at >>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) >>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) >>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) >>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) >>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) >>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:300) >>> at >>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) >>> at >>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >>> at >>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) >>> at >>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) >>> at >>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) >>> at >>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) >>> >>> >>> >> >> _______________________________________________ >> 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/20140926/956947e6/attachment.html From miere.teixeira at gmail.com Fri Sep 26 12:01:56 2014 From: miere.teixeira at gmail.com (Miere Teixeira) Date: Fri, 26 Sep 2014 13:01:56 -0300 Subject: [undertow-dev] Could not handle the same URL to GET and POST with RoutingHandler In-Reply-To: References: Message-ID: Hi Bill, Thanks for your answer. I did test the same behavior without trailling slashes and it worked. So, to avoid this issue, should I remove the trailling slash before register the route? On Fri, Sep 26, 2014 at 11:19 AM, Bill O'Neil wrote: > Hi Miere, > > I think this is related to the issue you reported back in June that we > talked about. At the following line trailing /'s are being stripped from > PathTemplates. This causes it to compare /sameurl to /sameurl/ which does > not match. > > > https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/util/PathTemplateMatcher.java#L207 > > Here is the ticket showing when the behavior changed and that it should be > fixed. https://issues.jboss.org/browse/UNDERTOW-267 > > If you remove the trailing slash from the first two urls it will work, > however that is not really a fix. > > On Fri, Sep 26, 2014 at 9:13 AM, Miere Teixeira > wrote: > >> up >> >> On Thu, Sep 25, 2014 at 7:39 AM, Miere Teixeira > > wrote: >> >>> Hi Devs, >>> >>> I'm facing a new situation with RoutingHandler. I have two >>> HttpHandler's, one responsible to retrieve all users registered in my >>> database. The second one is responsible to include an user into my database. >>> >>> Both handler was registered with RoutingHandler, both registered with >>> '/users/' URL but the first one registered for GET and the second for POST. >>> >>> After upgrade to 1.1.0.Beta7 version, this behavior was broken and >>> throws the exception described bellow. >>> >>> I've made this simple unit test that simulates the same error when >>> running in 1.1.0.Beta7, but works perfectly in 1.1.0.Beta6. >>> https://gist.github.com/miere/3ef15b916cdaaae1896c >>> >>> Let me know if it is a bug or the wrong way to achieve this goal. Also, >>> let me know if I could in some way. >>> >>> Miere >>> -- >>> >>> java.lang.IllegalStateException: UT000071: Cannot add path template >>> /sameurl, matcher already contains an equivalent pattern /sameurl >>> at >>> io.undertow.util.PathTemplateMatcher.add(PathTemplateMatcher.java:112) >>> at >>> io.undertow.util.PathTemplateMatcher.add(PathTemplateMatcher.java:148) >>> at io.undertow.server.RoutingHandler.add(RoutingHandler.java:112) >>> at io.undertow.server.RoutingHandler.add(RoutingHandler.java:99) >>> at >>> kikaha.core.RoutingHandlerTest.ensureItsPossibleToHandlePostAndGetToSameURL(RoutingHandlerTest.java:16) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:606) >>> at >>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) >>> at >>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) >>> at >>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) >>> at >>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) >>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) >>> at >>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) >>> at >>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) >>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) >>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) >>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) >>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) >>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:300) >>> at >>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) >>> at >>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >>> at >>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) >>> at >>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) >>> at >>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) >>> at >>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) >>> >>> >>> >> >> _______________________________________________ >> 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/20140926/2603b0c5/attachment-0001.html From mclarkson at eyeota.com Fri Sep 26 05:23:53 2014 From: mclarkson at eyeota.com (Matt Clarkson) Date: Fri, 26 Sep 2014 17:23:53 +0800 Subject: [undertow-dev] Tracing HTTP Response content Message-ID: Hi, I'd like to be able to dump Response content as a string to my logger when tracing. I'm guessing something related to HttpServerExchange.getResponseChannel()... but not sure where to go from there. thanks! Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140926/8ad8f591/attachment.html From sdouglas at redhat.com Sun Sep 28 16:36:53 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 29 Sep 2014 06:36:53 +1000 Subject: [undertow-dev] Tracing HTTP Response content In-Reply-To: References: Message-ID: <54287165.6080900@redhat.com> We have io.undertow.server.handlers.RequestDumpingHandler, but that does not dump the response content, just all headers etc. If you file JIRA I can expand it to optionally dump the response content as well. Basically it needs to call HttpServerExchange.addResponseWrapper() and add a conduit that dumps the request. Stuart Matt Clarkson wrote: > Hi, > > I'd like to be able to dump Response content as a string to my logger > when tracing. I'm guessing something related to > HttpServerExchange.getResponseChannel()... but not sure where to go from > there. > > thanks! > > Matt > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev