From espina.edgar at gmail.com Sun Mar 1 19:45:27 2015 From: espina.edgar at gmail.com (Edgar Espina) Date: Sun, 1 Mar 2015 21:45:27 -0300 Subject: [undertow-dev] setting a bufferSize Message-ID: Hi, I found some issues will setting the bufferSize: 1) bufferSize isn't exactly the max number of bytes of a response body. For example, bufferSize=5 with a "hello" response failed with a byte overflow error. That's bc undertow requires some extra bytes for response headers and others. This is not necessarily wrong but a response/buffer size is usually the max number of bytes for the HTTP body (jetty, netty, others). It is something minor, but will be nice to change this to represent the max size of the HTTP body. 2) bufferSize is ignored when Content-Length is set. Here are some logs from Apache HTTP client calling Undertow and Jetty with a buffer size of 20 bytes. Undertow: output size is 40bytes, buffer size is 20 bytes 2015/03/01 21:30:32:053 ART [DEBUG] wire - http-outgoing-0 >> "GET /?data= *ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMN*&len=40 HTTP/1.1[\r][\n]" 2015/03/01 21:30:32:053 ART [DEBUG] wire - http-outgoing-0 >> "Host: localhost:54697[\r][\n]" 2015/03/01 21:30:32:053 ART [DEBUG] wire - http-outgoing-0 >> "Connection: Keep-Alive[\r][\n]" 2015/03/01 21:30:32:054 ART [DEBUG] wire - http-outgoing-0 >> "User-Agent: Apache-HttpClient/4.4-beta1 (Java 1.5 minimum; Java/1.8.0)[\r][\n]" 2015/03/01 21:30:32:054 ART [DEBUG] wire - http-outgoing-0 >> "Accept-Encoding: gzip,deflate[\r][\n]" 2015/03/01 21:30:32:054 ART [DEBUG] wire - http-outgoing-0 >> "[\r][\n]" 2015/03/01 21:30:32:120 ART [DEBUG] wire - http-outgoing-0 << "HTTP/1.1 200 OK[\r][\n]" 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << "Content-Type: text/html;charset=UTF-8[\r][\n]" 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << "Content-Length: 40[\r][\n]" 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << "Date: Mon, 02 Mar 2015 00:30:32 GMT[\r][\n]" 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << "[\r][\n]" 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << " *ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMN*" Jetty: output size is 40bytes, buffer size is 20 bytes 2015/03/01 21:33:07:956 ART [DEBUG] wire - http-outgoing-1 >> "GET /?data= *ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMN*&len=40 HTTP/1.1[\r][\n]" 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> "Host: localhost:54732[\r][\n]" 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> "Connection: Keep-Alive[\r][\n]" 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> "User-Agent: Apache-HttpClient/4.4-beta1 (Java 1.5 minimum; Java/1.8.0)[\r][\n]" 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> "Accept-Encoding: gzip,deflate[\r][\n]" 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> "[\r][\n]" 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << "HTTP/1.1 200 OK[\r][\n]" 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << "Content-Type: text/html;charset=UTF-8[\r][\n]" 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << "Content-Length: 40[\r][\n]" 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << "[\r][\n]" 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << " *ABCDEFGHIJKLMNOPQRST*" 2015/03/01 21:33:07:959 ART [DEBUG] headers - http-outgoing-1 << HTTP/1.1 200 OK 2015/03/01 21:33:07:959 ART [DEBUG] headers - http-outgoing-1 << Content-Type: text/html;charset=UTF-8 2015/03/01 21:33:07:959 ART [DEBUG] headers - http-outgoing-1 << Content-Length: 40 2015/03/01 21:33:07:960 ART [DEBUG] MainClientExec - Connection can be kept alive indefinitely 2015/03/01 21:33:07:960 ART [DEBUG] wire - http-outgoing-1 << " *UVWXYZABCDEFGHIJKLMN*" As you can see, undertow seems to ignore the bufferSize option and it sends the whole output at once, while jetty sent two chunks of 20 bytes each. BufferSize work when Transfer-Encoding: Chunked is set, but ignored when Content-Length is set. I didn't try with larger files but this makes me worry bc I think sending a large file and setting Content-Length might result in an OOM error. Found this in latest beta release: 1.2.0beta8 using exchange.getOutputStream (blocking mode) Thanks -- edgar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150301/e219d743/attachment-0001.html From sdouglas at redhat.com Sun Mar 1 23:17:32 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 1 Mar 2015 23:17:32 -0500 (EST) Subject: [undertow-dev] setting a bufferSize In-Reply-To: References: Message-ID: <560157348.23807206.1425269852914.JavaMail.zimbra@redhat.com> I think you have misunderstood the point of the servlet output buffer. Basically the bufferSize parameter is the size of the servlets output buffer, it controls how much content can be written to the output stream before Undertow will start to send the data to the client. It does not provide any sort of maximum limit on the size, and it does not control the maximum write size (as in some situations we will write additional data using a gathering write). For example if you call setBufferSize(5), then write "Hi" to the output stream nothing will be sent to the client, as the response fits in the buffer, if you try and write "Hello World" then the response will be flushed, as the response is larger than 5 bytes and cannot be fully buffered. In this case though Undertow will not split the message into 5 byte chunks, instead anything that overflows will be copied into a pooled buffer and written out using a gathering write for maximum performance. Undertow does not allocate arbitrary large amounts of memory for large responses (although note that in order to send the larger response in one write() call your application has to have allocated a byte array of that size). In general the only parameter you should change is the size of Undertow's internal buffer pool, and you should never call setBufferSize() unless you have a very specific reason (namely you want to fully buffer a response that is larger than the default buffer size). Stuart ----- Original Message ----- > From: "Edgar Espina" > To: undertow-dev at lists.jboss.org > Sent: Monday, 2 March, 2015 11:45:27 AM > Subject: [undertow-dev] setting a bufferSize > > Hi, > > I found some issues will setting the bufferSize: > > 1) bufferSize isn't exactly the max number of bytes of a response body. For > example, bufferSize=5 with a "hello" response failed with a byte overflow > error. That's bc undertow requires some extra bytes for response headers and > others. This is not necessarily wrong but a response/buffer size is usually > the max number of bytes for the HTTP body (jetty, netty, others). It is > something minor, but will be nice to change this to represent the max size > of the HTTP body. > > 2) bufferSize is ignored when Content-Length is set. Here are some logs from > Apache HTTP client calling Undertow and Jetty with a buffer size of 20 > bytes. > > Undertow: output size is 40bytes, buffer size is 20 bytes > 2015/03/01 21:30:32:053 ART [DEBUG] wire - http-outgoing-0 >> "GET /?data= > ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMN &len=40 HTTP/1.1[\r][\n]" > 2015/03/01 21:30:32:053 ART [DEBUG] wire - http-outgoing-0 >> "Host: > localhost:54697[\r][\n]" > 2015/03/01 21:30:32:053 ART [DEBUG] wire - http-outgoing-0 >> "Connection: > Keep-Alive[\r][\n]" > 2015/03/01 21:30:32:054 ART [DEBUG] wire - http-outgoing-0 >> "User-Agent: > Apache-HttpClient/4.4-beta1 (Java 1.5 minimum; Java/1.8.0)[\r][\n]" > 2015/03/01 21:30:32:054 ART [DEBUG] wire - http-outgoing-0 >> > "Accept-Encoding: gzip,deflate[\r][\n]" > 2015/03/01 21:30:32:054 ART [DEBUG] wire - http-outgoing-0 >> "[\r][\n]" > 2015/03/01 21:30:32:120 ART [DEBUG] wire - http-outgoing-0 << "HTTP/1.1 200 > OK[\r][\n]" > 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << "Content-Type: > text/html;charset=UTF-8[\r][\n]" > 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << > "Content-Length: 40[\r][\n]" > 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << "Date: Mon, 02 > Mar 2015 00:30:32 GMT[\r][\n]" > 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << "[\r][\n]" > 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << " > ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMN " > > Jetty: output size is 40bytes, buffer size is 20 bytes > 2015/03/01 21:33:07:956 ART [DEBUG] wire - http-outgoing-1 >> "GET /?data= > ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMN &len=40 HTTP/1.1[\r][\n]" > 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> "Host: > localhost:54732[\r][\n]" > 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> "Connection: > Keep-Alive[\r][\n]" > 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> "User-Agent: > Apache-HttpClient/4.4-beta1 (Java 1.5 minimum; Java/1.8.0)[\r][\n]" > 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> > "Accept-Encoding: gzip,deflate[\r][\n]" > 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> "[\r][\n]" > 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << "HTTP/1.1 200 > OK[\r][\n]" > 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << "Content-Type: > text/html;charset=UTF-8[\r][\n]" > 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << > "Content-Length: 40[\r][\n]" > 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << "[\r][\n]" > 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << " > ABCDEFGHIJKLMNOPQRST " > 2015/03/01 21:33:07:959 ART [DEBUG] headers - http-outgoing-1 << HTTP/1.1 200 > OK > 2015/03/01 21:33:07:959 ART [DEBUG] headers - http-outgoing-1 << > Content-Type: text/html;charset=UTF-8 > 2015/03/01 21:33:07:959 ART [DEBUG] headers - http-outgoing-1 << > Content-Length: 40 > 2015/03/01 21:33:07:960 ART [DEBUG] MainClientExec - Connection can be kept > alive indefinitely > 2015/03/01 21:33:07:960 ART [DEBUG] wire - http-outgoing-1 << " > UVWXYZABCDEFGHIJKLMN " > > > As you can see, undertow seems to ignore the bufferSize option and it sends > the whole output at once, while jetty sent two chunks of 20 bytes each. > > BufferSize work when Transfer-Encoding: Chunked is set, but ignored when > Content-Length is set. I didn't try with larger files but this makes me > worry bc I think sending a large file and setting Content-Length might > result in an OOM error. > > Found this in latest beta release: 1.2.0beta8 using exchange.getOutputStream > (blocking mode) > > Thanks > > > -- > edgar > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From espina.edgar at gmail.com Mon Mar 2 07:30:05 2015 From: espina.edgar at gmail.com (Edgar Espina) Date: Mon, 2 Mar 2015 09:30:05 -0300 Subject: [undertow-dev] setting a bufferSize In-Reply-To: <560157348.23807206.1425269852914.JavaMail.zimbra@redhat.com> References: <560157348.23807206.1425269852914.JavaMail.zimbra@redhat.com> Message-ID: Hi, Got this when using Undertow.Builder.setBufferSize, sorry for not being clear in my previous email. You mentioned that undertow won't split into two chunks of 5 bytes and overflows will use a pooled buffer... but now how/when undertow decided to send and flush data? Is there a config parameter? Thought it was Undertow.Builder.setBufferSize. Thanks. On Mon, Mar 2, 2015 at 1:17 AM, Stuart Douglas wrote: > I think you have misunderstood the point of the servlet output buffer. > > Basically the bufferSize parameter is the size of the servlets output > buffer, it controls how much content can be written to the output stream > before Undertow will start to send the data to the client. It does not > provide any sort of maximum limit on the size, and it does not control the > maximum write size (as in some situations we will write additional data > using a gathering write). > > For example if you call setBufferSize(5), then write "Hi" to the output > stream nothing will be sent to the client, as the response fits in the > buffer, if you try and write "Hello World" then the response will be > flushed, as the response is larger than 5 bytes and cannot be fully > buffered. In this case though Undertow will not split the message into 5 > byte chunks, instead anything that overflows will be copied into a pooled > buffer and written out using a gathering write for maximum performance. > > Undertow does not allocate arbitrary large amounts of memory for large > responses (although note that in order to send the larger response in one > write() call your application has to have allocated a byte array of that > size). > > In general the only parameter you should change is the size of Undertow's > internal buffer pool, and you should never call setBufferSize() unless you > have a very specific reason (namely you want to fully buffer a response > that is larger than the default buffer size). > > Stuart > > > > ----- Original Message ----- > > From: "Edgar Espina" > > To: undertow-dev at lists.jboss.org > > Sent: Monday, 2 March, 2015 11:45:27 AM > > Subject: [undertow-dev] setting a bufferSize > > > > Hi, > > > > I found some issues will setting the bufferSize: > > > > 1) bufferSize isn't exactly the max number of bytes of a response body. > For > > example, bufferSize=5 with a "hello" response failed with a byte overflow > > error. That's bc undertow requires some extra bytes for response headers > and > > others. This is not necessarily wrong but a response/buffer size is > usually > > the max number of bytes for the HTTP body (jetty, netty, others). It is > > something minor, but will be nice to change this to represent the max > size > > of the HTTP body. > > > > 2) bufferSize is ignored when Content-Length is set. Here are some logs > from > > Apache HTTP client calling Undertow and Jetty with a buffer size of 20 > > bytes. > > > > Undertow: output size is 40bytes, buffer size is 20 bytes > > 2015/03/01 21:30:32:053 ART [DEBUG] wire - http-outgoing-0 >> "GET > /?data= > > ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMN &len=40 HTTP/1.1[\r][\n]" > > 2015/03/01 21:30:32:053 ART [DEBUG] wire - http-outgoing-0 >> "Host: > > localhost:54697[\r][\n]" > > 2015/03/01 21:30:32:053 ART [DEBUG] wire - http-outgoing-0 >> > "Connection: > > Keep-Alive[\r][\n]" > > 2015/03/01 21:30:32:054 ART [DEBUG] wire - http-outgoing-0 >> > "User-Agent: > > Apache-HttpClient/4.4-beta1 (Java 1.5 minimum; Java/1.8.0)[\r][\n]" > > 2015/03/01 21:30:32:054 ART [DEBUG] wire - http-outgoing-0 >> > > "Accept-Encoding: gzip,deflate[\r][\n]" > > 2015/03/01 21:30:32:054 ART [DEBUG] wire - http-outgoing-0 >> "[\r][\n]" > > 2015/03/01 21:30:32:120 ART [DEBUG] wire - http-outgoing-0 << "HTTP/1.1 > 200 > > OK[\r][\n]" > > 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << > "Content-Type: > > text/html;charset=UTF-8[\r][\n]" > > 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << > > "Content-Length: 40[\r][\n]" > > 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << "Date: > Mon, 02 > > Mar 2015 00:30:32 GMT[\r][\n]" > > 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << "[\r][\n]" > > 2015/03/01 21:30:32:122 ART [DEBUG] wire - http-outgoing-0 << " > > ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMN " > > > > Jetty: output size is 40bytes, buffer size is 20 bytes > > 2015/03/01 21:33:07:956 ART [DEBUG] wire - http-outgoing-1 >> "GET > /?data= > > ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMN &len=40 HTTP/1.1[\r][\n]" > > 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> "Host: > > localhost:54732[\r][\n]" > > 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> > "Connection: > > Keep-Alive[\r][\n]" > > 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> > "User-Agent: > > Apache-HttpClient/4.4-beta1 (Java 1.5 minimum; Java/1.8.0)[\r][\n]" > > 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> > > "Accept-Encoding: gzip,deflate[\r][\n]" > > 2015/03/01 21:33:07:957 ART [DEBUG] wire - http-outgoing-1 >> "[\r][\n]" > > 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << "HTTP/1.1 > 200 > > OK[\r][\n]" > > 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << > "Content-Type: > > text/html;charset=UTF-8[\r][\n]" > > 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << > > "Content-Length: 40[\r][\n]" > > 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << "[\r][\n]" > > 2015/03/01 21:33:07:959 ART [DEBUG] wire - http-outgoing-1 << " > > ABCDEFGHIJKLMNOPQRST " > > 2015/03/01 21:33:07:959 ART [DEBUG] headers - http-outgoing-1 << > HTTP/1.1 200 > > OK > > 2015/03/01 21:33:07:959 ART [DEBUG] headers - http-outgoing-1 << > > Content-Type: text/html;charset=UTF-8 > > 2015/03/01 21:33:07:959 ART [DEBUG] headers - http-outgoing-1 << > > Content-Length: 40 > > 2015/03/01 21:33:07:960 ART [DEBUG] MainClientExec - Connection can be > kept > > alive indefinitely > > 2015/03/01 21:33:07:960 ART [DEBUG] wire - http-outgoing-1 << " > > UVWXYZABCDEFGHIJKLMN " > > > > > > As you can see, undertow seems to ignore the bufferSize option and it > sends > > the whole output at once, while jetty sent two chunks of 20 bytes each. > > > > BufferSize work when Transfer-Encoding: Chunked is set, but ignored when > > Content-Length is set. I didn't try with larger files but this makes me > > worry bc I think sending a large file and setting Content-Length might > > result in an OOM error. > > > > Found this in latest beta release: 1.2.0beta8 using > exchange.getOutputStream > > (blocking mode) > > > > Thanks > > > > > > -- > > edgar > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > -- edgar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150302/6faf6582/attachment.html From cvandera at andrew.cmu.edu Mon Mar 2 19:15:59 2015 From: cvandera at andrew.cmu.edu (Chryssanthi Vandera) Date: Mon, 2 Mar 2015 19:15:59 -0500 Subject: [undertow-dev] Undertow High Performance Message-ID: <1ACB709E-A231-4CF3-A035-5289855AA7CA@andrew.cmu.edu> Hello, I am a graduate student working on an assignment and I am using undertow. My assignment has a performance goal (requests per second) and I am trying to configure undertow to perform better to achieve this goal. I read in the documentation about the number of IO threads as well as the number of Worker threads but I haven?t understood the relation between each other apparently, because when I tweak this configuration I get worse results? Could you please help me understand what are the factors of undertow performing faster? Is it just those two or I can change some other configuration to make it serve more requests per sec. Thank you, Chrysanthi Vandera From sdouglas at redhat.com Mon Mar 2 22:38:41 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 2 Mar 2015 22:38:41 -0500 (EST) Subject: [undertow-dev] Undertow High Performance In-Reply-To: <1ACB709E-A231-4CF3-A035-5289855AA7CA@andrew.cmu.edu> References: <1ACB709E-A231-4CF3-A035-5289855AA7CA@andrew.cmu.edu> Message-ID: <1660371308.24776762.1425353921529.JavaMail.zimbra@redhat.com> By default Undertow should provide good out of the box defaults for these parameters, for most applications you should not need to adjust them. Can you give more details about what you are trying to achieve? In particular: - How many requests/sec do you need to get? - How many are you getting now? - What does your handler do? - Are you using blocking IO or Servlet? Stuart ----- Original Message ----- > From: "Chryssanthi Vandera" > To: undertow-dev at lists.jboss.org > Sent: Tuesday, 3 March, 2015 11:15:59 AM > Subject: [undertow-dev] Undertow High Performance > > Hello, > > I am a graduate student working on an assignment and I am using undertow. > > My assignment has a performance goal (requests per second) and I am trying to > configure undertow to perform better to achieve this goal. > > I read in the documentation about the number of IO threads as well as the > number of Worker threads but I haven?t understood the relation between each > other apparently, because when I tweak this configuration I get worse > results? > > Could you please help me understand what are the factors of undertow > performing faster? Is it just those two or I can change some other > configuration to make it serve more requests per sec. > > Thank you, > Chrysanthi Vandera > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From bburke at redhat.com Wed Mar 4 10:21:26 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 04 Mar 2015 10:21:26 -0500 Subject: [undertow-dev] problem with root url redirects Message-ID: <54F722F6.7070805@redhat.com> Looking at Wildfly 8.2.0, 1. I'm sending a POST to /app 2. Wildfly redirects to /app/ via a 302 3. Browser does a GET /app/ Form data is lost. Why does Wildfly do a redirect? This has caused me a lot of problems for our SAML adapter as users have to remember to put a trailing '/' in their registration URLs. If you insist on doing a redirect, why not send a 307 instead if it is a non-GET request? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From jason.greene at redhat.com Wed Mar 4 11:13:11 2015 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 4 Mar 2015 10:13:11 -0600 Subject: [undertow-dev] problem with root url redirects In-Reply-To: <54F722F6.7070805@redhat.com> References: <54F722F6.7070805@redhat.com> Message-ID: <8AA22A2B-CDB0-4700-833C-F2F103CE0C12@redhat.com> Hmm not sure why. A quick search shows we send a 302 as part of the form auth process, but I assume this isn?t form auth? Could it be servlet code calling sendRedirect()? That is required to send a 302. > On Mar 4, 2015, at 9:21 AM, Bill Burke wrote: > > Looking at Wildfly 8.2.0, > > 1. I'm sending a POST to /app > 2. Wildfly redirects to /app/ via a 302 > 3. Browser does a GET /app/ > > Form data is lost. > > Why does Wildfly do a redirect? This has caused me a lot of problems > for our SAML adapter as users have to remember to put a trailing '/' in > their registration URLs. > > If you insist on doing a redirect, why not send a 307 instead if it is a > non-GET request? > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From bburke at redhat.com Wed Mar 4 11:20:28 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 04 Mar 2015 11:20:28 -0500 Subject: [undertow-dev] problem with root url redirects In-Reply-To: <8AA22A2B-CDB0-4700-833C-F2F103CE0C12@redhat.com> References: <54F722F6.7070805@redhat.com> <8AA22A2B-CDB0-4700-833C-F2F103CE0C12@redhat.com> Message-ID: <54F730CC.8080108@redhat.com> I'm pretty sure the 302 happens prior to any auth code being called if you hit the root context of the WAR without a trailing '/'. This is something Stuart and I talked about before. On 3/4/2015 11:13 AM, Jason Greene wrote: > Hmm not sure why. A quick search shows we send a 302 as part of the form auth process, but I assume this isn?t form auth? > > Could it be servlet code calling sendRedirect()? That is required to send a 302. > >> On Mar 4, 2015, at 9:21 AM, Bill Burke wrote: >> >> Looking at Wildfly 8.2.0, >> >> 1. I'm sending a POST to /app >> 2. Wildfly redirects to /app/ via a 302 >> 3. Browser does a GET /app/ >> >> Form data is lost. >> >> Why does Wildfly do a redirect? This has caused me a lot of problems >> for our SAML adapter as users have to remember to put a trailing '/' in >> their registration URLs. >> >> If you insist on doing a redirect, why not send a 307 instead if it is a >> non-GET request? >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From jason.greene at redhat.com Wed Mar 4 11:42:47 2015 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 4 Mar 2015 10:42:47 -0600 Subject: [undertow-dev] problem with root url redirects In-Reply-To: <54F730CC.8080108@redhat.com> References: <54F722F6.7070805@redhat.com> <8AA22A2B-CDB0-4700-833C-F2F103CE0C12@redhat.com> <54F730CC.8080108@redhat.com> Message-ID: Ah yes not sure how my search didn?t miss that its: https://issues.jboss.org/browse/UNDERTOW-89 I agree we should switch that to a 307 > On Mar 4, 2015, at 10:20 AM, Bill Burke wrote: > > I'm pretty sure the 302 happens prior to any auth code being called if you hit the root context of the WAR without a trailing '/'. This is something Stuart and I talked about before. > > > On 3/4/2015 11:13 AM, Jason Greene wrote: >> Hmm not sure why. A quick search shows we send a 302 as part of the form auth process, but I assume this isn?t form auth? >> >> Could it be servlet code calling sendRedirect()? That is required to send a 302. >> >>> On Mar 4, 2015, at 9:21 AM, Bill Burke wrote: >>> >>> Looking at Wildfly 8.2.0, >>> >>> 1. I'm sending a POST to /app >>> 2. Wildfly redirects to /app/ via a 302 >>> 3. Browser does a GET /app/ >>> >>> Form data is lost. >>> >>> Why does Wildfly do a redirect? This has caused me a lot of problems >>> for our SAML adapter as users have to remember to put a trailing '/' in >>> their registration URLs. >>> >>> If you insist on doing a redirect, why not send a 307 instead if it is a >>> non-GET request? >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From bburke at redhat.com Wed Mar 4 11:57:03 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 04 Mar 2015 11:57:03 -0500 Subject: [undertow-dev] problem with root url redirects In-Reply-To: References: <54F722F6.7070805@redhat.com> <8AA22A2B-CDB0-4700-833C-F2F103CE0C12@redhat.com> <54F730CC.8080108@redhat.com> Message-ID: <54F7395F.2050903@redhat.com> https://issues.jboss.org/browse/UNDERTOW-404 On 3/4/2015 11:42 AM, Jason Greene wrote: > Ah yes not sure how my search didn?t miss that its: > > https://issues.jboss.org/browse/UNDERTOW-89 > > I agree we should switch that to a 307 > >> On Mar 4, 2015, at 10:20 AM, Bill Burke wrote: >> >> I'm pretty sure the 302 happens prior to any auth code being called if you hit the root context of the WAR without a trailing '/'. This is something Stuart and I talked about before. >> >> >> On 3/4/2015 11:13 AM, Jason Greene wrote: >>> Hmm not sure why. A quick search shows we send a 302 as part of the form auth process, but I assume this isn?t form auth? >>> >>> Could it be servlet code calling sendRedirect()? That is required to send a 302. >>> >>>> On Mar 4, 2015, at 9:21 AM, Bill Burke wrote: >>>> >>>> Looking at Wildfly 8.2.0, >>>> >>>> 1. I'm sending a POST to /app >>>> 2. Wildfly redirects to /app/ via a 302 >>>> 3. Browser does a GET /app/ >>>> >>>> Form data is lost. >>>> >>>> Why does Wildfly do a redirect? This has caused me a lot of problems >>>> for our SAML adapter as users have to remember to put a trailing '/' in >>>> their registration URLs. >>>> >>>> If you insist on doing a redirect, why not send a 307 instead if it is a >>>> non-GET request? >>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From jason.greene at redhat.com Wed Mar 4 12:02:04 2015 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 4 Mar 2015 11:02:04 -0600 Subject: [undertow-dev] problem with root url redirects In-Reply-To: <54F7395F.2050903@redhat.com> References: <54F722F6.7070805@redhat.com> <8AA22A2B-CDB0-4700-833C-F2F103CE0C12@redhat.com> <54F730CC.8080108@redhat.com> <54F7395F.2050903@redhat.com> Message-ID: <82FD3C4C-06AA-44D7-B9C5-2EC052C11AEB@redhat.com> Hmm issue not found :) (snare hit, cymbal crash) > On Mar 4, 2015, at 10:57 AM, Bill Burke wrote: > > https://issues.jboss.org/browse/UNDERTOW-404 > > On 3/4/2015 11:42 AM, Jason Greene wrote: >> Ah yes not sure how my search didn?t miss that its: >> >> https://issues.jboss.org/browse/UNDERTOW-89 >> >> I agree we should switch that to a 307 >> >>> On Mar 4, 2015, at 10:20 AM, Bill Burke wrote: >>> >>> I'm pretty sure the 302 happens prior to any auth code being called if you hit the root context of the WAR without a trailing '/'. This is something Stuart and I talked about before. >>> >>> >>> On 3/4/2015 11:13 AM, Jason Greene wrote: >>>> Hmm not sure why. A quick search shows we send a 302 as part of the form auth process, but I assume this isn?t form auth? >>>> >>>> Could it be servlet code calling sendRedirect()? That is required to send a 302. >>>> >>>>> On Mar 4, 2015, at 9:21 AM, Bill Burke wrote: >>>>> >>>>> Looking at Wildfly 8.2.0, >>>>> >>>>> 1. I'm sending a POST to /app >>>>> 2. Wildfly redirects to /app/ via a 302 >>>>> 3. Browser does a GET /app/ >>>>> >>>>> Form data is lost. >>>>> >>>>> Why does Wildfly do a redirect? This has caused me a lot of problems >>>>> for our SAML adapter as users have to remember to put a trailing '/' in >>>>> their registration URLs. >>>>> >>>>> If you insist on doing a redirect, why not send a 307 instead if it is a >>>>> non-GET request? >>>>> >>>>> -- >>>>> Bill Burke >>>>> JBoss, a division of Red Hat >>>>> http://bill.burkecentral.com >>>>> _______________________________________________ >>>>> undertow-dev mailing list >>>>> undertow-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>> >>>> -- >>>> Jason T. Greene >>>> WildFly Lead / JBoss EAP Platform Architect >>>> JBoss, a division of Red Hat >>>> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jsrobin at gmail.com Wed Mar 4 12:32:43 2015 From: jsrobin at gmail.com (John Robinson) Date: Wed, 4 Mar 2015 12:32:43 -0500 Subject: [undertow-dev] SSL client authorization -- how ? Message-ID: What are the detailed configuration instructions to configure "standalone.xml", web.xml, and jboss-web.xml to set up SSL with client authorization? Could someone direct me to the appropriate place to find detailed configuration information on how to have a WildFly 8.2 server evoke from a client, a certificate under SSL. The cerificate, I expect, would be sent via the "javax.servlet.request.X509Certificate" request attribute. If this is an inappropriate forum for this question, please feel free to direct me to the correct forum. Thanks in advance for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150304/b397ed32/attachment.html From bburke at redhat.com Wed Mar 4 12:44:05 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 04 Mar 2015 12:44:05 -0500 Subject: [undertow-dev] problem with root url redirects In-Reply-To: <82FD3C4C-06AA-44D7-B9C5-2EC052C11AEB@redhat.com> References: <54F722F6.7070805@redhat.com> <8AA22A2B-CDB0-4700-833C-F2F103CE0C12@redhat.com> <54F730CC.8080108@redhat.com> <54F7395F.2050903@redhat.com> <82FD3C4C-06AA-44D7-B9C5-2EC052C11AEB@redhat.com> Message-ID: <54F74465.3000506@redhat.com> LOL. On 3/4/2015 12:02 PM, Jason Greene wrote: > Hmm issue not found :) (snare hit, cymbal crash) > >> On Mar 4, 2015, at 10:57 AM, Bill Burke wrote: >> >> https://issues.jboss.org/browse/UNDERTOW-404 >> >> On 3/4/2015 11:42 AM, Jason Greene wrote: >>> Ah yes not sure how my search didn?t miss that its: >>> >>> https://issues.jboss.org/browse/UNDERTOW-89 >>> >>> I agree we should switch that to a 307 >>> >>>> On Mar 4, 2015, at 10:20 AM, Bill Burke wrote: >>>> >>>> I'm pretty sure the 302 happens prior to any auth code being called if you hit the root context of the WAR without a trailing '/'. This is something Stuart and I talked about before. >>>> >>>> >>>> On 3/4/2015 11:13 AM, Jason Greene wrote: >>>>> Hmm not sure why. A quick search shows we send a 302 as part of the form auth process, but I assume this isn?t form auth? >>>>> >>>>> Could it be servlet code calling sendRedirect()? That is required to send a 302. >>>>> >>>>>> On Mar 4, 2015, at 9:21 AM, Bill Burke wrote: >>>>>> >>>>>> Looking at Wildfly 8.2.0, >>>>>> >>>>>> 1. I'm sending a POST to /app >>>>>> 2. Wildfly redirects to /app/ via a 302 >>>>>> 3. Browser does a GET /app/ >>>>>> >>>>>> Form data is lost. >>>>>> >>>>>> Why does Wildfly do a redirect? This has caused me a lot of problems >>>>>> for our SAML adapter as users have to remember to put a trailing '/' in >>>>>> their registration URLs. >>>>>> >>>>>> If you insist on doing a redirect, why not send a 307 instead if it is a >>>>>> non-GET request? >>>>>> >>>>>> -- >>>>>> Bill Burke >>>>>> JBoss, a division of Red Hat >>>>>> http://bill.burkecentral.com >>>>>> _______________________________________________ >>>>>> undertow-dev mailing list >>>>>> undertow-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>>> >>>>> -- >>>>> Jason T. Greene >>>>> WildFly Lead / JBoss EAP Platform Architect >>>>> JBoss, a division of Red Hat >>>>> >>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>> >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sdouglas at redhat.com Thu Mar 5 22:52:03 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 5 Mar 2015 22:52:03 -0500 (EST) Subject: [undertow-dev] SSL client authorization -- how ? In-Reply-To: References: Message-ID: <2137307931.27283889.1425613923980.JavaMail.zimbra@redhat.com> The basic steps are: In standalone.xml Add a HTTPS listener to the undertow subsystem: Add a security realm: Add a security domains to the security subsystem, should be something like this (although it will depend on how you store your user information): - Set the authentication mechanism as CLIENT_CERT in web.xml - In jboss-web.xml specify your security domain: client-cert We are taking steps to simplify this configuration, and unify (and hopefully simplify) all our SSL config, although I am not sure when this will be done. Stuart ----- Original Message ----- > From: "John Robinson" > To: "undertow-dev" > Sent: Thursday, 5 March, 2015 4:32:43 AM > Subject: [undertow-dev] SSL client authorization -- how ? > > What are the detailed configuration instructions to configure > "standalone.xml", web.xml, and jboss-web.xml to set up SSL with client > authorization? > > Could someone direct me to the appropriate place to find detailed > configuration information on how to have a WildFly 8.2 server evoke from a > client, a certificate under SSL. > > The cerificate, I expect, would be sent via the > "javax.servlet.request.X509Certificate" request attribute. > > If this is an inappropriate forum for this question, please feel free to > direct me to the correct forum. > > Thanks in advance for your help. > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From mbarton at itrsgroup.com Fri Mar 6 05:06:54 2015 From: mbarton at itrsgroup.com (Michael Barton) Date: Fri, 6 Mar 2015 10:06:54 +0000 Subject: [undertow-dev] Lost requests when responding from Akka actor system Message-ID: Hi all, I've been using Undertow embedded in an Akka application and it is working great apart from a small issue when running load tests. I've reduced the problem down to a small little demo application which I've attached below. It is in Scala but I can create a Java version if required. I fire one million POST requests at Undertow and almost all succeed, however some never receive a response. The number that fail varies from 1 to 10. Increasing the concurrency on the client and server side together and independently increases the number of failures. I've not yet seen any failures with no concurrency on the server side. The HTTP handler callback is not invoked for the requests that fail. I've verified this by adding a counter before I call exchange.dispatch() and pass it on to the processing actor pool. I don't think I'm doing anything that is not thread-safe since Akka guarantees that actors do not execute concurrently. However the execution of the actor does move around a number of threads in the underlying Fork Join pool and I'm wondering if that would cause issues with Undertow? Any suggestions for how I could debug this? Thanks, Michael Code to reproduce ============== object UndertowTest { def start(handler: HttpHandler) = Undertow.builder() .addHttpListener(8888, "localhost") .setHandler(handler) .build() .start() } class Responder extends HttpHandler { override def handleRequest(exchange: HttpServerExchange): Unit = { exchange.getResponseHeaders.put(io.undertow.util.Headers.CONTENT_TYPE, "text/plain") exchange.getResponseSender.send("Hello world!") } } class RequestHandler extends Actor with Loggable { val handler = new Responder override def receive = { case exchange: HttpServerExchange => handler.handeRequest(exchange) } } object UndertowAkkaTest extends App { val sys = ActorSystem() // Changing the number here changes the number of actors handling incoming requests val handlerPool = sys.actorOf(RoundRobinPool(4).props(Props(classOf[RequestHandler]))) UndertowTest.start(new HttpHandler { override def handleRequest(exchange: HttpServerExchange): Unit = { exchange.dispatch() handlerPool ! exchange } }) } Apache Bench command to test ======================== # -c changes number of concurrent client side requests ab -k -c 4 -n 100000 -p payload.json -T application/json http://localhost:8888/streams/demo/infrastructure/cpu Data in payload.json =============== { "sampleTime": "2015-02-24T06:02:47", "contributor": "3b8da322-ef8f-4f6b-93a3-a171dd794308", "host": "some-host", "process": "some-process", "user": 35.7, "kernel": 12.3 } ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150306/7aee4e3a/attachment.html From sdouglas at redhat.com Sat Mar 7 00:00:31 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Sat, 7 Mar 2015 00:00:31 -0500 (EST) Subject: [undertow-dev] Lost requests when responding from Akka actor system In-Reply-To: References: Message-ID: <839355040.11083.1425704431648.JavaMail.zimbra@redhat.com> It is possible there may be a thread safety issue. When you do the initial dispatch try using the version of dispatch that takes a Runnable and dispatch to Akka in the Runnable. This makes sure that there is only one thread active on the exchange at any time (as Undertow needs to examine some state on the exchange when the call stack initially returns). Stuart ----- Original Message ----- > From: "Michael Barton" > To: undertow-dev at lists.jboss.org > Sent: Friday, 6 March, 2015 9:06:54 PM > Subject: [undertow-dev] Lost requests when responding from Akka actor system > > > > Hi all, > > > > I?ve been using Undertow embedded in an Akka application and it is working > great apart from a small issue when running load tests. > > > > I?ve reduced the problem down to a small little demo application which I?ve > attached below. It is in Scala but I can create a Java version if required. > > > > I fire one million POST requests at Undertow and almost all succeed, however > some never receive a response. The number that fail varies from 1 to 10. > > > > Increasing the concurrency on the client and server side together and > independently increases the number of failures. I?ve not yet seen any > failures with no concurrency on the server side. > > > > The HTTP handler callback is not invoked for the requests that fail. I?ve > verified this by adding a counter before I call exchange.dispatch() and pass > it on to the processing actor pool. > > > > I don?t think I?m doing anything that is not thread-safe since Akka > guarantees that actors do not execute concurrently. However the execution of > the actor does move around a number of threads in the underlying Fork Join > pool and I?m wondering if that would cause issues with Undertow? > > > > Any suggestions for how I could debug this? > > > > Thanks, > > > > Michael > > > > Code to reproduce > > ============== > > > > object UndertowTest { > > def start(handler: HttpHandler) = Undertow.builder() > > .addHttpListener(8888, "localhost") > > .setHandler(handler) > > .build() > > .start() > > } > > > > class Responder extends HttpHandler { > > override def handleRequest(exchange: HttpServerExchange): Unit = { > > exchange.getResponseHeaders.put(io.undertow.util.Headers.CONTENT_TYPE, > "text/plain") > > exchange.getResponseSender.send("Hello world!") > > } > > } > > > > class RequestHandler extends Actor with Loggable { > > val handler = new Responder > > > > override def receive = { > > case exchange: HttpServerExchange => > > handler.handeRequest(exchange) > > } > > } > > > > object UndertowAkkaTest extends App { > > val sys = ActorSystem() > > > > // Changing the number here changes the number of actors handling incoming > requests > > val handlerPool = > sys.actorOf(RoundRobinPool(4).props(Props(classOf[RequestHandler]))) > > > > UndertowTest.start(new HttpHandler { > > override def handleRequest(exchange: HttpServerExchange): Unit = { > > exchange.dispatch() > > handlerPool ! exchange > > } > > }) > > } > > > > Apache Bench command to test > > ======================== > > > > # -c changes number of concurrent client side requests > > ab -k -c 4 -n 100000 -p payload.json -T application/json > http://localhost:8888/streams/demo/infrastructure/cpu > > > > Data in payload.json > > =============== > > > > { > > "sampleTime": "2015-02-24T06:02:47", > > "contributor": "3b8da322-ef8f-4f6b-93a3-a171dd794308", > > "host": "some-host", > > "process": "some-process", > > "user": 35.7, > > "kernel": 12.3 > > } > > > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From jsrobin at gmail.com Sat Mar 7 13:47:03 2015 From: jsrobin at gmail.com (John Robinson) Date: Sat, 7 Mar 2015 13:47:03 -0500 Subject: [undertow-dev] SSL client authorization -- how ? In-Reply-To: <2137307931.27283889.1425613923980.JavaMail.zimbra@redhat.com> References: <2137307931.27283889.1425613923980.JavaMail.zimbra@redhat.com> Message-ID: Stuart, Thanks for addressing the problem posed. In the solution you presented, you noted that one had to "... Add a security domain ... although it will depend on how you store your user information ...". The crux of the matter is that the security information for the user is not on the platform. In particular, I am seeking to obtain the certificate from the request attribute "javax.servlet.request.X509Certificate" so that in an application servlet or in a ejb referenced by a JSF page, the certificate would be authenticated and authorized. In particular: 1. Does the configuration that you present assume that the client's certificate is in the trust store (undertow.keystore)? 2. Does the platform (WildFly 8.2.0) when configured as recommended use " org.jboss.security.auth.certs.AnyCertVerifier" so that it does not try to validate, but relies on the application to obtain the certificate from the request attribute "javax.servlet.request.X509Certificate" to perform authentication and authorization at the application level. Thanks in advance for your help. John On Thu, Mar 5, 2015 at 10:52 PM, Stuart Douglas wrote: > The basic steps are: > > In standalone.xml > > Add a HTTPS listener to the undertow subsystem: > > security-realm="myrealm"/> > > Add a security realm: > > > > > > relative-to="jboss.server.config.dir" keystore-password="mypassword" /> > > > > relative-to="jboss.server.config.dir" keystore-password="mypassword" /> > > > > Add a security domains to the security subsystem, should be something like > this (although it will depend on how you store your user information): > > > > truststore-url="../standalone/configuration/keystores/undertow.keystore" > truststore-password="mypassword" > > keystore-url="../standalone/configuration/keystores/clientcert.jks" > keystore-password="mypassword"/> > > > > flag="required"> > value="userFirstPass"/> > value="ssl"/> > value="../standalone/configuration/security/roles.properties"/> > > > > > > > type="role"/> > > > > - Set the authentication mechanism as CLIENT_CERT in web.xml > - In jboss-web.xml specify your security domain: > > > > client-cert > > > > We are taking steps to simplify this configuration, and unify (and > hopefully simplify) all our SSL config, although I am not sure when this > will be done. > > Stuart > > > ----- Original Message ----- > > From: "John Robinson" > > To: "undertow-dev" > > Sent: Thursday, 5 March, 2015 4:32:43 AM > > Subject: [undertow-dev] SSL client authorization -- how ? > > > > What are the detailed configuration instructions to configure > > "standalone.xml", web.xml, and jboss-web.xml to set up SSL with client > > authorization? > > > > Could someone direct me to the appropriate place to find detailed > > configuration information on how to have a WildFly 8.2 server evoke from > a > > client, a certificate under SSL. > > > > The cerificate, I expect, would be sent via the > > "javax.servlet.request.X509Certificate" request attribute. > > > > If this is an inappropriate forum for this question, please feel free to > > direct me to the correct forum. > > > > Thanks in advance for your help. > > > > _______________________________________________ > > 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/20150307/87475b4e/attachment-0001.html From mbarton at itrsgroup.com Mon Mar 9 05:51:04 2015 From: mbarton at itrsgroup.com (Michael Barton) Date: Mon, 9 Mar 2015 09:51:04 +0000 Subject: [undertow-dev] Lost requests when responding from Akka actor system In-Reply-To: <839355040.11083.1425704431648.JavaMail.zimbra@redhat.com> References: <839355040.11083.1425704431648.JavaMail.zimbra@redhat.com> Message-ID: Thanks Stuart. Looks like that has fixed the issue. Michael -----Original Message----- From: Stuart Douglas [mailto:sdouglas at redhat.com] Sent: 07 March 2015 05:01 To: Michael Barton Cc: undertow-dev at lists.jboss.org Subject: Re: [undertow-dev] Lost requests when responding from Akka actor system It is possible there may be a thread safety issue. When you do the initial dispatch try using the version of dispatch that takes a Runnable and dispatch to Akka in the Runnable. This makes sure that there is only one thread active on the exchange at any time (as Undertow needs to examine some state on the exchange when the call stack initially returns). Stuart ----- Original Message ----- > From: "Michael Barton" > To: undertow-dev at lists.jboss.org > Sent: Friday, 6 March, 2015 9:06:54 PM > Subject: [undertow-dev] Lost requests when responding from Akka actor > system > > > > Hi all, > > > > I?ve been using Undertow embedded in an Akka application and it is > working great apart from a small issue when running load tests. > > > > I?ve reduced the problem down to a small little demo application which > I?ve attached below. It is in Scala but I can create a Java version if required. > > > > I fire one million POST requests at Undertow and almost all succeed, > however some never receive a response. The number that fail varies from 1 to 10. > > > > Increasing the concurrency on the client and server side together and > independently increases the number of failures. I?ve not yet seen any > failures with no concurrency on the server side. > > > > The HTTP handler callback is not invoked for the requests that fail. > I?ve verified this by adding a counter before I call > exchange.dispatch() and pass it on to the processing actor pool. > > > > I don?t think I?m doing anything that is not thread-safe since Akka > guarantees that actors do not execute concurrently. However the > execution of the actor does move around a number of threads in the > underlying Fork Join pool and I?m wondering if that would cause issues with Undertow? > > > > Any suggestions for how I could debug this? > > > > Thanks, > > > > Michael > > > > Code to reproduce > > ============== > > > > object UndertowTest { > > def start(handler: HttpHandler) = Undertow.builder() > > .addHttpListener(8888, "localhost") > > .setHandler(handler) > > .build() > > .start() > > } > > > > class Responder extends HttpHandler { > > override def handleRequest(exchange: HttpServerExchange): Unit = { > > exchange.getResponseHeaders.put(io.undertow.util.Headers.CONTENT_TYPE, > "text/plain") > > exchange.getResponseSender.send("Hello world!") > > } > > } > > > > class RequestHandler extends Actor with Loggable { > > val handler = new Responder > > > > override def receive = { > > case exchange: HttpServerExchange => > > handler.handeRequest(exchange) > > } > > } > > > > object UndertowAkkaTest extends App { > > val sys = ActorSystem() > > > > // Changing the number here changes the number of actors handling > incoming requests > > val handlerPool = > sys.actorOf(RoundRobinPool(4).props(Props(classOf[RequestHandler]))) > > > > UndertowTest.start(new HttpHandler { > > override def handleRequest(exchange: HttpServerExchange): Unit = { > > exchange.dispatch() > > handlerPool ! exchange > > } > > }) > > } > > > > Apache Bench command to test > > ======================== > > > > # -c changes number of concurrent client side requests > > ab -k -c 4 -n 100000 -p payload.json -T application/json > http://localhost:8888/streams/demo/infrastructure/cpu > > > > Data in payload.json > > =============== > > > > { > > "sampleTime": "2015-02-24T06:02:47", > > "contributor": "3b8da322-ef8f-4f6b-93a3-a171dd794308", > > "host": "some-host", > > "process": "some-process", > > "user": 35.7, > > "kernel": 12.3 > > } > > > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From davidpobrien at gmail.com Thu Mar 12 19:33:43 2015 From: davidpobrien at gmail.com (Dave O'Brien) Date: Thu, 12 Mar 2015 23:33:43 +0000 Subject: [undertow-dev] TransferTo/sendfile Undertow v1.0.x vs 1.1.x Message-ID: Hi everyone, I wanted to run this 'issue' past the experts, as I've looked into it myself and hit a bit of a dead end. Our application is using Undertow 1.0.17 for serving both static and dynamic Web content. We did some benchmarking early on in the development of our app and got some very impressive results. On a modest server with undertow 1.0.17, using wrk defaults we get around 50k rqsts/s for a 2kb file and about 17k rqsts/s for a 100kb file. So far, so (very) good. I recently tried updating to version 1.1.2 and ran the original tests and got similar results as for v1.0.17 for the 2kb file. For the 100kb file, however the throughput dropped to about 10k rqsts/s. Not the end of the world, I know but I decided to dig around and see what was (or wasn't) going on.... Our app has a sendfile threshold (64k), that above which we use the ResponseChannel 'TransferTo' method, which performs (on Linux anyway) a native zero-copy sendfile operation using the Java NIO FileChannel.transferTo call (which calls into Linux sendfile under the covers if certain conditions are met). In v1.0.x, the native sendfile method (transferTo0) is ultimately invoked to send the content. But in v1.1.x (and 1.2.x also) the transferTo method in the FileChannel instead opts to invoke transferToArbitraryChannel which resorts to a kernel -> user space copy and a not-insignificant drop in throughput. So my question is, is this change across the versions deliberate, a sacrifice for improvements elsewhere - or is it a bug? If it's a bug I'm happy to re-instate the native sendfile functionality myself, but I wanted to check it was an issue first... Thanks in advance for any assistance/advice on this one... David. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150312/631ff89a/attachment.html From sdouglas at redhat.com Thu Mar 12 21:04:55 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 12 Mar 2015 21:04:55 -0400 (EDT) Subject: [undertow-dev] TransferTo/sendfile Undertow v1.0.x vs 1.1.x In-Reply-To: References: Message-ID: <2115992251.3983252.1426208695635.JavaMail.zimbra@redhat.com> I have filed https://issues.jboss.org/browse/UNDERTOW-407 and pushed a potential fix for this upstream to both the master and 1.1.x branches. Can you try it out and see if it resolves your issue? Stuart ----- Original Message ----- > From: "Dave O'Brien" > To: undertow-dev at lists.jboss.org > Sent: Friday, 13 March, 2015 10:33:43 AM > Subject: [undertow-dev] TransferTo/sendfile Undertow v1.0.x vs 1.1.x > > Hi everyone, > > I wanted to run this 'issue' past the experts, as I've looked into it myself > and hit a bit of a dead end. > > Our application is using Undertow 1.0.17 for serving both static and dynamic > Web content. We did some benchmarking early on in the development of our app > and got some very impressive results. > > On a modest server with undertow 1.0.17, using wrk defaults we get around 50k > rqsts/s for a 2kb file and about 17k rqsts/s for a 100kb file. So far, so > (very) good. > > I recently tried updating to version 1.1.2 and ran the original tests and got > similar results as for v1.0.17 for the 2kb file. For the 100kb file, however > the throughput dropped to about 10k rqsts/s. > > Not the end of the world, I know but I decided to dig around and see what was > (or wasn't) going on.... > > Our app has a sendfile threshold (64k), that above which we use the > ResponseChannel 'TransferTo' method, which performs (on Linux anyway) a > native zero-copy sendfile operation using the Java NIO > FileChannel.transferTo call (which calls into Linux sendfile under the > covers if certain conditions are met). > > In v1.0.x, the native sendfile method (transferTo0) is ultimately invoked to > send the content. But in v1.1.x (and 1.2.x also) the transferTo method in > the FileChannel instead opts to invoke transferToArbitraryChannel which > resorts to a kernel -> user space copy and a not-insignificant drop in > throughput. > > So my question is, is this change across the versions deliberate, a sacrifice > for improvements elsewhere - or is it a bug? > > If it's a bug I'm happy to re-instate the native sendfile functionality > myself, but I wanted to check it was an issue first... > > Thanks in advance for any assistance/advice on this one... > > David. > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From ecki at zusammenkunft.net Fri Mar 13 15:47:20 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 13 Mar 2015 20:47:20 +0100 Subject: [undertow-dev] ResourceHandler give 0 byte Content-Length for HEAD Message-ID: <20150313204720.00000070.ecki@zusammenkunft.net> Hello, with all versions I tried (including 1.2.0.Beta9) undertow-core will return content-length: 0 if a HEAD request is made. I am using a simple handler: FileResourceManager frm = new FileResourceManager(new File(".").getCanonicalFile(), 16*1024); ResourceHandler res = new ResourceHandler(); res.setResourceManager(frm); res.setAllowed(Predicates.truePredicate()); res.setDirectoryListingEnabled(true); PathHandler path = Handlers.path(errorHandler); path.addPrefixPath("/res", res); GracefulShutdownHandler shutdownHandler = Handlers.gracefulShutdown(path); Undertow server = Undertow.builder().addHttpListener(8080, null) .setServerOption(UndertowOptions.RECORD_REQUEST_START_TIME, Boolean.TRUE) .setServerOption(UndertowOptions.ALWAYS_SET_DATE, Boolean.TRUE) // default .setWorkerThreads(2).setHandler(shutdownHandler).build(); server.start(); If I request the GET method the content is found: curl -v http://localhost:8080/webdav/pom.xml * Connected to localhost (127.0.0.1) port 8080 (#0) > GET /res/pom.xml HTTP/1.1 > User-Agent: curl/7.30.0 > Host: localhost:8080 > Accept: */* > < HTTP/1.1 200 OK < Connection: keep-alive < Last-Modified: Fri, 13 Mar 2015 19:24:58 GMT < Content-Length: 1155 < Content-Type: text/xml < Date: Fri, 13 Mar 2015 19:39:24 GMT < ... curl -v -XHEAD http://localhost:8080/webdav/pom.xml * Connected to localhost (127.0.0.1) port 8080 (#0) > HEAD /webdav/pom.xml HTTP/1.1 > User-Agent: curl/7.30.0 > Host: localhost:8080 > Accept: */* > < HTTP/1.1 200 OK < Connection: keep-alive < Last-Modified: Fri, 13 Mar 2015 19:24:58 GMT < Content-Length: 0 < Content-Type: text/xml < Date: Fri, 13 Mar 2015 19:40:51 GMT < * Connection #0 to host localhost left intact According to RFC2616 sc 14.13 this needs to be non-null. From jason.greene at redhat.com Fri Mar 13 15:55:39 2015 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 13 Mar 2015 14:55:39 -0500 Subject: [undertow-dev] ResourceHandler give 0 byte Content-Length for HEAD In-Reply-To: <20150313204720.00000070.ecki@zusammenkunft.net> References: <20150313204720.00000070.ecki@zusammenkunft.net> Message-ID: <8D403F49-824B-415C-A23B-F655DF9F6283@redhat.com> > On Mar 13, 2015, at 2:47 PM, Bernd Eckenfels wrote: > > Hello, > > with all versions I tried (including 1.2.0.Beta9) undertow-core will > return content-length: 0 if a HEAD request is made. > -snip- > < HTTP/1.1 200 OK > < Connection: keep-alive > < Last-Modified: Fri, 13 Mar 2015 19:24:58 GMT > < Content-Length: 0 > < Content-Type: text/xml > < Date: Fri, 13 Mar 2015 19:40:51 GMT > < > * Connection #0 to host localhost left intact > > According to RFC2616 sc 14.13 this needs to be non-null. > It?s wasting bandwidth, so we should probably not send it. However, its a legal value: 14.13 says "Any Content-Length greater than or equal to zero is a valid value." -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From ecki at zusammenkunft.net Fri Mar 13 16:20:38 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 13 Mar 2015 21:20:38 +0100 Subject: [undertow-dev] ResourceHandler give 0 byte Content-Length for HEAD In-Reply-To: <8D403F49-824B-415C-A23B-F655DF9F6283@redhat.com> References: <20150313204720.00000070.ecki@zusammenkunft.net> <8D403F49-824B-415C-A23B-F655DF9F6283@redhat.com> Message-ID: <20150313212038.000026d4.ecki@zusammenkunft.net> Hello Jason, yes you could send a wrong value and it would be better to not answer one than a wrong one, but even better woild it be to follow the RFC recommendation, that states that the headers of a HEAD should be identical to those of a GET. In fact the content-length is one of the most interesting informations one would want to query with a HEAD request. Gruss Bernd Am Fri, 13 Mar 2015 14:55:39 -0500 schrieb Jason Greene : > > > On Mar 13, 2015, at 2:47 PM, Bernd Eckenfels > > wrote: > > > > Hello, > > > > with all versions I tried (including 1.2.0.Beta9) undertow-core will > > return content-length: 0 if a HEAD request is made. > > > > -snip- > > > < HTTP/1.1 200 OK > > < Connection: keep-alive > > < Last-Modified: Fri, 13 Mar 2015 19:24:58 GMT > > < Content-Length: 0 > > < Content-Type: text/xml > > < Date: Fri, 13 Mar 2015 19:40:51 GMT > > < > > * Connection #0 to host localhost left intact > > > > According to RFC2616 sc 14.13 this needs to be non-null. > > > > It?s wasting bandwidth, so we should probably not send it. However, > its a legal value: > > 14.13 says "Any Content-Length greater than or equal to zero is a > valid value." > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > From jason.greene at redhat.com Fri Mar 13 16:29:55 2015 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 13 Mar 2015 15:29:55 -0500 Subject: [undertow-dev] ResourceHandler give 0 byte Content-Length for HEAD In-Reply-To: <20150313212038.000026d4.ecki@zusammenkunft.net> References: <20150313204720.00000070.ecki@zusammenkunft.net> <8D403F49-824B-415C-A23B-F655DF9F6283@redhat.com> <20150313212038.000026d4.ecki@zusammenkunft.net> Message-ID: Ah! now i follow. Sorry, I skimmed your email and didn?t recognize you were highlighting the discrepancy between a GET and HEAD. > On Mar 13, 2015, at 3:20 PM, Bernd Eckenfels wrote: > > Hello Jason, > > yes you could send a wrong value and it would be > better to not answer one than a wrong one, but even better woild it > be to follow the RFC recommendation, that states that the headers of a > HEAD should be identical to those of a GET. In fact the content-length > is one of the most interesting informations one would want to query > with a HEAD request. > > Gruss > Bernd > > Am Fri, 13 Mar 2015 14:55:39 -0500 > schrieb Jason Greene : > >> >>> On Mar 13, 2015, at 2:47 PM, Bernd Eckenfels >>> wrote: >>> >>> Hello, >>> >>> with all versions I tried (including 1.2.0.Beta9) undertow-core will >>> return content-length: 0 if a HEAD request is made. >>> >> >> -snip- >> >>> < HTTP/1.1 200 OK >>> < Connection: keep-alive >>> < Last-Modified: Fri, 13 Mar 2015 19:24:58 GMT >>> < Content-Length: 0 >>> < Content-Type: text/xml >>> < Date: Fri, 13 Mar 2015 19:40:51 GMT >>> < >>> * Connection #0 to host localhost left intact >>> >>> According to RFC2616 sc 14.13 this needs to be non-null. >>> >> >> It?s wasting bandwidth, so we should probably not send it. However, >> its a legal value: >> >> 14.13 says "Any Content-Length greater than or equal to zero is a >> valid value." >> >> -- >> 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 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From ecki at zusammenkunft.net Fri Mar 13 17:10:37 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 13 Mar 2015 22:10:37 +0100 Subject: [undertow-dev] ResourceHandler give 0 byte Content-Length for HEAD In-Reply-To: References: <20150313204720.00000070.ecki@zusammenkunft.net> <8D403F49-824B-415C-A23B-F655DF9F6283@redhat.com> <20150313212038.000026d4.ecki@zusammenkunft.net> Message-ID: <20150313221037.0000694b.ecki@zusammenkunft.net> Hello Jason, oh ok, no problem. I was trying to fix it myself by adding a content-length header in ResourceHandler#serveResource in the" if (!sendContent)", but it seems the core is overwriting this. Want me to open a bug for it? Gruss Bernd Am Fri, 13 Mar 2015 15:29:55 -0500 schrieb Jason Greene : > Ah! now i follow. Sorry, I skimmed your email and didn?t recognize > you were highlighting the discrepancy between a GET and HEAD. > > > On Mar 13, 2015, at 3:20 PM, Bernd Eckenfels > > wrote: > > > > Hello Jason, > > > > yes you could send a wrong value and it would be > > better to not answer one than a wrong one, but even better woild it > > be to follow the RFC recommendation, that states that the headers > > of a HEAD should be identical to those of a GET. In fact the > > content-length is one of the most interesting informations one > > would want to query with a HEAD request. > > > > Gruss > > Bernd > > > > Am Fri, 13 Mar 2015 14:55:39 -0500 > > schrieb Jason Greene : > > > >> > >>> On Mar 13, 2015, at 2:47 PM, Bernd Eckenfels > >>> wrote: > >>> > >>> Hello, > >>> > >>> with all versions I tried (including 1.2.0.Beta9) undertow-core > >>> will return content-length: 0 if a HEAD request is made. > >>> > >> > >> -snip- > >> > >>> < HTTP/1.1 200 OK > >>> < Connection: keep-alive > >>> < Last-Modified: Fri, 13 Mar 2015 19:24:58 GMT > >>> < Content-Length: 0 > >>> < Content-Type: text/xml > >>> < Date: Fri, 13 Mar 2015 19:40:51 GMT > >>> < > >>> * Connection #0 to host localhost left intact > >>> > >>> According to RFC2616 sc 14.13 this needs to be non-null. > >>> > >> > >> It?s wasting bandwidth, so we should probably not send it. However, > >> its a legal value: > >> > >> 14.13 says "Any Content-Length greater than or equal to zero is a > >> valid value." > >> > >> -- > >> 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 > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > From ecki at zusammenkunft.net Sat Mar 14 18:02:47 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 14 Mar 2015 23:02:47 +0100 Subject: [undertow-dev] ResourceHandler give 0 byte Content-Length for HEAD In-Reply-To: <20150313221037.0000694b.ecki@zusammenkunft.net> References: <20150313204720.00000070.ecki@zusammenkunft.net> <8D403F49-824B-415C-A23B-F655DF9F6283@redhat.com> <20150313212038.000026d4.ecki@zusammenkunft.net> <20150313221037.0000694b.ecki@zusammenkunft.net> Message-ID: <20150314230247.00007544.ecki@zusammenkunft.net> Hello, I filed this bug: https://issues.jboss.org/browse/UNDERTOW-409 Gruss Bernd BTW: I just noticed dont be confused about my cut+paste example below, I was renaming /webdav into /res to avoid the confusing path name /webdav. However I did not change all occurences. So both requests actually are run against the same /res resource (and should show the same size). From sdouglas at redhat.com Sun Mar 15 17:05:55 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 15 Mar 2015 17:05:55 -0400 (EDT) Subject: [undertow-dev] ResourceHandler give 0 byte Content-Length for HEAD In-Reply-To: <20150314230247.00007544.ecki@zusammenkunft.net> References: <20150313204720.00000070.ecki@zusammenkunft.net> <8D403F49-824B-415C-A23B-F655DF9F6283@redhat.com> <20150313212038.000026d4.ecki@zusammenkunft.net> <20150313221037.0000694b.ecki@zusammenkunft.net> <20150314230247.00007544.ecki@zusammenkunft.net> Message-ID: <1424439088.5226490.1426453555454.JavaMail.zimbra@redhat.com> I have fixed this upstream. Stuart ----- Original Message ----- > From: "Bernd Eckenfels" > To: undertow-dev at lists.jboss.org > Sent: Sunday, 15 March, 2015 9:02:47 AM > Subject: Re: [undertow-dev] ResourceHandler give 0 byte Content-Length for HEAD > > Hello, > > I filed this bug: https://issues.jboss.org/browse/UNDERTOW-409 > > Gruss > Bernd > > BTW: I just noticed dont be confused about my cut+paste example below, > I was renaming /webdav into /res to avoid the confusing path > name /webdav. However I did not change all occurences. So both > requests actually are run against the same /res resource (and should > show the same size). > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From ecki at zusammenkunft.net Sun Mar 15 19:03:54 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 16 Mar 2015 00:03:54 +0100 Subject: [undertow-dev] Async PUT (fileresource) handler. Message-ID: <20150316000354.00004dc2.ecki@zusammenkunft.net> Hello, I have added a small special-purpose PUT handler to a project of mine. I am using however a blocking exchange to read the uploaded data and put it into a file. This seems to work, but I wonder if it would be worthwile to do this async (with channels). When I understand NIO FileChannels correctly they emulate the non-blocking behaviour with their own IO threads, so I guess it is not really better to use it this way (in terms of occupied threads). But I wonder if somebody did some experiments of has ready-made code for it? Just for the record, I am using new File(FileResourceManager.getBase(), canonicalize(exchange.getRelativePath()) to work around the missing write support in the FRM. Thats fine of the application is not too complex and needs no abstraction, but I can imagine it would be better to have that support (for things like WebDav handler). Gruss Bernd From sdouglas at redhat.com Mon Mar 16 21:47:34 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 16 Mar 2015 21:47:34 -0400 (EDT) Subject: [undertow-dev] Async PUT (fileresource) handler. In-Reply-To: <20150316000354.00004dc2.ecki@zusammenkunft.net> References: <20150316000354.00004dc2.ecki@zusammenkunft.net> Message-ID: <1949509484.7365619.1426556854550.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bernd Eckenfels" > To: undertow-dev at lists.jboss.org > Sent: Monday, 16 March, 2015 10:03:54 AM > Subject: [undertow-dev] Async PUT (fileresource) handler. > > Hello, > > I have added a small special-purpose PUT handler to a project of mine. > I am using however a blocking exchange to read the uploaded data and > put it into a file. This seems to work, but I wonder if it would be > worthwile to do this async (with channels). > > When I understand NIO FileChannels correctly they emulate the > non-blocking behaviour with their own IO threads, so I guess it is not > really better to use it this way (in terms of occupied threads). I think you are correct, although I am not 100% sure. > > But I wonder if somebody did some experiments of has ready-made code > for it? > > Just for the record, I am using new File(FileResourceManager.getBase(), > canonicalize(exchange.getRelativePath()) to work around the missing > write support in the FRM. Thats fine of the application is not too > complex and needs no abstraction, but I can imagine it would be better > to have that support (for things like WebDav handler). I will look at adding this. It will probably be in the form of an optional interface (WritableResource) that Resource instances can implement. We definitely need to provide webdav support, so I will look at implementing this sooner rather than later. Stuart > > Gruss > Bernd > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From stephan.mehlhase at eml.org Tue Mar 17 09:36:31 2015 From: stephan.mehlhase at eml.org (Stephan Mehlhase) Date: Tue, 17 Mar 2015 14:36:31 +0100 Subject: [undertow-dev] JSR WebSocket onMessage called out-of-order Message-ID: <55082DDF.5020106@eml.org> Hi, I ran into an issue with the Undertow JSR WebSocket implementation: the message handler's @OnMessage method is not called with messages in the same order as these were sent. I encountered this problem first with the current WildFly 8.2.0.Final version. I posted about it in the forums [1]. But since I got no replies there and can reproduce this problem with Undertow 1.2.0.Beta4 (from maven) alone, I thought this might be the right place to ask about it. I am developing a @ServerEndpoint which needs to handle clients sending unfragmented messages in rapid succession. These messages are not always delivered in the order as they were sent. Since WebSocket is based on HTTP, I assume that the messages arrive in the "correct" order at the server. However, from time to time two messages appear switched (e.g. message no. 4 arrives at @OnMessage before message no. 3). If I fragment the messages (according to RFC 6455), the order of all messages is always correct. I have uploaded an example application which reproduces this to http://pastebin.com/tcm6ZnsB It uses some Guava classes for checking the order of messages. I can also reproduce this problem with another (non-public but RFC compliant) WebSocket library. My first question is, if that is intended behavior or a bug? The WebSocket RFC does not explicitly forbid this kind of behavior, however for me it was very surprising given that 1. the underlying protocols deliver everything in order, 2. this works as I expected it for fragmented messages and 3. I haven't seen this for other implementations. If this is not considered a bug, is there an option which basically forces in-order delivery of messages? Ideally even accessible in WildFly. If not, does opening a feature request for this make sense (i.e. does it have a realistic chance of being addressed)? Best, Stephan [1]: https://developer.jboss.org/message/921226#921226 -- Stephan Mehlhase Email: stephan.mehlhase at eml.org EML European Media Laboratory GmbH Schloss-Wolfsbrunnenweg 35 69118 Heidelberg Amtsgericht Mannheim / HRB 335719 Managing Partner: Dr. h. c. Dr.-Ing. E. h. Klaus Tschira, Scientific and Managing Director: Prof. Dr.-Ing. Andreas Reuter http://www.eml.org From sdouglas at redhat.com Tue Mar 17 18:53:09 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 17 Mar 2015 18:53:09 -0400 (EDT) Subject: [undertow-dev] JSR WebSocket onMessage called out-of-order In-Reply-To: <55082DDF.5020106@eml.org> References: <55082DDF.5020106@eml.org> Message-ID: <2002611717.8361777.1426632789451.JavaMail.zimbra@redhat.com> I think this is a bug, I will have a look. Stuart ----- Original Message ----- > From: "Stephan Mehlhase" > To: undertow-dev at lists.jboss.org > Sent: Wednesday, 18 March, 2015 12:36:31 AM > Subject: [undertow-dev] JSR WebSocket onMessage called out-of-order > > Hi, > > I ran into an issue with the Undertow JSR WebSocket implementation: the > message handler's @OnMessage method is not called with messages in the > same order as these were sent. I encountered this problem first with the > current WildFly 8.2.0.Final version. I posted about it in the forums > [1]. But since I got no replies there and can reproduce this problem > with Undertow 1.2.0.Beta4 (from maven) alone, I thought this might be > the right place to ask about it. > > I am developing a @ServerEndpoint which needs to handle clients sending > unfragmented messages in rapid succession. These messages are not always > delivered in the order as they were sent. Since WebSocket is based on > HTTP, I assume that the messages arrive in the "correct" order at the > server. However, from time to time two messages appear switched (e.g. > message no. 4 arrives at @OnMessage before message no. 3). If I fragment > the messages (according to RFC 6455), the order of all messages is > always correct. > > I have uploaded an example application which reproduces this to > > http://pastebin.com/tcm6ZnsB > > It uses some Guava classes for checking the order of messages. > > I can also reproduce this problem with another (non-public but RFC > compliant) WebSocket library. > > My first question is, if that is intended behavior or a bug? The > WebSocket RFC does not explicitly forbid this kind of behavior, however > for me it was very surprising given that > 1. the underlying protocols deliver everything in order, > 2. this works as I expected it for fragmented messages and > 3. I haven't seen this for other implementations. > > If this is not considered a bug, is there an option which basically > forces in-order delivery of messages? Ideally even accessible in > WildFly. If not, does opening a feature request for this make sense > (i.e. does it have a realistic chance of being addressed)? > > > Best, > Stephan > > > > [1]: https://developer.jboss.org/message/921226#921226 > > -- > > Stephan Mehlhase > Email: stephan.mehlhase at eml.org > > EML European Media Laboratory GmbH > Schloss-Wolfsbrunnenweg 35 > 69118 Heidelberg > > Amtsgericht Mannheim / HRB 335719 > Managing Partner: Dr. h. c. Dr.-Ing. E. h. Klaus Tschira, Scientific and > Managing > Director: Prof. Dr.-Ing. Andreas Reuter > > http://www.eml.org > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From sdouglas at redhat.com Tue Mar 17 20:06:09 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 17 Mar 2015 20:06:09 -0400 (EDT) Subject: [undertow-dev] JSR WebSocket onMessage called out-of-order In-Reply-To: <2002611717.8361777.1426632789451.JavaMail.zimbra@redhat.com> References: <55082DDF.5020106@eml.org> <2002611717.8361777.1426632789451.JavaMail.zimbra@redhat.com> Message-ID: <1722125861.8370243.1426637169237.JavaMail.zimbra@redhat.com> https://issues.jboss.org/browse/UNDERTOW-410 I have pushed a fix upstream, and turned your reproducer into a test case. Stuart ----- Original Message ----- > From: "Stuart Douglas" > To: "Stephan Mehlhase" > Cc: undertow-dev at lists.jboss.org > Sent: Wednesday, 18 March, 2015 9:53:09 AM > Subject: Re: [undertow-dev] JSR WebSocket onMessage called out-of-order > > I think this is a bug, I will have a look. > > Stuart > > ----- Original Message ----- > > From: "Stephan Mehlhase" > > To: undertow-dev at lists.jboss.org > > Sent: Wednesday, 18 March, 2015 12:36:31 AM > > Subject: [undertow-dev] JSR WebSocket onMessage called out-of-order > > > > Hi, > > > > I ran into an issue with the Undertow JSR WebSocket implementation: the > > message handler's @OnMessage method is not called with messages in the > > same order as these were sent. I encountered this problem first with the > > current WildFly 8.2.0.Final version. I posted about it in the forums > > [1]. But since I got no replies there and can reproduce this problem > > with Undertow 1.2.0.Beta4 (from maven) alone, I thought this might be > > the right place to ask about it. > > > > I am developing a @ServerEndpoint which needs to handle clients sending > > unfragmented messages in rapid succession. These messages are not always > > delivered in the order as they were sent. Since WebSocket is based on > > HTTP, I assume that the messages arrive in the "correct" order at the > > server. However, from time to time two messages appear switched (e.g. > > message no. 4 arrives at @OnMessage before message no. 3). If I fragment > > the messages (according to RFC 6455), the order of all messages is > > always correct. > > > > I have uploaded an example application which reproduces this to > > > > http://pastebin.com/tcm6ZnsB > > > > It uses some Guava classes for checking the order of messages. > > > > I can also reproduce this problem with another (non-public but RFC > > compliant) WebSocket library. > > > > My first question is, if that is intended behavior or a bug? The > > WebSocket RFC does not explicitly forbid this kind of behavior, however > > for me it was very surprising given that > > 1. the underlying protocols deliver everything in order, > > 2. this works as I expected it for fragmented messages and > > 3. I haven't seen this for other implementations. > > > > If this is not considered a bug, is there an option which basically > > forces in-order delivery of messages? Ideally even accessible in > > WildFly. If not, does opening a feature request for this make sense > > (i.e. does it have a realistic chance of being addressed)? > > > > > > Best, > > Stephan > > > > > > > > [1]: https://developer.jboss.org/message/921226#921226 > > > > -- > > > > Stephan Mehlhase > > Email: stephan.mehlhase at eml.org > > > > EML European Media Laboratory GmbH > > Schloss-Wolfsbrunnenweg 35 > > 69118 Heidelberg > > > > Amtsgericht Mannheim / HRB 335719 > > Managing Partner: Dr. h. c. Dr.-Ing. E. h. Klaus Tschira, Scientific and > > Managing > > Director: Prof. Dr.-Ing. Andreas Reuter > > > > http://www.eml.org > > _______________________________________________ > > 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 ecki at zusammenkunft.net Wed Mar 18 18:56:25 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 18 Mar 2015 23:56:25 +0100 Subject: [undertow-dev] Different Handler Chains for Listeners Message-ID: <20150318235625.00007ee7.ecki@zusammenkunft.net> Hello, I see in the Undertow$Builder, that each listener which is added gets the rootHandler set. The Builder API does not allow me to set different handlers for different ports. Is that an expected and intended use case? Replicating all the setup code from Undertow.start() might allow me to use that, but it is not an exported API it seems. Specifically I want to have a service and a management interface in a micro service. I could to that with two server instances, just not sure if this is better? I havent seen a handler which can dispatch based on the listener, is there any (maybe based on ServerConnection#getLocalAddress()?)? Greetings Bernd From stephan.mehlhase at eml.org Wed Mar 18 19:28:46 2015 From: stephan.mehlhase at eml.org (Mehlhase, Stephan) Date: Wed, 18 Mar 2015 23:28:46 +0000 Subject: [undertow-dev] JSR WebSocket onMessage called out-of-order In-Reply-To: <1722125861.8370243.1426637169237.JavaMail.zimbra@redhat.com> References: <55082DDF.5020106@eml.org> <2002611717.8361777.1426632789451.JavaMail.zimbra@redhat.com>, <1722125861.8370243.1426637169237.JavaMail.zimbra@redhat.com> Message-ID: <03829010dec74d4eb95b46d3aad2cbcf@VBMBX01.villa-bosch.de> Hi Stuart, Thanks. :-) Stephan ________________________________________ Von: Stuart Douglas Gesendet: Mittwoch, 18. M?rz 2015 01:06 An: Mehlhase, Stephan Cc: undertow-dev at lists.jboss.org Betreff: Re: [undertow-dev] JSR WebSocket onMessage called out-of-order https://issues.jboss.org/browse/UNDERTOW-410 I have pushed a fix upstream, and turned your reproducer into a test case. Stuart ----- Original Message ----- > From: "Stuart Douglas" > To: "Stephan Mehlhase" > Cc: undertow-dev at lists.jboss.org > Sent: Wednesday, 18 March, 2015 9:53:09 AM > Subject: Re: [undertow-dev] JSR WebSocket onMessage called out-of-order > > I think this is a bug, I will have a look. > > Stuart > > ----- Original Message ----- > > From: "Stephan Mehlhase" > > To: undertow-dev at lists.jboss.org > > Sent: Wednesday, 18 March, 2015 12:36:31 AM > > Subject: [undertow-dev] JSR WebSocket onMessage called out-of-order > > > > Hi, > > > > I ran into an issue with the Undertow JSR WebSocket implementation: the > > message handler's @OnMessage method is not called with messages in the > > same order as these were sent. I encountered this problem first with the > > current WildFly 8.2.0.Final version. I posted about it in the forums > > [1]. But since I got no replies there and can reproduce this problem > > with Undertow 1.2.0.Beta4 (from maven) alone, I thought this might be > > the right place to ask about it. > > > > I am developing a @ServerEndpoint which needs to handle clients sending > > unfragmented messages in rapid succession. These messages are not always > > delivered in the order as they were sent. Since WebSocket is based on > > HTTP, I assume that the messages arrive in the "correct" order at the > > server. However, from time to time two messages appear switched (e.g. > > message no. 4 arrives at @OnMessage before message no. 3). If I fragment > > the messages (according to RFC 6455), the order of all messages is > > always correct. > > > > I have uploaded an example application which reproduces this to > > > > http://pastebin.com/tcm6ZnsB > > > > It uses some Guava classes for checking the order of messages. > > > > I can also reproduce this problem with another (non-public but RFC > > compliant) WebSocket library. > > > > My first question is, if that is intended behavior or a bug? The > > WebSocket RFC does not explicitly forbid this kind of behavior, however > > for me it was very surprising given that > > 1. the underlying protocols deliver everything in order, > > 2. this works as I expected it for fragmented messages and > > 3. I haven't seen this for other implementations. > > > > If this is not considered a bug, is there an option which basically > > forces in-order delivery of messages? Ideally even accessible in > > WildFly. If not, does opening a feature request for this make sense > > (i.e. does it have a realistic chance of being addressed)? > > > > > > Best, > > Stephan > > > > > > > > [1]: https://developer.jboss.org/message/921226#921226 > > > > -- > > > > Stephan Mehlhase > > Email: stephan.mehlhase at eml.org > > > > EML European Media Laboratory GmbH > > Schloss-Wolfsbrunnenweg 35 > > 69118 Heidelberg > > > > Amtsgericht Mannheim / HRB 335719 > > Managing Partner: Dr. h. c. Dr.-Ing. E. h. Klaus Tschira, Scientific and > > Managing > > Director: Prof. Dr.-Ing. Andreas Reuter > > > > http://www.eml.org > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From sdouglas at redhat.com Wed Mar 18 20:30:04 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 18 Mar 2015 20:30:04 -0400 (EDT) Subject: [undertow-dev] Different Handler Chains for Listeners In-Reply-To: <20150318235625.00007ee7.ecki@zusammenkunft.net> References: <20150318235625.00007ee7.ecki@zusammenkunft.net> Message-ID: <2074577125.9306236.1426725004766.JavaMail.zimbra@redhat.com> I have added a new version of the add listener methods that allow you to specify a different handler per method. Stuart ----- Original Message ----- > From: "Bernd Eckenfels" > To: undertow-dev at lists.jboss.org > Sent: Thursday, 19 March, 2015 9:56:25 AM > Subject: [undertow-dev] Different Handler Chains for Listeners > > Hello, > > I see in the Undertow$Builder, that each listener which is added gets > the rootHandler set. The Builder API does not allow me to set different > handlers for different ports. > > Is that an expected and intended use case? Replicating all the setup > code from Undertow.start() might allow me to use that, but it is not an > exported API it seems. > > Specifically I want to have a service and a management interface in a > micro service. I could to that with two server instances, just not sure > if this is better? I havent seen a handler which can dispatch based on > the listener, is there any (maybe based on > ServerConnection#getLocalAddress()?)? > > Greetings > Bernd > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From ecki at zusammenkunft.net Thu Mar 19 03:35:36 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 19 Mar 2015 08:35:36 +0100 Subject: [undertow-dev] Different Handler Chains for Listeners In-Reply-To: <2074577125.9306236.1426725004766.JavaMail.zimbra@redhat.com> References: <20150318235625.00007ee7.ecki@zusammenkunft.net> <2074577125.9306236.1426725004766.JavaMail.zimbra@redhat.com> Message-ID: <20150319083536.00000738.ecki@zusammenkunft.net> Am Wed, 18 Mar 2015 20:30:04 -0400 (EDT) schrieb Stuart Douglas : > I have added a new version of the add listener methods that allow you > to specify a different handler per method. Thank you, this API looks easy to use. It worked with my first experiments. Gruss Bernd