From pbielicki at gmail.com Tue Apr 1 04:52:28 2014 From: pbielicki at gmail.com (Przemyslaw Bielicki) Date: Tue, 1 Apr 2014 10:52:28 +0200 Subject: [undertow-dev] HTTP Upgrade in Servlet 3.1 - how to use non-blocking input & output at the same time Message-ID: Hi, I posted my question on wildfly-dev ( http://lists.jboss.org/pipermail/wildfly-dev/2014-March/001986.html) but I think this one is better, as the implementation is in undertow-servlet, not in wildfly itself. I would like to use non-blocking input and output at the same time. For the simplicity let's implement EchoProtocol - check the attachments. As you see, the writer is in a separate thread created by manually (which is a bit smelly IMHO). Another point is that I do the write directly without checking whether I can write without blocking. In fact, when I call ServletOutputStream.isReady() I get the Undertow error: "UT010034: Stream not in async mode" Checking the source code you are not really sure if it's a correct behaviour: io.undertow.servlet.spec.UpgradeServletOutputStream io.undertow.servlet.spec.ServletOutputStreamImpl @Override public boolean isReady() { if (listener == null) { * //TODO: is this the correct behaviour?* throw UndertowServletMessages.MESSAGES.streamNotInAsyncMode(); } Another point - more to non-blocking itself. How can ServletOutputStream.write(byte b[]) be non-blocking at all? Let's imagine that the socket is ready to write and I call write with a buffer of 1000 bytes but the receiver is ready only to receive 500 bytes at this point. My call will be blocked, right? Cheers, Przemyslaw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140401/9c3cd082/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: EchoHandler.java Type: application/octet-stream Size: 1477 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20140401/9c3cd082/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: EchoReadListener.java Type: application/octet-stream Size: 1050 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20140401/9c3cd082/attachment-0001.obj From sdouglas at redhat.com Fri Apr 4 02:06:37 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 04 Apr 2014 17:06:37 +1100 Subject: [undertow-dev] HTTP Upgrade in Servlet 3.1 - how to use non-blocking input & output at the same time In-Reply-To: References: Message-ID: <533E4BED.7090907@redhat.com> Przemyslaw Bielicki wrote: > Hi, > > I posted my question on wildfly-dev > (http://lists.jboss.org/pipermail/wildfly-dev/2014-March/001986.html) > but I think this one is better, as the implementation is in > undertow-servlet, not in wildfly itself. > > I would like to use non-blocking input and output at the same time. For > the simplicity let's implement EchoProtocol - check the attachments. > > As you see, the writer is in a separate thread created by manually > (which is a bit smelly IMHO). This is not guaranteed to work, as the underlying request objects are not thread safe. Another point is that I do the write > directly without checking whether I can write without blocking. In fact, > when I call ServletOutputStream.isReady() I get the Undertow error: > "UT010034: Stream not in async mode" > > Checking the source code you are not really sure if it's a correct > behaviour: > > io.undertow.servlet.spec.UpgradeServletOutputStream > io.undertow.servlet.spec.ServletOutputStreamImpl > @Override > public boolean isReady() { > if (listener == null) { > *//TODO: is this the correct behaviour?* > throw UndertowServletMessages.MESSAGES.streamNotInAsyncMode(); > } That is just a question about what happens if you call isReady() when the stream is not in async mode. Basically the spec does not say what to do, so we just throw an exception. If you are getting this exception you are using the stream wrong. If you want to use async IO you need to register a write listener. > > Another point - more to non-blocking itself. How can > ServletOutputStream.write(byte b[]) be non-blocking at all? Let's > imagine that the socket is ready to write and I call write with a buffer > of 1000 bytes but the receiver is ready only to receive 500 bytes at > this point. My call will be blocked, right? We just buffer the input, and then write it out in the background, then call the write listener again when we are done. Stuart > > Cheers, > Przemyslaw > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From hostetlerm at gmail.com Wed Apr 9 15:24:18 2014 From: hostetlerm at gmail.com (Mike Hostetler) Date: Wed, 9 Apr 2014 14:24:18 -0500 Subject: [undertow-dev] java.io.IOException: Broken pip Message-ID: I'm using a WildFly 8.0.1 nightly and can easily recreate this error: 14:01:30,134 ERROR [io.undertow.request] (default task-18) Blocking request failed HttpServerExchange{ GET /ottrservices/recentpatients}: java.lang.RuntimeException: java.io.IOException: Broken pipe at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] Caused by: java.io.IOException: Broken pipe at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_51] at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_51] at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_51] at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_51] at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_51] at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.2.1.Final.jar:3.2.1.Final] at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:529) at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:251) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.2.1.Final.jar:3.2.1.Final] at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100) at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.2.1.Final.jar:3.2.1.Final] at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:623) at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525) ... 9 more For this particular screen, we do send a lot of data back and forth via REST requests. Some of it can be large. I have this setting in my http-listener: yes I picked those large values just to see if they would work and they haven't. I see from this page: http://undertow.io/documentation/core/listeners.html That there is a MAX_ENTITY_SIZE in Undertow but I can't seem to get Wildfly to recognize it -- when I try max-entity-size="something" in the http-listener tag, I get a validation error. Any ideas? -- Mike Hostetler http://mike.hostetlerhome.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140409/85fd5b8a/attachment-0001.html From tomaz.cerar at gmail.com Wed Apr 9 17:49:11 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 9 Apr 2014 23:49:11 +0200 Subject: [undertow-dev] java.io.IOException: Broken pip In-Reply-To: References: Message-ID: What platform is this? Mac? Linux? Windows? On Wed, Apr 9, 2014 at 9:24 PM, Mike Hostetler wrote: > I'm using a WildFly 8.0.1 nightly and can easily recreate this error: > > 14:01:30,134 ERROR [io.undertow.request] (default task-18) Blocking > request failed HttpServerExchange{ GET /ottrservices/recentpatients}: > java.lang.RuntimeException: java.io.IOException: Broken pipe > at > io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_51] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: java.io.IOException: Broken pipe > at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_51] > at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) > [rt.jar:1.7.0_51] > at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) > [rt.jar:1.7.0_51] > at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_51] > at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) > [rt.jar:1.7.0_51] > at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) > [xnio-nio-3.2.1.Final.jar:3.2.1.Final] > at > io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:529) > at > io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:251) > at > org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) > [xnio-api-3.2.1.Final.jar:3.2.1.Final] > at > io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100) > at org.xnio.channels.Channels.flushBlocking(Channels.java:63) > [xnio-api-3.2.1.Final.jar:3.2.1.Final] > at > io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:623) > at > io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451) > at > io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525) > ... 9 more > > > For this particular screen, we do send a lot of data back and forth via > REST requests. Some of it can be large. > > I have this setting in my http-listener: > max-buffered-request-size="10485760" max-header-size="7864320" > allow-equals-in-cookie-value="true"/> > > yes I picked those large values just to see if they would work and they > haven't. I see from this page: > http://undertow.io/documentation/core/listeners.html > > That there is a MAX_ENTITY_SIZE in Undertow but I can't seem to get > Wildfly to recognize it -- when I try max-entity-size="something" in the > http-listener tag, I get a validation error. > > Any ideas? > > > > -- > Mike Hostetler > http://mike.hostetlerhome.com/ > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140409/afd2c38d/attachment.html From hostetlerm at gmail.com Thu Apr 10 09:47:05 2014 From: hostetlerm at gmail.com (Mike Hostetler) Date: Thu, 10 Apr 2014 08:47:05 -0500 Subject: [undertow-dev] java.io.IOException: Broken pip In-Reply-To: References: Message-ID: Just verified that the same thing happens in Windows 7 as well as Linux. On Wed, Apr 9, 2014 at 4:49 PM, Toma? Cerar wrote: > What platform is this? Mac? Linux? Windows? > > > On Wed, Apr 9, 2014 at 9:24 PM, Mike Hostetler wrote: > >> I'm using a WildFly 8.0.1 nightly and can easily recreate this error: >> >> 14:01:30,134 ERROR [io.undertow.request] (default task-18) Blocking >> request failed HttpServerExchange{ GET /ottrservices/recentpatients}: >> java.lang.RuntimeException: java.io.IOException: Broken pipe >> at >> io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) >> at >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) >> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) >> at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> [rt.jar:1.7.0_51] >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> [rt.jar:1.7.0_51] >> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] >> Caused by: java.io.IOException: Broken pipe >> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_51] >> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) >> [rt.jar:1.7.0_51] >> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) >> [rt.jar:1.7.0_51] >> at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_51] >> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) >> [rt.jar:1.7.0_51] >> at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) >> [xnio-nio-3.2.1.Final.jar:3.2.1.Final] >> at >> io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:529) >> at >> io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:251) >> at >> org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) >> [xnio-api-3.2.1.Final.jar:3.2.1.Final] >> at >> io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100) >> at org.xnio.channels.Channels.flushBlocking(Channels.java:63) >> [xnio-api-3.2.1.Final.jar:3.2.1.Final] >> at >> io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:623) >> at >> io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451) >> at >> io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525) >> ... 9 more >> >> >> For this particular screen, we do send a lot of data back and forth via >> REST requests. Some of it can be large. >> >> I have this setting in my http-listener: >> > max-buffered-request-size="10485760" max-header-size="7864320" >> allow-equals-in-cookie-value="true"/> >> >> yes I picked those large values just to see if they would work and they >> haven't. I see from this page: >> http://undertow.io/documentation/core/listeners.html >> >> That there is a MAX_ENTITY_SIZE in Undertow but I can't seem to get >> Wildfly to recognize it -- when I try max-entity-size="something" in the >> http-listener tag, I get a validation error. >> >> Any ideas? >> >> >> >> -- >> Mike Hostetler >> http://mike.hostetlerhome.com/ >> >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> > > -- Mike Hostetler http://mike.hostetlerhome.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140410/aab16e08/attachment.html From oneil5045 at gmail.com Mon Apr 7 23:23:42 2014 From: oneil5045 at gmail.com (Bill O'Neil) Date: Mon, 7 Apr 2014 23:23:42 -0400 Subject: [undertow-dev] REST routing Message-ID: I was curious what the best practices would be for url routing with many endpoints. For example POST /user/ GET /user/{userId} GET /document/{documentId} ContentType=appliction/json (only respond when json is requested) What would be the best option for this? I was able to achieve most of what i wanted using the PredicatesHandler class. Is this a good choice? This would build a List of PredicatedHandlers as well as the fall through handler which I would use as a 404. I got an example working using the text predicate format method[GET] and path-template[value=\"/user/{userId}\"] Is this a good approach or are there better recommendations? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140407/0de908ab/attachment-0001.html From azure.mumu at gmail.com Tue Apr 8 23:39:09 2014 From: azure.mumu at gmail.com (=?GB2312?B?1cXB1g==?=) Date: Wed, 9 Apr 2014 11:39:09 +0800 Subject: [undertow-dev] Can't get customed header and attributes in the websocket handshakeheader. Message-ID: Hi, We registed a web socket handler in the server, waiting for the clients to connect. According to the usiness, we need to identify (or mark) a client when it do handshake with the server, so I tried to set some customed headers in the handshakeheader, just like: WebSocketConnectionManager manager = new WebSocketConnectionManager( webSocketClient, webSocketHandler, "ws://localhost:8080/websocket/myHandler"); manager.setAutoStartup(true); *manager.getHeaders().add("myHeader", "1234567");* return manager; I supposed to retrieve it from the WebSocketSession in the serverside, but I can't get it. it is ok in the jetty server 9. The server we used: wildfly 8.0.3 Release The client dependencies: org.springframework spring-context 4.0.3.RELEASE org.springframework spring-websocket 4.0.3.RELEASE javax.websocket javax.websocket-api 1.0 compile true io.undertow undertow-websockets-jsr 1.0.3.Final This issue blocked me for some days, could you please help to figure out what's the matter, and it is really appreciate if you can give some advice to achieve that. Thank you very much! Sincerely yours, Lynn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140409/ae9163cf/attachment-0001.html From azure.mumu at gmail.com Tue Apr 8 23:53:13 2014 From: azure.mumu at gmail.com (=?GB2312?B?1cXB1g==?=) Date: Wed, 9 Apr 2014 11:53:13 +0800 Subject: [undertow-dev] How to configure wss with undertow? Message-ID: Hi, In the client side, I want to use "wss" to communicate with the server, when I change the "ws" to "wss", it reported a error: *java.lang.IllegalArgumentException: XNIO000100: 'https' URL scheme chosen but no SSL provider given* So I try to provide a ssl provider XnioSsl, but I found the io.undertow.websockets.client.WebSocketClient not support. in the code ,it invokes the method: HttpUpgrade.performUpgrade(worker, null, newUri, headers, new ChannelListener(handshake, newUri, bufferPool, ioFuture); *NOT* HttpUpgradeState(final XnioWorker worker,* final XnioSsl ssl*, final InetSocketAddress bindAddress, final URI uri, final Map headers, final ChannelListener openListener, final ChannelListener bindListener, final OptionMap optionMap, final HandshakeChecker handshakeChecker) I think it doesn't support wss yet for undertow now? is it right? or could you tell me how to do this? Thanks. Sincerely yours, Lynn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140409/28695631/attachment.html From sdouglas at redhat.com Mon Apr 14 18:49:28 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 15 Apr 2014 08:49:28 +1000 Subject: [undertow-dev] java.io.IOException: Broken pip In-Reply-To: References: Message-ID: <534C65F8.2090001@redhat.com> In Wildfly it should be: I'm not sure why the name in the XML is different to the underlying option name. Stuart Mike Hostetler wrote: > I'm using a WildFly 8.0.1 nightly and can easily recreate this error: > > 14:01:30,134 ERROR [io.undertow.request] (default task-18) Blocking > request failed HttpServerExchange{ GET /ottrservices/recentpatients}: > java.lang.RuntimeException: java.io.IOException: Broken pipe > at > io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_51] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: java.io.IOException: Broken pipe > at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_51] > at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) > [rt.jar:1.7.0_51] > at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_51] > at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_51] > at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) > [rt.jar:1.7.0_51] > at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) > [xnio-nio-3.2.1.Final.jar:3.2.1.Final] > at > io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:529) > at > io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:251) > at > org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) > [xnio-api-3.2.1.Final.jar:3.2.1.Final] > at > io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100) > at org.xnio.channels.Channels.flushBlocking(Channels.java:63) > [xnio-api-3.2.1.Final.jar:3.2.1.Final] > at > io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:623) > at > io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451) > at > io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525) > ... 9 more > > > For this particular screen, we do send a lot of data back and forth via > REST requests. Some of it can be large. > > I have this setting in my http-listener: > max-buffered-request-size="10485760" max-header-size="7864320" > allow-equals-in-cookie-value="true"/> > > yes I picked those large values just to see if they would work and they > haven't. I see from this page: > http://undertow.io/documentation/core/listeners.html > > That there is a MAX_ENTITY_SIZE in Undertow but I can't seem to get > Wildfly to recognize it -- when I try max-entity-size="something" in the > http-listener tag, I get a validation error. > > Any ideas? > > > > -- > Mike Hostetler > http://mike.hostetlerhome.com/ > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Mon Apr 14 20:38:19 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 15 Apr 2014 10:38:19 +1000 Subject: [undertow-dev] REST routing In-Reply-To: References: Message-ID: <534C7F7B.8030908@redhat.com> Bill O'Neil wrote: > I was curious what the best practices would be for url routing with many > endpoints. > > For example > > POST /user/ > GET /user/{userId} > GET /document/{documentId} ContentType=appliction/json (only respond > when json is requested) > > What would be the best option for this? I was able to achieve most of > what i wanted using the PredicatesHandler class. Is this a good choice? That will work fine, although there are more efficient ways to do this. I think this will actually be a fairly common use case, so I have added a handler to handle this: https://github.com/undertow-io/undertow/commit/04385f29996673658bce3c131de4e0a32241e78e#diff-3 Basically it matches requests based on a combination of method, path template and predicate, and will be considerably more efficient that testing a list of predicates. Stuart > > This would build a List of PredicatedHandlers as well as the fall > through handler which I would use as a 404. I got an example working > using the text predicate format > > method[GET] and path-template[value=\"/user/{userId}\"] > > > Is this a good approach or are there better recommendations? > > > 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 Mon Apr 14 21:56:13 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 15 Apr 2014 11:56:13 +1000 Subject: [undertow-dev] Can't get customed header and attributes in the websocket handshakeheader. In-Reply-To: References: Message-ID: <534C91BD.303@redhat.com> This has been improved greatly in Undertow 1.0.5.Final. You can now provide an instance of io.undertow.websockets.client.WebSocketClientNegotiation that allows you to modify the headers. Stuart ?? wrote: > Hi, > We registed a web socket handler in the server, waiting for the clients > to connect. According to the usiness, we need to identify (or mark) a > client when it do handshake with the server, so I tried to set some > customed headers in the handshakeheader, just like: > WebSocketConnectionManager manager = new WebSocketConnectionManager( > webSocketClient, webSocketHandler, > "ws://localhost:8080/websocket/myHandler"); > manager.setAutoStartup(true); > *manager.getHeaders().add("myHeader", "1234567");* > return manager; > > I supposed to retrieve it from the WebSocketSession in the serverside, > but I can't get it. it is ok in the jetty server 9. > > > The server we used: wildfly 8.0.3 Release > The client dependencies: > > org.springframework > spring-context > 4.0.3.RELEASE > > > org.springframework > spring-websocket > 4.0.3.RELEASE > > > javax.websocket > javax.websocket-api > 1.0 > compile > true > > > io.undertow > undertow-websockets-jsr > 1.0.3.Final > > > This issue blocked me for some days, could you please help to figure out > what's the matter, and it is really appreciate if you can give some > advice to achieve that. Thank you very much! > > > Sincerely yours, > Lynn > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From jonathan.hart at gmail.com Tue Apr 15 19:27:43 2014 From: jonathan.hart at gmail.com (Jonathan Hart) Date: Tue, 15 Apr 2014 16:27:43 -0700 Subject: [undertow-dev] REST routing In-Reply-To: <534C7F7B.8030908@redhat.com> References: <534C7F7B.8030908@redhat.com> Message-ID: Hi everyone (new to this list) Many thanks for making this, I was trying to do the EXACT same thing with Undertow and was having a very hard time wrapping my head around predicates. On Mon, Apr 14, 2014 at 5:38 PM, Stuart Douglas wrote: > > > Bill O'Neil wrote: > > I was curious what the best practices would be for url routing with many > > endpoints. > > > > For example > > > > POST /user/ > > GET /user/{userId} > > GET /document/{documentId} ContentType=appliction/json (only respond > > when json is requested) > > > > What would be the best option for this? I was able to achieve most of > > what i wanted using the PredicatesHandler class. Is this a good choice? > > That will work fine, although there are more efficient ways to do this. > I think this will actually be a fairly common use case, so I have added > a handler to handle this: > > > https://github.com/undertow-io/undertow/commit/04385f29996673658bce3c131de4e0a32241e78e#diff-3 > > > Basically it matches requests based on a combination of method, path > template and predicate, and will be considerably more efficient that > testing a list of predicates. > > Stuart > > > > > > > This would build a List of PredicatedHandlers as well as the fall > > through handler which I would use as a 404. I got an example working > > using the text predicate format > > > > method[GET] and path-template[value=\"/user/{userId}\"] > > > > > > Is this a good approach or are there better recommendations? > > > > > > Thanks, > > > > Bill > > > > _______________________________________________ > > 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/20140415/edff8d67/attachment.html From oneil5045 at gmail.com Tue Apr 15 21:16:51 2014 From: oneil5045 at gmail.com (Bill O'Neil) Date: Tue, 15 Apr 2014 21:16:51 -0400 Subject: [undertow-dev] REST routing In-Reply-To: References: <534C7F7B.8030908@redhat.com> Message-ID: Thanks for the quick response. This is exactly what I was looking for. Bill On Tue, Apr 15, 2014 at 7:27 PM, Jonathan Hart wrote: > Hi everyone (new to this list) > > Many thanks for making this, I was trying to do the EXACT same thing with > Undertow and was having a very hard time wrapping my head around > predicates. > > > On Mon, Apr 14, 2014 at 5:38 PM, Stuart Douglas wrote: > >> >> >> Bill O'Neil wrote: >> > I was curious what the best practices would be for url routing with many >> > endpoints. >> > >> > For example >> > >> > POST /user/ >> > GET /user/{userId} >> > GET /document/{documentId} ContentType=appliction/json (only respond >> > when json is requested) >> > >> > What would be the best option for this? I was able to achieve most of >> > what i wanted using the PredicatesHandler class. Is this a good choice? >> >> That will work fine, although there are more efficient ways to do this. >> I think this will actually be a fairly common use case, so I have added >> a handler to handle this: >> >> >> https://github.com/undertow-io/undertow/commit/04385f29996673658bce3c131de4e0a32241e78e#diff-3 >> >> >> Basically it matches requests based on a combination of method, path >> template and predicate, and will be considerably more efficient that >> testing a list of predicates. >> >> Stuart >> >> >> >> > >> > This would build a List of PredicatedHandlers as well as the fall >> > through handler which I would use as a 404. I got an example working >> > using the text predicate format >> > >> > method[GET] and path-template[value=\"/user/{userId}\"] >> > >> > >> > Is this a good approach or are there better recommendations? >> > >> > >> > Thanks, >> > >> > Bill >> > >> > _______________________________________________ >> > 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/20140415/79443c1d/attachment-0001.html From sdouglas at redhat.com Wed Apr 16 03:30:26 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 16 Apr 2014 17:30:26 +1000 Subject: [undertow-dev] How to configure wss with undertow? In-Reply-To: References: Message-ID: <534E3192.8030706@redhat.com> ?? wrote: > Hi, > In the client side, I want to use "wss" to communicate with the server, > when I change the "ws" to "wss", it reported a error: > /java.lang.IllegalArgumentException: XNIO000100: 'https' URL scheme > chosen but no SSL provider given/ > > So I try to provide a ssl provider XnioSsl, but I found the > io.undertow.websockets.client.WebSocketClient not support. > > in the code ,it invokes the method: > HttpUpgrade.performUpgrade(worker, null, newUri, headers, new > ChannelListener(handshake, newUri, bufferPool, ioFuture); > > *NOT* > HttpUpgradeState(final XnioWorker worker,*final XnioSsl ssl*, final > InetSocketAddress bindAddress, final URI uri, final Map > headers, final ChannelListener openListener, final > ChannelListener bindListener, final OptionMap > optionMap, final HandshakeChecker handshakeChecker) > > > I think it doesn't support wss yet for undertow now? is it right? or > could you tell me how to do this? Thanks. Hmm, you are correct. I will fix this up in Undertow upstream. Stuart > > Sincerely yours, > Lynn > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From jonathan.hart at gmail.com Sun Apr 20 22:59:20 2014 From: jonathan.hart at gmail.com (Jonathan Hart) Date: Sun, 20 Apr 2014 19:59:20 -0700 Subject: [undertow-dev] REST routing In-Reply-To: References: <534C7F7B.8030908@redhat.com> Message-ID: Stuart, I was able to successfully set up a RoutingHandler, and it is matching templates correctly. However, how do I get access to the {variable} data itself once inside my matched handler? I have looked through all of the Handler methods/props and the only place I see the values are in the relative path, which would require me to re-parse the URL to get to the data I need.. A quick example is: /user/{userId} Which is matched when someone requests something like: /user/5 How do I get access to the "5"? Perhaps I'm too new to Undertow to miss something obvious, but some advice would be appreciated! On Tue, Apr 15, 2014 at 6:16 PM, Bill O'Neil wrote: > Thanks for the quick response. This is exactly what I was looking for. > > Bill > > > On Tue, Apr 15, 2014 at 7:27 PM, Jonathan Hart wrote: > >> Hi everyone (new to this list) >> >> Many thanks for making this, I was trying to do the EXACT same thing with >> Undertow and was having a very hard time wrapping my head around >> predicates. >> >> >> On Mon, Apr 14, 2014 at 5:38 PM, Stuart Douglas wrote: >> >>> >>> >>> Bill O'Neil wrote: >>> > I was curious what the best practices would be for url routing with >>> many >>> > endpoints. >>> > >>> > For example >>> > >>> > POST /user/ >>> > GET /user/{userId} >>> > GET /document/{documentId} ContentType=appliction/json (only respond >>> > when json is requested) >>> > >>> > What would be the best option for this? I was able to achieve most of >>> > what i wanted using the PredicatesHandler class. Is this a good choice? >>> >>> That will work fine, although there are more efficient ways to do this. >>> I think this will actually be a fairly common use case, so I have added >>> a handler to handle this: >>> >>> >>> https://github.com/undertow-io/undertow/commit/04385f29996673658bce3c131de4e0a32241e78e#diff-3 >>> >>> >>> Basically it matches requests based on a combination of method, path >>> template and predicate, and will be considerably more efficient that >>> testing a list of predicates. >>> >>> Stuart >>> >>> >>> >>> > >>> > This would build a List of PredicatedHandlers as well as the fall >>> > through handler which I would use as a 404. I got an example working >>> > using the text predicate format >>> > >>> > method[GET] and path-template[value=\"/user/{userId}\"] >>> > >>> > >>> > Is this a good approach or are there better recommendations? >>> > >>> > >>> > Thanks, >>> > >>> > Bill >>> > >>> > _______________________________________________ >>> > 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/20140420/b41a0660/attachment.html From bill at dartalley.com Sun Apr 20 23:03:15 2014 From: bill at dartalley.com (Bill O'Neil) Date: Sun, 20 Apr 2014 23:03:15 -0400 Subject: [undertow-dev] REST routing In-Reply-To: References: <534C7F7B.8030908@redhat.com> Message-ID: I believe by default all path parameters will be written as query parameters. You can read them the same way you read query parameters. However if you have a path parameter and a query parameter with the same name this can cause issues. There is a flag to NOT rewrite path parameters as query params if you wish to use that. There is a second way to get the path parameter values but I cannot remember it off of the top of my head. On Sun, Apr 20, 2014 at 10:59 PM, Jonathan Hart wrote: > Stuart, > > I was able to successfully set up a RoutingHandler, and it is matching > templates correctly. However, how do I get access to the {variable} data > itself once inside my matched handler? > > I have looked through all of the Handler methods/props and the only place > I see the values are in the relative path, which would require me to > re-parse the URL to get to the data I need.. > > A quick example is: > > /user/{userId} > > Which is matched when someone requests something like: > > /user/5 > > How do I get access to the "5"? Perhaps I'm too new to Undertow to miss > something obvious, but some advice would be appreciated! > > > On Tue, Apr 15, 2014 at 6:16 PM, Bill O'Neil wrote: > >> Thanks for the quick response. This is exactly what I was looking for. >> >> Bill >> >> >> On Tue, Apr 15, 2014 at 7:27 PM, Jonathan Hart wrote: >> >>> Hi everyone (new to this list) >>> >>> Many thanks for making this, I was trying to do the EXACT same thing >>> with Undertow and was having a very hard time wrapping my head around >>> predicates. >>> >>> >>> On Mon, Apr 14, 2014 at 5:38 PM, Stuart Douglas wrote: >>> >>>> >>>> >>>> Bill O'Neil wrote: >>>> > I was curious what the best practices would be for url routing with >>>> many >>>> > endpoints. >>>> > >>>> > For example >>>> > >>>> > POST /user/ >>>> > GET /user/{userId} >>>> > GET /document/{documentId} ContentType=appliction/json (only respond >>>> > when json is requested) >>>> > >>>> > What would be the best option for this? I was able to achieve most of >>>> > what i wanted using the PredicatesHandler class. Is this a good >>>> choice? >>>> >>>> That will work fine, although there are more efficient ways to do this. >>>> I think this will actually be a fairly common use case, so I have added >>>> a handler to handle this: >>>> >>>> >>>> https://github.com/undertow-io/undertow/commit/04385f29996673658bce3c131de4e0a32241e78e#diff-3 >>>> >>>> >>>> Basically it matches requests based on a combination of method, path >>>> template and predicate, and will be considerably more efficient that >>>> testing a list of predicates. >>>> >>>> Stuart >>>> >>>> >>>> >>>> > >>>> > This would build a List of PredicatedHandlers as well as the fall >>>> > through handler which I would use as a 404. I got an example working >>>> > using the text predicate format >>>> > >>>> > method[GET] and path-template[value=\"/user/{userId}\"] >>>> > >>>> > >>>> > Is this a good approach or are there better recommendations? >>>> > >>>> > >>>> > Thanks, >>>> > >>>> > Bill >>>> > >>>> > _______________________________________________ >>>> > undertow-dev mailing list >>>> > undertow-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/undertow-dev >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>> >>> >>> >> > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140420/60405639/attachment.html From jonathan.hart at gmail.com Mon Apr 21 00:09:14 2014 From: jonathan.hart at gmail.com (Jonathan Hart) Date: Sun, 20 Apr 2014 21:09:14 -0700 Subject: [undertow-dev] REST routing In-Reply-To: References: <534C7F7B.8030908@redhat.com> Message-ID: Thanks for the tip. I was only able to get the parameters if the constructor for the RoutingHandler was set to true (rewrite as query params). If it is set to false, I'm not seeing them show up in pathParameters. It is still null. On Sun, Apr 20, 2014 at 8:03 PM, Bill O'Neil wrote: > I believe by default all path parameters will be written as query > parameters. You can read them the same way you read query parameters. > However if you have a path parameter and a query parameter with the same > name this can cause issues. There is a flag to NOT rewrite path parameters > as query params if you wish to use that. There is a second way to get the > path parameter values but I cannot remember it off of the top of my head. > > > On Sun, Apr 20, 2014 at 10:59 PM, Jonathan Hart wrote: > >> Stuart, >> >> I was able to successfully set up a RoutingHandler, and it is matching >> templates correctly. However, how do I get access to the {variable} data >> itself once inside my matched handler? >> >> I have looked through all of the Handler methods/props and the only place >> I see the values are in the relative path, which would require me to >> re-parse the URL to get to the data I need.. >> >> A quick example is: >> >> /user/{userId} >> >> Which is matched when someone requests something like: >> >> /user/5 >> >> How do I get access to the "5"? Perhaps I'm too new to Undertow to miss >> something obvious, but some advice would be appreciated! >> >> >> On Tue, Apr 15, 2014 at 6:16 PM, Bill O'Neil wrote: >> >>> Thanks for the quick response. This is exactly what I was looking for. >>> >>> Bill >>> >>> >>> On Tue, Apr 15, 2014 at 7:27 PM, Jonathan Hart wrote: >>> >>>> Hi everyone (new to this list) >>>> >>>> Many thanks for making this, I was trying to do the EXACT same thing >>>> with Undertow and was having a very hard time wrapping my head around >>>> predicates. >>>> >>>> >>>> On Mon, Apr 14, 2014 at 5:38 PM, Stuart Douglas wrote: >>>> >>>>> >>>>> >>>>> Bill O'Neil wrote: >>>>> > I was curious what the best practices would be for url routing with >>>>> many >>>>> > endpoints. >>>>> > >>>>> > For example >>>>> > >>>>> > POST /user/ >>>>> > GET /user/{userId} >>>>> > GET /document/{documentId} ContentType=appliction/json (only respond >>>>> > when json is requested) >>>>> > >>>>> > What would be the best option for this? I was able to achieve most of >>>>> > what i wanted using the PredicatesHandler class. Is this a good >>>>> choice? >>>>> >>>>> That will work fine, although there are more efficient ways to do this. >>>>> I think this will actually be a fairly common use case, so I have added >>>>> a handler to handle this: >>>>> >>>>> >>>>> https://github.com/undertow-io/undertow/commit/04385f29996673658bce3c131de4e0a32241e78e#diff-3 >>>>> >>>>> >>>>> Basically it matches requests based on a combination of method, path >>>>> template and predicate, and will be considerably more efficient that >>>>> testing a list of predicates. >>>>> >>>>> Stuart >>>>> >>>>> >>>>> >>>>> > >>>>> > This would build a List of PredicatedHandlers as well as the fall >>>>> > through handler which I would use as a 404. I got an example working >>>>> > using the text predicate format >>>>> > >>>>> > method[GET] and path-template[value=\"/user/{userId}\"] >>>>> > >>>>> > >>>>> > Is this a good approach or are there better recommendations? >>>>> > >>>>> > >>>>> > Thanks, >>>>> > >>>>> > Bill >>>>> > >>>>> > _______________________________________________ >>>>> > undertow-dev mailing list >>>>> > undertow-dev at lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/undertow-dev >>>>> _______________________________________________ >>>>> undertow-dev mailing list >>>>> undertow-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>>> >>>> >>>> >>> >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140420/62f61e80/attachment-0001.html From sdouglas at redhat.com Mon Apr 21 02:35:18 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 21 Apr 2014 16:35:18 +1000 Subject: [undertow-dev] REST routing In-Reply-To: References: <534C7F7B.8030908@redhat.com> Message-ID: <5354BC26.1060308@redhat.com> Two options. If you set the 'rewriteQueryParameters' option to true in the handler then they will be available in the exchange query parameters. Otherwise they can be retrieved from the exchange as an attachment under the io.undertow.util.PathTemplateMatch.ATTACHMENT_KEY key. Stuart Jonathan Hart wrote: > Stuart, > > I was able to successfully set up a RoutingHandler, and it is matching > templates correctly. However, how do I get access to the {variable} data > itself once inside my matched handler? > > I have looked through all of the Handler methods/props and the only > place I see the values are in the relative path, which would require me > to re-parse the URL to get to the data I need.. > > A quick example is: > > /user/{userId} > > Which is matched when someone requests something like: > > /user/5 > > How do I get access to the "5"? Perhaps I'm too new to Undertow to miss > something obvious, but some advice would be appreciated! > > > On Tue, Apr 15, 2014 at 6:16 PM, Bill O'Neil > wrote: > > Thanks for the quick response. This is exactly what I was looking for. > > Bill > > > On Tue, Apr 15, 2014 at 7:27 PM, Jonathan Hart > > wrote: > > Hi everyone (new to this list) > > Many thanks for making this, I was trying to do the EXACT same > thing with Undertow and was having a very hard time wrapping my > head around predicates. > > > On Mon, Apr 14, 2014 at 5:38 PM, Stuart Douglas > > wrote: > > > > Bill O'Neil wrote: > > I was curious what the best practices would be for url > routing with many > > endpoints. > > > > For example > > > > POST /user/ > > GET /user/{userId} > > GET /document/{documentId} ContentType=appliction/json > (only respond > > when json is requested) > > > > What would be the best option for this? I was able to > achieve most of > > what i wanted using the PredicatesHandler class. Is this > a good choice? > > That will work fine, although there are more efficient ways > to do this. > I think this will actually be a fairly common use case, so I > have added > a handler to handle this: > > https://github.com/undertow-io/undertow/commit/04385f29996673658bce3c131de4e0a32241e78e#diff-3 > > > Basically it matches requests based on a combination of > method, path > template and predicate, and will be considerably more > efficient that > testing a list of predicates. > > Stuart > > > > > > > This would build a List of PredicatedHandlers as well as > the fall > > through handler which I would use as a 404. I got an > example working > > using the text predicate format > > > > method[GET] and path-template[value=\"/user/{userId}\"] > > > > > > Is this a good approach or are there better recommendations? > > > > > > Thanks, > > > > Bill > > > > _______________________________________________ > > 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 draganj at gmail.com Fri Apr 25 14:29:47 2014 From: draganj at gmail.com (Dragan Jotanovic) Date: Fri, 25 Apr 2014 19:29:47 +0100 Subject: [undertow-dev] Embedded undertow with servlet deployment and dispatch to worker threads Message-ID: Hi, I did some testing with servlet deployment on undertow and it seems that servlet requests are always executed on IO thread instead of dispatched to worker threads. Basically I used modified servlet example from undertow github (I just added Thread.sleep(5000) to servlet). When I send request simultaneously from two browser tabs, first request is retrieved after 5 seconds as expected, but the second after 10 seconds, which means that IO thread was blocked until first request was completed. Is there some configuration parameter in DeploymentInfo which forces request to be dispatched to worker threads, or is there some other way to prevent IO thread from blocking? Bellow is the example source: import javax.servlet.ServletConfig; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import io.undertow.Handlers; import io.undertow.Undertow; import io.undertow.server.HttpHandler; import io.undertow.server.handlers.PathHandler; import io.undertow.servlet.api.DeploymentInfo; import io.undertow.servlet.api.DeploymentManager; import java.io.IOException; import java.io.PrintWriter; import static io.undertow.servlet.Servlets.defaultContainer; import static io.undertow.servlet.Servlets.deployment; import static io.undertow.servlet.Servlets.servlet; public class TestServer { public static class TestServlet extends HttpServlet { @Override public void init(final ServletConfig config) throws ServletException { super.init(config); } @Override protected void doGet(final HttpServletRequest req, final HttpServletResponse resp) throws ServletException, IOException { try { Thread.sleep(5000); } catch (InterruptedException e) { e.printStackTrace(); } PrintWriter writer = resp.getWriter(); writer.write("Done!"); writer.close(); } @Override protected void doPost(final HttpServletRequest req, final HttpServletResponse resp) throws ServletException, IOException { doGet(req, resp); } } public static void main(String[] args) { try { String context = "/"; DeploymentInfo servletBuilder = deployment() .setClassLoader(TestServer.class.getClassLoader()) .setContextPath(context) .setDeploymentName("test.war") .addServlets( servlet("TestServlet", TestServer.TestServlet.class) .addMapping("/*")); DeploymentManager manager = defaultContainer().addDeployment(servletBuilder); manager.deploy(); HttpHandler servletHandler = manager.start(); PathHandler path = Handlers.path(Handlers.redirect(context)) .addPrefixPath(context, servletHandler); Undertow server = Undertow.builder() .addHttpListener(8181, "0.0.0.0") .setHandler(path) .build(); server.start(); } catch (ServletException e) { throw new RuntimeException(e); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140425/7dfc68c3/attachment.html From jason.greene at redhat.com Fri Apr 25 14:38:00 2014 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 25 Apr 2014 13:38:00 -0500 Subject: [undertow-dev] Embedded undertow with servlet deployment and dispatch to worker threads In-Reply-To: References: Message-ID: <68272E82-A756-463E-898B-A56C003FCAC7@redhat.com> A worker is definitely being used. However, the behavior you are seeing is happening because your web browser is reusing the same connection to issue the second request. If you execute multiple curl commands you should see processing concurrently. On Apr 25, 2014, at 1:29 PM, Dragan Jotanovic wrote: > Hi, > I did some testing with servlet deployment on undertow and it seems that servlet requests are always executed on IO thread instead of dispatched to worker threads. > > Basically I used modified servlet example from undertow github (I just added Thread.sleep(5000) to servlet). When I send request simultaneously from two browser tabs, first request is retrieved after 5 seconds as expected, but the second after 10 seconds, which means that IO thread was blocked until first request was completed. > Is there some configuration parameter in DeploymentInfo which forces request to be dispatched to worker threads, or is there some other way to prevent IO thread from blocking? > > Bellow is the example source: > > import javax.servlet.ServletConfig; > import javax.servlet.ServletException; > import javax.servlet.http.HttpServlet; > import javax.servlet.http.HttpServletRequest; > import javax.servlet.http.HttpServletResponse; > > import io.undertow.Handlers; > import io.undertow.Undertow; > import io.undertow.server.HttpHandler; > import io.undertow.server.handlers.PathHandler; > import io.undertow.servlet.api.DeploymentInfo; > import io.undertow.servlet.api.DeploymentManager; > > import java.io.IOException; > import java.io.PrintWriter; > > import static io.undertow.servlet.Servlets.defaultContainer; > import static io.undertow.servlet.Servlets.deployment; > import static io.undertow.servlet.Servlets.servlet; > > public class TestServer { > public static class TestServlet extends HttpServlet { > @Override > public void init(final ServletConfig config) throws ServletException { > super.init(config); > } > > @Override > protected void doGet(final HttpServletRequest req, final HttpServletResponse resp) throws ServletException, IOException { > try { > Thread.sleep(5000); > } catch (InterruptedException e) { > e.printStackTrace(); > } > PrintWriter writer = resp.getWriter(); > writer.write("Done!"); > writer.close(); > } > > @Override > protected void doPost(final HttpServletRequest req, final HttpServletResponse resp) throws ServletException, IOException { > doGet(req, resp); > } > } > > public static void main(String[] args) { > try { > String context = "/"; > DeploymentInfo servletBuilder = deployment() > .setClassLoader(TestServer.class.getClassLoader()) > .setContextPath(context) > .setDeploymentName("test.war") > .addServlets( > servlet("TestServlet", TestServer.TestServlet.class) > .addMapping("/*")); > > DeploymentManager manager = defaultContainer().addDeployment(servletBuilder); > manager.deploy(); > > HttpHandler servletHandler = manager.start(); > PathHandler path = Handlers.path(Handlers.redirect(context)) > .addPrefixPath(context, servletHandler); > Undertow server = Undertow.builder() > .addHttpListener(8181, "0.0.0.0") > .setHandler(path) > .build(); > server.start(); > } catch (ServletException e) { > throw new RuntimeException(e); > } > } > } > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Fri Apr 25 14:38:00 2014 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 25 Apr 2014 13:38:00 -0500 Subject: [undertow-dev] Embedded undertow with servlet deployment and dispatch to worker threads In-Reply-To: References: Message-ID: <9815BCDB-2BFF-4966-97A7-ACBC76C10639@redhat.com> A worker is definitely being used. However, the behavior you are seeing is happening because your web browser is reusing the same connection to issue the second request. If you execute multiple curl commands you should see processing concurrently. On Apr 25, 2014, at 1:29 PM, Dragan Jotanovic wrote: > Hi, > I did some testing with servlet deployment on undertow and it seems that servlet requests are always executed on IO thread instead of dispatched to worker threads. > > Basically I used modified servlet example from undertow github (I just added Thread.sleep(5000) to servlet). When I send request simultaneously from two browser tabs, first request is retrieved after 5 seconds as expected, but the second after 10 seconds, which means that IO thread was blocked until first request was completed. > Is there some configuration parameter in DeploymentInfo which forces request to be dispatched to worker threads, or is there some other way to prevent IO thread from blocking? > > Bellow is the example source: > > import javax.servlet.ServletConfig; > import javax.servlet.ServletException; > import javax.servlet.http.HttpServlet; > import javax.servlet.http.HttpServletRequest; > import javax.servlet.http.HttpServletResponse; > > import io.undertow.Handlers; > import io.undertow.Undertow; > import io.undertow.server.HttpHandler; > import io.undertow.server.handlers.PathHandler; > import io.undertow.servlet.api.DeploymentInfo; > import io.undertow.servlet.api.DeploymentManager; > > import java.io.IOException; > import java.io.PrintWriter; > > import static io.undertow.servlet.Servlets.defaultContainer; > import static io.undertow.servlet.Servlets.deployment; > import static io.undertow.servlet.Servlets.servlet; > > public class TestServer { > public static class TestServlet extends HttpServlet { > @Override > public void init(final ServletConfig config) throws ServletException { > super.init(config); > } > > @Override > protected void doGet(final HttpServletRequest req, final HttpServletResponse resp) throws ServletException, IOException { > try { > Thread.sleep(5000); > } catch (InterruptedException e) { > e.printStackTrace(); > } > PrintWriter writer = resp.getWriter(); > writer.write("Done!"); > writer.close(); > } > > @Override > protected void doPost(final HttpServletRequest req, final HttpServletResponse resp) throws ServletException, IOException { > doGet(req, resp); > } > } > > public static void main(String[] args) { > try { > String context = "/"; > DeploymentInfo servletBuilder = deployment() > .setClassLoader(TestServer.class.getClassLoader()) > .setContextPath(context) > .setDeploymentName("test.war") > .addServlets( > servlet("TestServlet", TestServer.TestServlet.class) > .addMapping("/*")); > > DeploymentManager manager = defaultContainer().addDeployment(servletBuilder); > manager.deploy(); > > HttpHandler servletHandler = manager.start(); > PathHandler path = Handlers.path(Handlers.redirect(context)) > .addPrefixPath(context, servletHandler); > Undertow server = Undertow.builder() > .addHttpListener(8181, "0.0.0.0") > .setHandler(path) > .build(); > server.start(); > } catch (ServletException e) { > throw new RuntimeException(e); > } > } > } > > _______________________________________________ > 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 derrick.childers at gmail.com Fri Apr 25 14:43:39 2014 From: derrick.childers at gmail.com (Derrick Childers) Date: Fri, 25 Apr 2014 14:43:39 -0400 Subject: [undertow-dev] Wrong JSESSIONID cookie Message-ID: I think I've found a bug in undertow and I have patch. I thought I'd explain. We have multiple War's serving a site. One war covers the root context '/' and a variety of sub paths/contexts. A couple of other war's server specific sub contexts, such as /selfserve. If you open a browser and go to / and look at the browser cookies you will see JSESSIONID with path=/. Then go to /selfserve and look at the cookies. You now have two JSESSIONID cookies. One for path=/ and one for path=/selfserve. As far as I know this is all normal and correct. From here when my app tries to use the session it fails in various ways. What I found was that if I deleted the JSESSIONID cookie that was associated with path=/ then everything worked. After digging around in the code I found where the cookies are being added to a HashMap by the name. It looks like the last cookie loaded wins, which means the correct cookie is loaded first then overridden by the wrong one. I have a patch in git and can send a pull request. -- Derrick Childers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140425/fa1df448/attachment-0001.html From derrick.childers at gmail.com Fri Apr 25 14:49:09 2014 From: derrick.childers at gmail.com (Derrick Childers) Date: Fri, 25 Apr 2014 14:49:09 -0400 Subject: [undertow-dev] Wrong JSESSIONID cookie In-Reply-To: References: Message-ID: Sorry, here is the change I made if additional or cookies already contains the name then just return... io.undertow.util.Cookies: private static int createCookie(final String name, final String value, int maxCookies, int cookieCount, final Map cookies, final Map additional) { if (name.charAt(0) == '$') { //added if(additional.containsKey(name)) { return cookieCount; } additional.put(name, value); return cookieCount; } else { if (cookieCount == maxCookies) { throw UndertowMessages.MESSAGES.tooManyCookies(maxCookies); } //added if(cookies.containsKey(name)) { return cookieCount; } cookies.put(name, value); return ++cookieCount; } } On Fri, Apr 25, 2014 at 2:43 PM, Derrick Childers < derrick.childers at gmail.com> wrote: > I think I've found a bug in undertow and I have patch. I thought I'd > explain. We have multiple War's serving a site. One war covers the root > context '/' and a variety of sub paths/contexts. A couple of other war's > server specific sub contexts, such as /selfserve. If you open a browser > and go to / and look at the browser cookies you will see JSESSIONID with > path=/. Then go to /selfserve and look at the cookies. You now have two > JSESSIONID cookies. One for path=/ and one for path=/selfserve. As far as > I know this is all normal and correct. From here when my app tries to use > the session it fails in various ways. What I found was that if I deleted > the JSESSIONID cookie that was associated with path=/ then everything > worked. After digging around in the code I found where the cookies are > being added to a HashMap by the name. It looks like the last cookie loaded > wins, which means the correct cookie is loaded first then overridden by the > wrong one. > > I have a patch in git and can send a pull request. > > -- > Derrick Childers > -- Derrick Childers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140425/b0a6f1da/attachment.html From draganj at gmail.com Fri Apr 25 14:52:25 2014 From: draganj at gmail.com (Dragan Jotanovic) Date: Fri, 25 Apr 2014 19:52:25 +0100 Subject: [undertow-dev] Embedded undertow with servlet deployment and dispatch to worker threads In-Reply-To: <68272E82-A756-463E-898B-A56C003FCAC7@redhat.com> References: <68272E82-A756-463E-898B-A56C003FCAC7@redhat.com> Message-ID: You are right. Thanks. On Fri, Apr 25, 2014 at 7:38 PM, Jason Greene wrote: > A worker is definitely being used. However, the behavior you are seeing is > happening because your web browser is reusing the same connection to issue > the second request. If you execute multiple curl commands you should see > processing concurrently. > > On Apr 25, 2014, at 1:29 PM, Dragan Jotanovic wrote: > > > Hi, > > I did some testing with servlet deployment on undertow and it seems that > servlet requests are always executed on IO thread instead of dispatched to > worker threads. > > > > Basically I used modified servlet example from undertow github (I just > added Thread.sleep(5000) to servlet). When I send request simultaneously > from two browser tabs, first request is retrieved after 5 seconds as > expected, but the second after 10 seconds, which means that IO thread was > blocked until first request was completed. > > Is there some configuration parameter in DeploymentInfo which forces > request to be dispatched to worker threads, or is there some other way to > prevent IO thread from blocking? > > > > Bellow is the example source: > > > > import javax.servlet.ServletConfig; > > import javax.servlet.ServletException; > > import javax.servlet.http.HttpServlet; > > import javax.servlet.http.HttpServletRequest; > > import javax.servlet.http.HttpServletResponse; > > > > import io.undertow.Handlers; > > import io.undertow.Undertow; > > import io.undertow.server.HttpHandler; > > import io.undertow.server.handlers.PathHandler; > > import io.undertow.servlet.api.DeploymentInfo; > > import io.undertow.servlet.api.DeploymentManager; > > > > import java.io.IOException; > > import java.io.PrintWriter; > > > > import static io.undertow.servlet.Servlets.defaultContainer; > > import static io.undertow.servlet.Servlets.deployment; > > import static io.undertow.servlet.Servlets.servlet; > > > > public class TestServer { > > public static class TestServlet extends HttpServlet { > > @Override > > public void init(final ServletConfig config) throws > ServletException { > > super.init(config); > > } > > > > @Override > > protected void doGet(final HttpServletRequest req, final > HttpServletResponse resp) throws ServletException, IOException { > > try { > > Thread.sleep(5000); > > } catch (InterruptedException e) { > > e.printStackTrace(); > > } > > PrintWriter writer = resp.getWriter(); > > writer.write("Done!"); > > writer.close(); > > } > > > > @Override > > protected void doPost(final HttpServletRequest req, final > HttpServletResponse resp) throws ServletException, IOException { > > doGet(req, resp); > > } > > } > > > > public static void main(String[] args) { > > try { > > String context = "/"; > > DeploymentInfo servletBuilder = deployment() > > .setClassLoader(TestServer.class.getClassLoader()) > > .setContextPath(context) > > .setDeploymentName("test.war") > > .addServlets( > > servlet("TestServlet", > TestServer.TestServlet.class) > > .addMapping("/*")); > > > > DeploymentManager manager = > defaultContainer().addDeployment(servletBuilder); > > manager.deploy(); > > > > HttpHandler servletHandler = manager.start(); > > PathHandler path = Handlers.path(Handlers.redirect(context)) > > .addPrefixPath(context, servletHandler); > > Undertow server = Undertow.builder() > > .addHttpListener(8181, "0.0.0.0") > > .setHandler(path) > > .build(); > > server.start(); > > } catch (ServletException e) { > > throw new RuntimeException(e); > > } > > } > > } > > > > _______________________________________________ > > 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/20140425/6af71648/attachment.html From ronny.karallus at gmail.com Mon Apr 28 05:30:31 2014 From: ronny.karallus at gmail.com (Ronny Karallus) Date: Mon, 28 Apr 2014 11:30:31 +0200 Subject: [undertow-dev] Caching Proxy / Proxy Extensions Message-ID: Hi Undertow Team, I just took a quick glimpse into Undertow, to be honest, as I was just evaluating it for a project. I planed to use it as a standalone reverse proxy including caching and SSI as an alternative to apache. However, as far as I saw this is not yet a feature set available in Undertow. Anyway, I am not worried to get my hands dirty and add a bit of code myself, so I looked a bit closer onto the proxy example and the underlying classes. As far as I saw it should be possible to add a CacheHandler in front of the ProxyHandler that just uses the proxy handler in case of a miss. However, I did not find a good way to hook into the Proxy Handler (it's also final :( ) to extend its functionality to store the response in the cache. Is there any way to do this? I'd love to have a hook on each processor that enables the developer to add response processors. There I could add the cache storage and also the SSI processing. Is something like this planed or already available and just overlooked by me? Appreciate your time Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140428/44528c27/attachment.html From sdouglas at redhat.com Mon Apr 28 20:36:45 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 28 Apr 2014 17:36:45 -0700 Subject: [undertow-dev] Caching Proxy / Proxy Extensions In-Reply-To: References: Message-ID: <535EF41D.8070807@redhat.com> Ronny Karallus wrote: > Hi Undertow Team, > > I just took a quick glimpse into Undertow, to be honest, as I was just > evaluating it for a project. I planed to use it as a standalone reverse > proxy including caching and SSI as an alternative to apache. > > However, as far as I saw this is not yet a feature set available in > Undertow. Anyway, I am not worried to get my hands dirty and add a bit > of code myself, so I looked a bit closer onto the proxy example and the > underlying classes. > > As far as I saw it should be possible to add a CacheHandler in front of > the ProxyHandler that just uses the proxy handler in case of a miss. > However, I did not find a good way to hook into the Proxy Handler (it's > also final :( ) to extend its functionality to store the response in the > cache. There are currently two options here. One would be to implement some kind of caching ProxyClient implementation that delegates to a real ProxyClient, however this would probably be a fair amount of work, and not a great solution as the ProxyClient API is really not designed to be wrapped in this way. The other way would be to use io.undertow.server.handlers.cache.CacheHandler. The intention of this handler was to be a generic caching handler, however it does still need some work (which is why it is not present in the Handlers utility class). If you file a JIRA about this I will add something to allow this in the 1.1 branch, I think we need some kind of a 'client interceptor' concept, to allow for the request and response to be modified. Stuart > > Is there any way to do this? I'd love to have a hook on each processor > that enables the developer to add response processors. There I could add > the cache storage and also the SSI processing. Is something like this > planed or already available and just overlooked by me? > > Appreciate your time > > Best Regards > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev