From ari.brandeis.king at gmail.com Fri Aug 7 17:53:00 2015 From: ari.brandeis.king at gmail.com (Ari King) Date: Fri, 7 Aug 2015 22:53:00 +0100 Subject: [undertow-dev] How to Access ServletContext? Message-ID: I've embedded Undertow into a Resteasy (JAX-RS) app. One of the libraries I'm using requires a servlet context attribute to be set. How can/should I go about doing so? If I should use a ServletExtension, to clarify, I need to create a file named "io.undertow.servlet.ServletExtension" and put it in the "META-INF/services/" directory? Within the above mentioned file do I need to provide the fully qualified name of the implementation class? Thanks. Best, Ari -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150807/9c8f5001/attachment-0001.html From alr at spinscale.de Sat Aug 8 09:03:36 2015 From: alr at spinscale.de (Alexander Reelsen) Date: Sat, 8 Aug 2015 15:03:36 +0200 Subject: [undertow-dev] Handler to proxy & log request bodies Message-ID: Hey, I am currently taking a look at undertow in order to write a small proxy (which is dead easy), that should log the incoming request into another data sink, then forward the request to the proxy, receive the response and log some parts of the JSON response (together with the request data) into that data sink plus forwarding it back to client. Just reading the input stream in a special proxy handler does not seem to work, so I guess there is a much smarter solution, like one of the listeners I could add to an exchange. Any help is highly appreciated. Thanks a lot! --Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150808/b7ed9d13/attachment.html From paulo at mlopes.net Wed Aug 5 05:05:31 2015 From: paulo at mlopes.net (Paulo Lopes) Date: Wed, 5 Aug 2015 11:05:31 +0200 (CEST) Subject: [undertow-dev] how to pipe a channel to a async HttpExchange? Message-ID: <1214790403.148724.1438765531597.JavaMail.open-xchange@app4.ox.privateemail.com> An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150805/6eea434a/attachment.html From basti.cremazo at gmail.com Wed Aug 5 05:24:33 2015 From: basti.cremazo at gmail.com (Cremazo Basti) Date: Wed, 5 Aug 2015 11:24:33 +0200 Subject: [undertow-dev] Mod JK with Wildfly 8 Message-ID: Hello, I experienced a strange behavior when i tried to connect apache httpd with wildfly using mod_jk:there thousands of threads that are created in the wildfly JVM. I am looking for any explantion and/or fix. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150805/5530f575/attachment.html From scrapmachines at gmail.com Thu Aug 6 10:40:10 2015 From: scrapmachines at gmail.com (Girish Sharma) Date: Thu, 6 Aug 2015 20:10:10 +0530 Subject: [undertow-dev] Combining encoding handlers with non-encoding handlers Message-ID: Hi team, I am trying to have a situation like this: Path A - response is gzipped, Path B - response is *not* gzipped. But from extensive searching, I could only figure out a way to make all paths as gzipped response. For example: Undertow.builder().addHttpListener(8080, "localhost").setHandler(new EncodingHandler(new ContentEncodingRepository().addEncodingHandler( "gzip", new GzipEncodingProvider(), 50, Predicates.parse("max-content-size[5]") ) ).setNext(Handlers.path() .addPrefixPath("/pathA", pathA::handle) .addPrefixPath("/pathB", pathAB::handle )).build(); will make both Path A and Path B as gzip encoded response. Any way to make only 1 of them give gzipped response? Regards -- Girish Sharma B.Tech(H), Civil Engineering, Indian Institute of Technology, Kharagpur -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150806/0ab7c57b/attachment.html From basti.cremazo at gmail.com Fri Aug 7 09:48:39 2015 From: basti.cremazo at gmail.com (Cremazo Basti) Date: Fri, 7 Aug 2015 15:48:39 +0200 Subject: [undertow-dev] Mod JK with Wildfly 8 In-Reply-To: References: Message-ID: well, i figured ou that these threads were created by my load balance. To monitor the apache server he sends every few seconds an http request which is forwarded to wildfly. these requests are handled through default-task threads. The high number of these threads is due to undefinded "task-max-thread" attribue of the io subsystem, and this attribute defauls the some thing like 16*number of cpu. 2015-08-05 11:24 GMT+02:00 Cremazo Basti : > Hello, > > I experienced a strange behavior when i tried to connect apache httpd with > wildfly using mod_jk:there thousands of threads that are created in the > wildfly JVM. > > I am looking for any explantion and/or fix. > > > Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150807/611c7964/attachment.html From sdouglas at redhat.com Mon Aug 10 02:02:10 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 10 Aug 2015 02:02:10 -0400 (EDT) Subject: [undertow-dev] Handler to proxy & log request bodies In-Reply-To: References: Message-ID: <303194196.9228522.1439186530845.JavaMail.zimbra@redhat.com> I think the best way capture the data is to use the HttpServerExchange methods addRequestWrapper and addResponseWrapper. These allow you to implement a Conduit that can see all the data as it is being read/written. Stuart ----- Original Message ----- > From: "Alexander Reelsen" > To: undertow-dev at lists.jboss.org > Sent: Saturday, 8 August, 2015 11:03:36 PM > Subject: [undertow-dev] Handler to proxy & log request bodies > > Hey, > > I am currently taking a look at undertow in order to write a small proxy > (which is dead easy), that should log the incoming request into another data > sink, then forward the request to the proxy, receive the response and log > some parts of the JSON response (together with the request data) into that > data sink plus forwarding it back to client. > > Just reading the input stream in a special proxy handler does not seem to > work, so I guess there is a much smarter solution, like one of the listeners > I could add to an exchange. > > Any help is highly appreciated. Thanks a lot! > > > --Alex > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Mon Aug 10 02:06:28 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 10 Aug 2015 02:06:28 -0400 (EDT) Subject: [undertow-dev] How to Access ServletContext? In-Reply-To: References: Message-ID: <96533099.9229567.1439186788024.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Ari King" > To: undertow-dev at lists.jboss.org > Sent: Saturday, 8 August, 2015 7:53:00 AM > Subject: [undertow-dev] How to Access ServletContext? > > I've embedded Undertow into a Resteasy (JAX-RS) app. One of the libraries I'm > using requires a servlet context attribute to be set. How can/should I go > about doing so? > > If I should use a ServletExtension, to clarify, I need to create a file named > " io.undertow.servlet.ServletExtension" and put it in the > "META-INF/services/ " directory? > > Within the above mentioned file do I need to provide the fully qualified name > of the implementation class? Yes, although there are some other options: - You can use io.undertow.servlet.api.DeploymentInfo#addServletExtension to create the extension yourself - You can also use a ServletContainerInitializer or ServletContextListener instead of a ServletExtension - In your embedding code you can call DeploymentManager.getDeployment().getServletContext() Stuart > > Thanks. > > Best, > Ari > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Mon Aug 10 02:09:30 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 10 Aug 2015 02:09:30 -0400 (EDT) Subject: [undertow-dev] Combining encoding handlers with non-encoding handlers In-Reply-To: References: Message-ID: <1285513045.9229880.1439186970022.JavaMail.zimbra@redhat.com> Just add the encoding handler to the appropriate prefix path, instead of making it the root handler, e.g. .addPrefixPath("/pathA", new EncodingHandler ....) Stuart ----- Original Message ----- > From: "Girish Sharma" > To: undertow-dev at lists.jboss.org > Sent: Friday, 7 August, 2015 12:40:10 AM > Subject: [undertow-dev] Combining encoding handlers with non-encoding handlers > > Hi team, > > I am trying to have a situation like this: > > Path A - response is gzipped, > Path B - response is not gzipped. > > But from extensive searching, I could only figure out a way to make all paths > as gzipped response. > > For example: > > Undertow . builder ().addHttpListener(8080, "localhost").setHandler( new > EncodingHandler( new ContentEncodingRepository().addEncodingHandler( > "gzip" , > new GzipEncodingProvider(), > 50 , > Predicates. parse ( "max-content-size[5]" ) > ) > ).setNext(Handlers. path () > .addPrefixPath("/pathA", pathA ::handle) > .addPrefixPath("/pathB", pathAB::handle > )).build(); > > will make both Path A and Path B as gzip encoded response. > > Any way to make only 1 of them give gzipped response? > > Regards > -- > Girish Sharma > B.Tech(H), Civil Engineering , > Indian Institute of Technology, Kharagpur > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Mon Aug 10 02:11:02 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 10 Aug 2015 02:11:02 -0400 (EDT) Subject: [undertow-dev] Changing proxy response In-Reply-To: <9705223.10163.1431170628777.JavaMail.webmail@bluewin.ch> References: <9705223.10163.1431170628777.JavaMail.webmail@bluewin.ch> Message-ID: <1050358738.9230518.1439187062794.JavaMail.zimbra@redhat.com> Are you talking about changing the response body or just the headers? Stuart ----- Original Message ----- > From: "ralf battenfeld" > To: undertow-dev at lists.jboss.org > Sent: Saturday, 9 May, 2015 9:23:48 PM > Subject: [undertow-dev] Changing proxy response > > Hi > > I am looking for a way to use the LoadBalancingProxyClient that changes the > response received from the backend server. I came up with configuring a > ResponseCommitListener. Is this the correct way of manipulating the response > within the beforeCommit() call? > > If yes, how can I change the response with the given HttpServerExchange > instance? If not, what would be the best way to achieve this? > > Thanks a lot for any help. > Ralf > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Mon Aug 10 02:18:54 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 10 Aug 2015 02:18:54 -0400 (EDT) Subject: [undertow-dev] ServerSentEventConnection In-Reply-To: References: Message-ID: <1541998859.9232490.1439187534886.JavaMail.zimbra@redhat.com> I have added this to the 1.3 branch. Stuart ----- Original Message ----- > From: "Fabian Mager" > To: undertow-dev at lists.jboss.org > Sent: Tuesday, 28 July, 2015 1:48:39 AM > Subject: [undertow-dev] ServerSentEventConnection > > Hi all, > > is there a way to access the queryParameters of an HttpServerExchange > object via a ServerSentEventConnection object? As far as I can see, > there is only access to certain members of the exchange object. In > case it is not possible, would it be problematic in some ways to > implement it? > > Thanks in advance, > Fabian > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From peter.royal at pobox.com Mon Aug 10 14:31:52 2015 From: peter.royal at pobox.com (peter royal) Date: Mon, 10 Aug 2015 13:31:52 -0500 Subject: [undertow-dev] websocket per-message compression & design q Message-ID: <4d9d65f663d29667573b0077b731e7c8@pobox.com> Hi! I'm trying to debug the problems I've encountered after enabling per-message compression on websockets in 1.2, https://issues.jboss.org/browse/UNDERTOW-508 One thing I've noticed is that there's an entirely different code path used inside of WebSocket07FrameSinkChannel whenever extensions are enabled. I was trying to think of how to refactor how extensions are applied so that it would be a path that is always-on, and thus hopefully subject to more scrutiny and use. Conceptually, extensions are transformations to the ByteBuffer that makes up a message payload. I think the internals might be a bit clearer if they were treated as that, and then always applied. (the ExtensionByteBuffer class is something I'd want to eliminate). From an internal API point of view, calls to write on a websocket are mostly made via the WebSockets class, and then a couple of places that use the StreamSinkFrameChannel (SSFC) over a longer period of time for partial messages and streams in the WS JSR implementation. For sending, the GatheringByteChannel APIs are used to represent writing a message. A collection of writes to a single SSFC will result in 1..n WS message fragments depending on how large the buffers returned from the allocator are. When using extensions, there are a bunch of ergonomics regarding the return value from write and remaining bytes in the provided buffers to enable For the WebSockets send methods, all the data to send is already in memory, and the methods just spin or wait over the SSFC writing fragments until all the data is sent. Then there are the blocking APIs in the JSR that send a single fragment and wait for it to be flushed. I think it might be cleaner to push some of that responsibility from the WebSockets utility class into the WebSocket07FrameSinkChannel. For the non-blocking cases, that'd be merging the following two lines from WebSockets into a single call, StreamSinkFrameChannel channel = wsChannel.send(type, totalData); WebSockets.sendData(data, wsChannel, callback, channel, null, timeoutmillis); The channel can then apply the extensions to data and do the appropriate thing. Similar changes would happen to the blocking methods. I realize this is a bit ramble-y, but I wanted to at least get some of my thoughts out there. I'm eager to get WS extensions working fully, and thought that re-architecting how the sending of WS messages happen might make the code less brittle and easier to maintain -pete -- (peter.royal|osi)@pobox.com - http://fotap.org/~osi From scrapmachines at gmail.com Mon Aug 10 03:49:14 2015 From: scrapmachines at gmail.com (Girish Sharma) Date: Mon, 10 Aug 2015 13:19:14 +0530 Subject: [undertow-dev] Combining encoding handlers with non-encoding handlers In-Reply-To: <1285513045.9229880.1439186970022.JavaMail.zimbra@redhat.com> References: <1285513045.9229880.1439186970022.JavaMail.zimbra@redhat.com> Message-ID: Thanks Stuart, it works like that. Seems a bit obvious now that I think of it :) Regards On Mon, Aug 10, 2015 at 11:39 AM, Stuart Douglas wrote: > Just add the encoding handler to the appropriate prefix path, instead of > making it the root handler, e.g. > > .addPrefixPath("/pathA", new EncodingHandler ....) > > Stuart > > ----- Original Message ----- > > From: "Girish Sharma" > > To: undertow-dev at lists.jboss.org > > Sent: Friday, 7 August, 2015 12:40:10 AM > > Subject: [undertow-dev] Combining encoding handlers with non-encoding > handlers > > > > Hi team, > > > > I am trying to have a situation like this: > > > > Path A - response is gzipped, > > Path B - response is not gzipped. > > > > But from extensive searching, I could only figure out a way to make all > paths > > as gzipped response. > > > > For example: > > > > Undertow . builder ().addHttpListener(8080, "localhost").setHandler( new > > EncodingHandler( new ContentEncodingRepository().addEncodingHandler( > > "gzip" , > > new GzipEncodingProvider(), > > 50 , > > Predicates. parse ( "max-content-size[5]" ) > > ) > > ).setNext(Handlers. path () > > .addPrefixPath("/pathA", pathA ::handle) > > .addPrefixPath("/pathB", pathAB::handle > > )).build(); > > > > will make both Path A and Path B as gzip encoded response. > > > > Any way to make only 1 of them give gzipped response? > > > > Regards > > -- > > Girish Sharma > > B.Tech(H), Civil Engineering , > > Indian Institute of Technology, Kharagpur > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > -- Girish Sharma B.Tech(H), Civil Engineering, Indian Institute of Technology, Kharagpur -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150810/49d23221/attachment.html From melghaouat at gmail.com Tue Aug 11 05:42:28 2015 From: melghaouat at gmail.com (Mohammed ElGhaouat) Date: Tue, 11 Aug 2015 11:42:28 +0200 Subject: [undertow-dev] Resizing undertow thread pool size dynamically Message-ID: Hi, I would like to know if there is a way to make undertow reducing the size of the thread pool when the server is less loaded. Is there any parameter(or other way) that make an idle thread die after some inactivity time ? Thanks. Mohammed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150811/eb6b3033/attachment.html From jason.greene at redhat.com Tue Aug 11 15:50:33 2015 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 11 Aug 2015 14:50:33 -0500 Subject: [undertow-dev] Resizing undertow thread pool size dynamically In-Reply-To: References: Message-ID: > On Aug 11, 2015, at 4:42 AM, Mohammed ElGhaouat wrote: > > > Hi, > > I would like to know if there is a way to make undertow reducing the size of the thread pool when the server is less loaded. Is there any parameter(or other way) that make an idle thread die after some inactivity time ? Are you referring to the worker pool or the I/O pool? The I/O pool is special and is fixed. The worker pool currently uses a JDK ThreadPoolExecutor with an unbounded queue which is a behavior pattern typically desired for web servers. That?s not pluggable at the moment, but it could be possible. If you are using the HttpHandler APIs, there is a method on HttpServerDispatch that allows you to use your own custom executor for blocking tasks (which would allow you to tune the default worker task pool very small). If you are using servlet APIs though that uses the standard pools we provide. Is there a particular reason you want to kill idle threads? Threads are cheap unless you are storing massive amounts of thread local data. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From ari.brandeis.king at gmail.com Tue Aug 11 20:08:34 2015 From: ari.brandeis.king at gmail.com (Ari King) Date: Wed, 12 Aug 2015 01:08:34 +0100 Subject: [undertow-dev] How to Access ServletContext? In-Reply-To: <96533099.9229567.1439186788024.JavaMail.zimbra@redhat.com> References: <96533099.9229567.1439186788024.JavaMail.zimbra@redhat.com> Message-ID: Hi Stuart, Thanks for the clarification. As a follow-up, does undertow handle/expose servlets like conventional containers (tomcat, jetty, etc)? I ask, because injecting a HttpServletRequest via a context annotation in a resource method causes the following error: org.jboss.resteasy.spi.LoggableFailure: Unable to find contextual data of type: javax.servlet.http.HttpServletRequest -Ari On Mon, Aug 10, 2015 at 7:06 AM, Stuart Douglas wrote: > > > ----- Original Message ----- > > From: "Ari King" > > To: undertow-dev at lists.jboss.org > > Sent: Saturday, 8 August, 2015 7:53:00 AM > > Subject: [undertow-dev] How to Access ServletContext? > > > > I've embedded Undertow into a Resteasy (JAX-RS) app. One of the > libraries I'm > > using requires a servlet context attribute to be set. How can/should I go > > about doing so? > > > > If I should use a ServletExtension, to clarify, I need to create a file > named > > " io.undertow.servlet.ServletExtension" and put it in the > > "META-INF/services/ " directory? > > > > Within the above mentioned file do I need to provide the fully qualified > name > > of the implementation class? > > Yes, although there are some other options: > > - You can use io.undertow.servlet.api.DeploymentInfo#addServletExtension > to create the extension yourself > - You can also use a ServletContainerInitializer or ServletContextListener > instead of a ServletExtension > - In your embedding code you can call > DeploymentManager.getDeployment().getServletContext() > > Stuart > > > > > > Thanks. > > > > Best, > > Ari > > > > _______________________________________________ > > 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/20150812/75b76804/attachment-0001.html From sdouglas at redhat.com Tue Aug 11 20:18:20 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 11 Aug 2015 20:18:20 -0400 (EDT) Subject: [undertow-dev] How to Access ServletContext? In-Reply-To: References: <96533099.9229567.1439186788024.JavaMail.zimbra@redhat.com> Message-ID: <1749877794.211496.1439338700571.JavaMail.zimbra@redhat.com> Undertow does not do discovery or metadata/annotation parsing. This is expected to be handled by the embedding container (so the embedding container has complete control over what is deployed). How are you setting up Resteasy? Stuart ----- Original Message ----- > From: "Ari King" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Wednesday, 12 August, 2015 10:08:34 AM > Subject: Re: [undertow-dev] How to Access ServletContext? > > Hi Stuart, > > Thanks for the clarification. As a follow-up, does undertow handle/expose > servlets like conventional containers (tomcat, jetty, etc)? I ask, because > injecting a HttpServletRequest via a context annotation in a resource > method causes the following error: > > org.jboss.resteasy.spi.LoggableFailure: Unable to find contextual data of > type: javax.servlet.http.HttpServletRequest > > -Ari > > On Mon, Aug 10, 2015 at 7:06 AM, Stuart Douglas wrote: > > > > > > > ----- Original Message ----- > > > From: "Ari King" > > > To: undertow-dev at lists.jboss.org > > > Sent: Saturday, 8 August, 2015 7:53:00 AM > > > Subject: [undertow-dev] How to Access ServletContext? > > > > > > I've embedded Undertow into a Resteasy (JAX-RS) app. One of the > > libraries I'm > > > using requires a servlet context attribute to be set. How can/should I go > > > about doing so? > > > > > > If I should use a ServletExtension, to clarify, I need to create a file > > named > > > " io.undertow.servlet.ServletExtension" and put it in the > > > "META-INF/services/ " directory? > > > > > > Within the above mentioned file do I need to provide the fully qualified > > name > > > of the implementation class? > > > > Yes, although there are some other options: > > > > - You can use io.undertow.servlet.api.DeploymentInfo#addServletExtension > > to create the extension yourself > > - You can also use a ServletContainerInitializer or ServletContextListener > > instead of a ServletExtension > > - In your embedding code you can call > > DeploymentManager.getDeployment().getServletContext() > > > > Stuart > > > > > > > > > > Thanks. > > > > > > Best, > > > Ari > > > > > > _______________________________________________ > > > undertow-dev mailing list > > > undertow-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > From sdouglas at redhat.com Wed Aug 12 00:51:58 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 12 Aug 2015 00:51:58 -0400 (EDT) Subject: [undertow-dev] websocket per-message compression & design q In-Reply-To: <4d9d65f663d29667573b0077b731e7c8@pobox.com> References: <4d9d65f663d29667573b0077b731e7c8@pobox.com> Message-ID: <1052143164.267700.1439355118620.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "peter royal" > To: undertow-dev at lists.jboss.org > Sent: Tuesday, 11 August, 2015 4:31:52 AM > Subject: [undertow-dev] websocket per-message compression & design q > > Hi! > > I'm trying to debug the problems I've encountered after enabling > per-message compression on websockets in 1.2, > https://issues.jboss.org/browse/UNDERTOW-508 > > One thing I've noticed is that there's an entirely different code path > used inside of WebSocket07FrameSinkChannel whenever extensions are > enabled. I was trying to think of how to refactor how extensions are > applied so that it would be a path that is always-on, and thus hopefully > subject to more scrutiny and use. A refactor of this code has been on my TODO list for a while, but I have not got to it. > > Conceptually, extensions are transformations to the ByteBuffer that > makes up a message payload. I think the internals might be a bit clearer > if they were treated as that, and then always applied. (the > ExtensionByteBuffer class is something I'd want to eliminate). Agreed > > From an internal API point of view, calls to write on a websocket are > mostly made via the WebSockets class, and then a couple of places that > use the StreamSinkFrameChannel (SSFC) over a longer period of time for > partial messages and streams in the WS JSR implementation. > > For sending, the GatheringByteChannel APIs are used to represent writing > a message. A collection of writes to a single SSFC will result in 1..n > WS message fragments depending on how large the buffers returned from > the allocator are. When using extensions, there are a bunch of > ergonomics regarding the return value from write and remaining bytes in > the provided buffers to enable > > For the WebSockets send methods, all the data to send is already in > memory, and the methods just spin or wait over the SSFC writing > fragments until all the data is sent. Then there are the blocking APIs > in the JSR that send a single fragment and wait for it to be flushed. > > I think it might be cleaner to push some of that responsibility from the > WebSockets utility class into the WebSocket07FrameSinkChannel. For the > non-blocking cases, that'd be merging the following two lines from > WebSockets into a single call, > > StreamSinkFrameChannel channel = wsChannel.send(type, totalData); > WebSockets.sendData(data, wsChannel, callback, channel, null, > timeoutmillis); Something we have been talking about for a while is the introduction of a different underlying API than the XNIO Channel, probably taking a form similar to send(Pooled buff), where the caller basically just transfers 'ownership' of the buffer to the underlying sender. For websockets this would definitely make the extension implementation much easier. > > The channel can then apply the extensions to data and do the appropriate > thing. Similar changes would happen to the blocking methods. > > I realize this is a bit ramble-y, but I wanted to at least get some of > my thoughts out there. I'm eager to get WS extensions working fully, and > thought that re-architecting how the sending of WS messages happen might > make the code less brittle and easier to maintain I have not looked at this code in a while, I will try and get to your WS bug some time this week. Stuart > > -pete > > > > -- > (peter.royal|osi)@pobox.com - http://fotap.org/~osi > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From melghaouat at gmail.com Wed Aug 12 04:19:11 2015 From: melghaouat at gmail.com (Mohammed ElGhaouat) Date: Wed, 12 Aug 2015 10:19:11 +0200 Subject: [undertow-dev] Resizing undertow thread pool size dynamically In-Reply-To: References: Message-ID: We are using the servlet API and I am referring to worker pool. Simply we don't want keeping bunch of idle threads in the JVM consuming some resources without doing any thing useful. So with the bounded queue executor, when the value of the task-max-threads parameter is reached, the number of threads in the worker pool couldn't be decreased ? Thank you. Mohammed. On Tue, Aug 11, 2015 at 9:50 PM, Jason Greene wrote: > > > On Aug 11, 2015, at 4:42 AM, Mohammed ElGhaouat > wrote: > > > > > > Hi, > > > > I would like to know if there is a way to make undertow reducing the > size of the thread pool when the server is less loaded. Is there any > parameter(or other way) that make an idle thread die after some inactivity > time ? > > > Are you referring to the worker pool or the I/O pool? The I/O pool is > special and is fixed. The worker pool currently uses a JDK > ThreadPoolExecutor with an unbounded queue which is a behavior pattern > typically desired for web servers. That?s not pluggable at the moment, but > it could be possible. > > If you are using the HttpHandler APIs, there is a method on > HttpServerDispatch that allows you to use your own custom executor for > blocking tasks (which would allow you to tune the default worker task pool > very small). If you are using servlet APIs though that uses the standard > pools we provide. > > Is there a particular reason you want to kill idle threads? Threads are > cheap unless you are storing massive amounts of thread local data. > > -- > 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/20150812/805ae7a3/attachment.html From sdouglas at redhat.com Wed Aug 12 04:55:23 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 12 Aug 2015 04:55:23 -0400 (EDT) Subject: [undertow-dev] Resizing undertow thread pool size dynamically In-Reply-To: References: Message-ID: <779237744.346643.1439369723927.JavaMail.zimbra@redhat.com> Are you using Wildfly or embedded Undertow? If it is the later you can just use io.undertow.servlet.api.DeploymentInfo#setExecutor to use whatever executor implementation you want. The reason why most executors don't reduce the number is because there is generally very little point, a parked thread is generally very cheap, while creating new threads is relatively expensive. Stuart ----- Original Message ----- > From: "Mohammed ElGhaouat" > To: "Jason Greene" > Cc: undertow-dev at lists.jboss.org > Sent: Wednesday, 12 August, 2015 6:19:11 PM > Subject: Re: [undertow-dev] Resizing undertow thread pool size dynamically > > We are using the servlet API and I am referring to worker pool. Simply we > don't want keeping bunch of idle threads in the JVM consuming some resources > without doing any thing useful. > > So with the bounded queue executor, when the value of the task-max-threads > parameter is reached, the number of threads in the worker pool couldn't be > decreased ? > > Thank you. > > > Mohammed. > > On Tue, Aug 11, 2015 at 9:50 PM, Jason Greene < jason.greene at redhat.com > > wrote: > > > > > On Aug 11, 2015, at 4:42 AM, Mohammed ElGhaouat < melghaouat at gmail.com > > > wrote: > > > > > > Hi, > > > > I would like to know if there is a way to make undertow reducing the size > > of the thread pool when the server is less loaded. Is there any > > parameter(or other way) that make an idle thread die after some inactivity > > time ? > > > Are you referring to the worker pool or the I/O pool? The I/O pool is special > and is fixed. The worker pool currently uses a JDK ThreadPoolExecutor with > an unbounded queue which is a behavior pattern typically desired for web > servers. That?s not pluggable at the moment, but it could be possible. > > If you are using the HttpHandler APIs, there is a method on > HttpServerDispatch that allows you to use your own custom executor for > blocking tasks (which would allow you to tune the default worker task pool > very small). If you are using servlet APIs though that uses the standard > pools we provide. > > Is there a particular reason you want to kill idle threads? Threads are cheap > unless you are storing massive amounts of thread local data. > > -- > 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 From melghaouat at gmail.com Wed Aug 12 05:03:39 2015 From: melghaouat at gmail.com (Mohammed ElGhaouat) Date: Wed, 12 Aug 2015 11:03:39 +0200 Subject: [undertow-dev] Resizing undertow thread pool size dynamically In-Reply-To: <779237744.346643.1439369723927.JavaMail.zimbra@redhat.com> References: <779237744.346643.1439369723927.JavaMail.zimbra@redhat.com> Message-ID: I am using Wildfly. Thanks, Mohammed. On Wed, Aug 12, 2015 at 10:55 AM, Stuart Douglas wrote: > Are you using Wildfly or embedded Undertow? > > If it is the later you can just use > io.undertow.servlet.api.DeploymentInfo#setExecutor to use whatever executor > implementation you want. > > The reason why most executors don't reduce the number is because there is > generally very little point, a parked thread is generally very cheap, while > creating new threads is relatively expensive. > > Stuart > > ----- Original Message ----- > > From: "Mohammed ElGhaouat" > > To: "Jason Greene" > > Cc: undertow-dev at lists.jboss.org > > Sent: Wednesday, 12 August, 2015 6:19:11 PM > > Subject: Re: [undertow-dev] Resizing undertow thread pool size > dynamically > > > > We are using the servlet API and I am referring to worker pool. Simply we > > don't want keeping bunch of idle threads in the JVM consuming some > resources > > without doing any thing useful. > > > > So with the bounded queue executor, when the value of the > task-max-threads > > parameter is reached, the number of threads in the worker pool couldn't > be > > decreased ? > > > > Thank you. > > > > > > Mohammed. > > > > On Tue, Aug 11, 2015 at 9:50 PM, Jason Greene < jason.greene at redhat.com > > > > wrote: > > > > > > > > > On Aug 11, 2015, at 4:42 AM, Mohammed ElGhaouat < melghaouat at gmail.com > > > > > wrote: > > > > > > > > > Hi, > > > > > > I would like to know if there is a way to make undertow reducing the > size > > > of the thread pool when the server is less loaded. Is there any > > > parameter(or other way) that make an idle thread die after some > inactivity > > > time ? > > > > > > Are you referring to the worker pool or the I/O pool? The I/O pool is > special > > and is fixed. The worker pool currently uses a JDK ThreadPoolExecutor > with > > an unbounded queue which is a behavior pattern typically desired for web > > servers. That?s not pluggable at the moment, but it could be possible. > > > > If you are using the HttpHandler APIs, there is a method on > > HttpServerDispatch that allows you to use your own custom executor for > > blocking tasks (which would allow you to tune the default worker task > pool > > very small). If you are using servlet APIs though that uses the standard > > pools we provide. > > > > Is there a particular reason you want to kill idle threads? Threads are > cheap > > unless you are storing massive amounts of thread local data. > > > > -- > > Jason T. Greene > > WildFly Lead / JBoss EAP Platform Architect > > JBoss, a division of Red Hat > > > > > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150812/51f45c08/attachment-0001.html From ari.brandeis.king at gmail.com Wed Aug 12 18:09:10 2015 From: ari.brandeis.king at gmail.com (Ari King) Date: Wed, 12 Aug 2015 23:09:10 +0100 Subject: [undertow-dev] How to Access ServletContext? In-Reply-To: <1749877794.211496.1439338700571.JavaMail.zimbra@redhat.com> References: <96533099.9229567.1439186788024.JavaMail.zimbra@redhat.com> <1749877794.211496.1439338700571.JavaMail.zimbra@redhat.com> Message-ID: A synopsis of how I'm setting up Resteasy follows, but for convenience/reference I posted the entire relevant code here: http://pastebin.com/JYMP22h2 I'm setting up Resteasy by leveraging org.jboss.resteasy.spi.ResteasyDeployment and org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher. Essentially, I create a new instance of "ResteasyDeployment" and set an "Application" class for the deployment. ResteasyDeployment deployment = new ResteasyDeployment(); deployment.setApplicationClass(appClass.getName()); Then I configure the servlet: ServletInfo servletInfo = Servlets.servlet("ResteasyServlet", HttpServlet30Dispatcher.class) .setAsyncSupported(true) .setLoadOnStartup(1) .addMapping(appPath); I create a new DeploymentInfo instance and set a few properties: new DeploymentInfo().setClassLoader(Server.class.getClassLoader()) .setContextPath("/") .addServletContextAttribute(ResteasyDeployment.class.getName(), deployment) .addServlet(servletInfo) .setDeploymentName("api.example") .addListeners(Servlets.listener(GuiceContextListener.class)); Then I add the deployment info to a container instance: private final ServletContainer container = ServletContainer.Factory.newInstance(); DeploymentManager manager = container.addDeployment(deployInfo); manager.deploy(); Lastly, I set the undertow handlers, build, and start: undertow = builder.setHandler(root).build(); undertow.start(); Thanks. -Ari On Wed, Aug 12, 2015 at 1:18 AM, Stuart Douglas wrote: > Undertow does not do discovery or metadata/annotation parsing. This is > expected to be handled by the embedding container (so the embedding > container has complete control over what is deployed). > > How are you setting up Resteasy? > > Stuart > > ----- Original Message ----- > > From: "Ari King" > > To: "Stuart Douglas" > > Cc: undertow-dev at lists.jboss.org > > Sent: Wednesday, 12 August, 2015 10:08:34 AM > > Subject: Re: [undertow-dev] How to Access ServletContext? > > > > Hi Stuart, > > > > Thanks for the clarification. As a follow-up, does undertow handle/expose > > servlets like conventional containers (tomcat, jetty, etc)? I ask, > because > > injecting a HttpServletRequest via a context annotation in a resource > > method causes the following error: > > > > org.jboss.resteasy.spi.LoggableFailure: Unable to find contextual data of > > type: javax.servlet.http.HttpServletRequest > > > > -Ari > > > > On Mon, Aug 10, 2015 at 7:06 AM, Stuart Douglas > wrote: > > > > > > > > > > > ----- Original Message ----- > > > > From: "Ari King" > > > > To: undertow-dev at lists.jboss.org > > > > Sent: Saturday, 8 August, 2015 7:53:00 AM > > > > Subject: [undertow-dev] How to Access ServletContext? > > > > > > > > I've embedded Undertow into a Resteasy (JAX-RS) app. One of the > > > libraries I'm > > > > using requires a servlet context attribute to be set. How can/should > I go > > > > about doing so? > > > > > > > > If I should use a ServletExtension, to clarify, I need to create a > file > > > named > > > > " io.undertow.servlet.ServletExtension" and put it in the > > > > "META-INF/services/ " directory? > > > > > > > > Within the above mentioned file do I need to provide the fully > qualified > > > name > > > > of the implementation class? > > > > > > Yes, although there are some other options: > > > > > > - You can use > io.undertow.servlet.api.DeploymentInfo#addServletExtension > > > to create the extension yourself > > > - You can also use a ServletContainerInitializer or > ServletContextListener > > > instead of a ServletExtension > > > - In your embedding code you can call > > > DeploymentManager.getDeployment().getServletContext() > > > > > > Stuart > > > > > > > > > > > > > > Thanks. > > > > > > > > Best, > > > > Ari > > > > > > > > _______________________________________________ > > > > 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/20150812/5b54019b/attachment.html From sdouglas at redhat.com Wed Aug 12 19:48:38 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 12 Aug 2015 19:48:38 -0400 (EDT) Subject: [undertow-dev] How to Access ServletContext? In-Reply-To: References: <96533099.9229567.1439186788024.JavaMail.zimbra@redhat.com> <1749877794.211496.1439338700571.JavaMail.zimbra@redhat.com> Message-ID: <1152284509.773148.1439423318598.JavaMail.zimbra@redhat.com> What does your full exception stack trace look like? as far as I can tell your current setup should be all that is required. Stuart ----- Original Message ----- > From: "Ari King" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Thursday, 13 August, 2015 8:09:10 AM > Subject: Re: [undertow-dev] How to Access ServletContext? > > A synopsis of how I'm setting up Resteasy follows, but for > convenience/reference I posted the entire relevant code here: > http://pastebin.com/JYMP22h2 > > I'm setting up Resteasy by leveraging > org.jboss.resteasy.spi.ResteasyDeployment and > org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher. > > Essentially, I create a new instance of "ResteasyDeployment" and set an > "Application" class for the deployment. > > ResteasyDeployment deployment = new ResteasyDeployment(); > deployment.setApplicationClass(appClass.getName()); > > Then I configure the servlet: > > ServletInfo servletInfo = Servlets.servlet("ResteasyServlet", > HttpServlet30Dispatcher.class) > .setAsyncSupported(true) > .setLoadOnStartup(1) > .addMapping(appPath); > > I create a new DeploymentInfo instance and set a few properties: > > new DeploymentInfo().setClassLoader(Server.class.getClassLoader()) > .setContextPath("/") > > .addServletContextAttribute(ResteasyDeployment.class.getName(), deployment) > .addServlet(servletInfo) > .setDeploymentName("api.example") > > .addListeners(Servlets.listener(GuiceContextListener.class)); > > Then I add the deployment info to a container instance: > > private final ServletContainer container = > ServletContainer.Factory.newInstance(); > DeploymentManager manager = container.addDeployment(deployInfo); > manager.deploy(); > > Lastly, I set the undertow handlers, build, and start: > > undertow = builder.setHandler(root).build(); > undertow.start(); > > Thanks. > > -Ari > > On Wed, Aug 12, 2015 at 1:18 AM, Stuart Douglas wrote: > > > Undertow does not do discovery or metadata/annotation parsing. This is > > expected to be handled by the embedding container (so the embedding > > container has complete control over what is deployed). > > > > How are you setting up Resteasy? > > > > Stuart > > > > ----- Original Message ----- > > > From: "Ari King" > > > To: "Stuart Douglas" > > > Cc: undertow-dev at lists.jboss.org > > > Sent: Wednesday, 12 August, 2015 10:08:34 AM > > > Subject: Re: [undertow-dev] How to Access ServletContext? > > > > > > Hi Stuart, > > > > > > Thanks for the clarification. As a follow-up, does undertow handle/expose > > > servlets like conventional containers (tomcat, jetty, etc)? I ask, > > because > > > injecting a HttpServletRequest via a context annotation in a resource > > > method causes the following error: > > > > > > org.jboss.resteasy.spi.LoggableFailure: Unable to find contextual data of > > > type: javax.servlet.http.HttpServletRequest > > > > > > -Ari > > > > > > On Mon, Aug 10, 2015 at 7:06 AM, Stuart Douglas > > wrote: > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Ari King" > > > > > To: undertow-dev at lists.jboss.org > > > > > Sent: Saturday, 8 August, 2015 7:53:00 AM > > > > > Subject: [undertow-dev] How to Access ServletContext? > > > > > > > > > > I've embedded Undertow into a Resteasy (JAX-RS) app. One of the > > > > libraries I'm > > > > > using requires a servlet context attribute to be set. How can/should > > I go > > > > > about doing so? > > > > > > > > > > If I should use a ServletExtension, to clarify, I need to create a > > file > > > > named > > > > > " io.undertow.servlet.ServletExtension" and put it in the > > > > > "META-INF/services/ " directory? > > > > > > > > > > Within the above mentioned file do I need to provide the fully > > qualified > > > > name > > > > > of the implementation class? > > > > > > > > Yes, although there are some other options: > > > > > > > > - You can use > > io.undertow.servlet.api.DeploymentInfo#addServletExtension > > > > to create the extension yourself > > > > - You can also use a ServletContainerInitializer or > > ServletContextListener > > > > instead of a ServletExtension > > > > - In your embedding code you can call > > > > DeploymentManager.getDeployment().getServletContext() > > > > > > > > Stuart > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > Best, > > > > > Ari > > > > > > > > > > _______________________________________________ > > > > > undertow-dev mailing list > > > > > undertow-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > > > > > > > From peter.royal at pobox.com Thu Aug 13 09:53:11 2015 From: peter.royal at pobox.com (peter royal) Date: Thu, 13 Aug 2015 08:53:11 -0500 Subject: [undertow-dev] websocket per-message compression & design q In-Reply-To: <1052143164.267700.1439355118620.JavaMail.zimbra@redhat.com> References: <4d9d65f663d29667573b0077b731e7c8@pobox.com> <1052143164.267700.1439355118620.JavaMail.zimbra@redhat.com> Message-ID: On 2015-08-11 23:51, Stuart Douglas wrote: > Something we have been talking about for a while is the introduction of > a > different underlying API than the XNIO Channel, probably taking a form > similar to send(Pooled buff), where the caller basically > just > transfers 'ownership' of the buffer to the underlying sender. > > For websockets this would definitely make the extension implementation > much > easier. I have free cycles, so I'll play around with hacking at this. I'll try and make a send(Pooled) the primary work function for a AbstractFramedStreakSinkChannel. The existing 'long write(...)' methods will just delegate to the new function, and hopefully it will fall out such that everything works :) -pete -- (peter.royal|osi)@pobox.com - http://fotap.org/~osi From arjan.tijms at gmail.com Mon Aug 17 08:03:50 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 17 Aug 2015 14:03:50 +0200 Subject: [undertow-dev] 1.2.9.Final tag missing in git repo Message-ID: Hi, I'm trying to build WildFly 9.0.1.Final from source. WildFly 9.0.1.Final seems to depend on WildFly core 1.0.1.Final, which on its turn depends on Undertow 1.2.9.Final. However, there's no tag 1.2.9.Final at https://github.com/undertow-io/undertow I see a 1.2.8.Final and a 1.2.10.Final Am I missing something? Kind regards, Arjan Tijms From sdouglas at redhat.com Mon Aug 17 18:16:39 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 17 Aug 2015 18:16:39 -0400 (EDT) Subject: [undertow-dev] 1.2.9.Final tag missing in git repo In-Reply-To: References: Message-ID: <1669978363.3794584.1439849799491.JavaMail.zimbra@redhat.com> Oops, I have pushed the tag. Stuart ----- Original Message ----- > From: "arjan tijms" > To: "undertow-dev" > Sent: Monday, 17 August, 2015 10:03:50 PM > Subject: [undertow-dev] 1.2.9.Final tag missing in git repo > > Hi, > > I'm trying to build WildFly 9.0.1.Final from source. WildFly > 9.0.1.Final seems to depend on WildFly core 1.0.1.Final, which on its > turn depends on Undertow 1.2.9.Final. > > However, there's no tag 1.2.9.Final at > https://github.com/undertow-io/undertow > > I see a 1.2.8.Final and a 1.2.10.Final > > Am I missing something? > > Kind regards, > Arjan Tijms > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From arjan.tijms at gmail.com Mon Aug 17 18:18:53 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 18 Aug 2015 00:18:53 +0200 Subject: [undertow-dev] 1.2.9.Final tag missing in git repo In-Reply-To: <1669978363.3794584.1439849799491.JavaMail.zimbra@redhat.com> References: <1669978363.3794584.1439849799491.JavaMail.zimbra@redhat.com> Message-ID: Great, thanks! :) On Tue, Aug 18, 2015 at 12:16 AM, Stuart Douglas wrote: > Oops, I have pushed the tag. > > Stuart > > ----- Original Message ----- >> From: "arjan tijms" >> To: "undertow-dev" >> Sent: Monday, 17 August, 2015 10:03:50 PM >> Subject: [undertow-dev] 1.2.9.Final tag missing in git repo >> >> Hi, >> >> I'm trying to build WildFly 9.0.1.Final from source. WildFly >> 9.0.1.Final seems to depend on WildFly core 1.0.1.Final, which on its >> turn depends on Undertow 1.2.9.Final. >> >> However, there's no tag 1.2.9.Final at >> https://github.com/undertow-io/undertow >> >> I see a 1.2.8.Final and a 1.2.10.Final >> >> Am I missing something? >> >> Kind regards, >> Arjan Tijms >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> From reginaldo.rms at gmail.com Fri Aug 21 19:05:22 2015 From: reginaldo.rms at gmail.com (Reginaldo Sousa) Date: Fri, 21 Aug 2015 20:05:22 -0300 Subject: [undertow-dev] It is possible to deploy a JAX-RS application? Message-ID: Hi, I'm working on a JAX-RS application and would like to use the undertow as container. I found only one implementation using RestEasy, but it very degrades performance. I tried to use jersey with servlet container but it still fails. Anyone have any suggestions? *_________________________________________________________ Reginaldo Sousa* - software developer Tw, FB, In: @reginaldosousa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150821/486cd998/attachment.html From vdevigere at gmail.com Fri Aug 21 21:43:19 2015 From: vdevigere at gmail.com (Vidyaranya Devigere) Date: Fri, 21 Aug 2015 18:43:19 -0700 Subject: [undertow-dev] It is possible to deploy a JAX-RS application? In-Reply-To: References: Message-ID: I have a tutorial and source code here https://github.com/vdevigere/undertow-cdi-jaxrs The tutorial uses RestEasy. I use a similar architecture and code for a work related project and we get very good performance. If you can post the issue you are seeing with Jersey we can help you out. On Fri, Aug 21, 2015 at 4:05 PM, Reginaldo Sousa wrote: > Hi, > > I'm working on a JAX-RS application and would like to use the undertow as > container. > I found only one implementation using RestEasy, but it very degrades > performance. > I tried to use jersey with servlet container but it still fails. > > Anyone have any suggestions? > > > *_________________________________________________________ Reginaldo Sousa* > - software developer > Tw, FB, In: @reginaldosousa > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -- Viddu Devigere -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150821/a64bc869/attachment.html From peter.royal at pobox.com Mon Aug 24 15:23:52 2015 From: peter.royal at pobox.com (peter royal) Date: Mon, 24 Aug 2015 14:23:52 -0500 Subject: [undertow-dev] websocket per-message compression & design q In-Reply-To: References: <4d9d65f663d29667573b0077b731e7c8@pobox.com> <1052143164.267700.1439355118620.JavaMail.zimbra@redhat.com> Message-ID: I have done this work and it is available at https://github.com/osi/undertow/commit/6199ea13dce900cf1ef808744aab141bee66380d All the tests and the autobahn fuzz tests pass. However, when I run it with my application using per-message deflate I am still getting some stream corruption I'm looking at. I'll send a PR once it is bug-free. -pete -- (peter.royal|osi)@pobox.com - http://fotap.org/~osi From sdouglas at redhat.com Tue Aug 25 02:28:33 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 25 Aug 2015 02:28:33 -0400 (EDT) Subject: [undertow-dev] websocket per-message compression & design q In-Reply-To: References: <4d9d65f663d29667573b0077b731e7c8@pobox.com> <1052143164.267700.1439355118620.JavaMail.zimbra@redhat.com> Message-ID: <1568769385.8151248.1440484113387.JavaMail.zimbra@redhat.com> I have had a quick look over this and so far I think it looks good. I will do a full review once you have sent in the PR. Stuart ----- Original Message ----- > From: "peter royal" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Tuesday, 25 August, 2015 5:23:52 AM > Subject: Re: [undertow-dev] websocket per-message compression & design q > > I have done this work and it is available at > https://github.com/osi/undertow/commit/6199ea13dce900cf1ef808744aab141bee66380d > > All the tests and the autobahn fuzz tests pass. However, when I run it > with my application using per-message deflate I am still getting some > stream corruption I'm looking at. I'll send a PR once it is bug-free. > > -pete > > -- > (peter.royal|osi)@pobox.com - http://fotap.org/~osi > From peter.royal at pobox.com Tue Aug 25 10:59:13 2015 From: peter.royal at pobox.com (peter royal) Date: Tue, 25 Aug 2015 09:59:13 -0500 Subject: [undertow-dev] websocket per-message compression & design q In-Reply-To: <1568769385.8151248.1440484113387.JavaMail.zimbra@redhat.com> References: <4d9d65f663d29667573b0077b731e7c8@pobox.com> <1052143164.267700.1439355118620.JavaMail.zimbra@redhat.com> <1568769385.8151248.1440484113387.JavaMail.zimbra@redhat.com> Message-ID: <0a64963f77ab31d0a4a495b66576c04f@pobox.com> On 2015-08-25 01:28, Stuart Douglas wrote: > I have had a quick look over this and so far I think it looks good. I > will do a full review once you have sent in the PR. https://github.com/undertow-io/undertow/pull/327 It is working with my application and permessage-deflate enabled. (My app has both a WS client and server present in it). -pete -- (peter.royal|osi)@pobox.com - http://fotap.org/~osi From toby at tcrawley.org Fri Aug 28 14:41:49 2015 From: toby at tcrawley.org (Toby Crawley) Date: Fri, 28 Aug 2015 14:41:49 -0400 Subject: [undertow-dev] Possible session lookup bug when no session cookie present Message-ID: With this commit[1], calls to Sessions.getOrCreateSession() from within a handler where no session cookie was sent with the request result in a new Session being created every time, with the last Session created actually being the one stored when the exchange is completed. This means that the following in a handler results in "foo" not being in the session on the next request: Sessions.getOrCreateSession(exchange).setAttribute("foo", "bar"); Sessions.getOrCreateSession(exchange); Before [1], the second getOrCreateSession() call would return the same Session object as the first call, not overwriting the one already attached to the request, and "foo" would be preserved. I'm not sure if you consider this a bug or not, but wanted to point it out just in case. We discovered this in an Immutant test when upgrading from undertow 1.1.0, and we were able to work around it with a small change to that test. I don't believe this will affect any Immutant users, since we handle all Session access for them, and call getOrCreateSession() only once during regular operation. Let me know if you do consider this a bug, and I'll file a JIRA. - Toby [1]: https://github.com/undertow-io/undertow/commit/a97fec29f379fff6cb5a74ae9a39177a9c36d4ae From sdouglas at redhat.com Fri Aug 28 18:37:37 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 28 Aug 2015 18:37:37 -0400 (EDT) Subject: [undertow-dev] Possible session lookup bug when no session cookie present In-Reply-To: References: Message-ID: <1036716020.10850736.1440801457304.JavaMail.zimbra@redhat.com> This is a bug. Stuart ----- Original Message ----- > From: "Toby Crawley" > To: undertow-dev at lists.jboss.org > Sent: Saturday, 29 August, 2015 4:41:49 AM > Subject: [undertow-dev] Possible session lookup bug when no session cookie present > > With this commit[1], calls to Sessions.getOrCreateSession() from > within a handler where no session cookie was sent with the request > result in a new Session being created every time, with the last > Session created actually being the one stored when the exchange is > completed. > > This means that the following in a handler results in "foo" not being > in the session on the next request: > > Sessions.getOrCreateSession(exchange).setAttribute("foo", "bar"); > Sessions.getOrCreateSession(exchange); > > Before [1], the second getOrCreateSession() call would return the same > Session object as the first call, not overwriting the one already > attached to the request, and "foo" would be preserved. > > I'm not sure if you consider this a bug or not, but wanted to point it > out just in case. We discovered this in an Immutant test when > upgrading from undertow 1.1.0, and we were able to work around it with > a small change to that test. I don't believe this will affect any > Immutant users, since we handle all Session access for them, and call > getOrCreateSession() only once during regular operation. > > Let me know if you do consider this a bug, and I'll file a JIRA. > > - Toby > > [1]: > https://github.com/undertow-io/undertow/commit/a97fec29f379fff6cb5a74ae9a39177a9c36d4ae > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From bitvector2 at gmail.com Sat Aug 29 22:00:49 2015 From: bitvector2 at gmail.com (Steve Logue) Date: Sat, 29 Aug 2015 19:00:49 -0700 Subject: [undertow-dev] Who Needs JAX-RS... Message-ID: Hi Folks, I'm definitely new to Undertow and super impressed with it. However the docs are a bit thin in regards to using the RoutingHandler and doing full async processing. May I ask for a quick check of my approach to using Undertow and trying not to block anywhere: https://github.com/bitvector2/microservice2/blob/master/src/main/java/org/bitvector/microservice2/HttpActor.java -STEVEl -- http://www.bitvector.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150829/c958b60b/attachment-0001.html From peter.royal at pobox.com Mon Aug 31 08:40:24 2015 From: peter.royal at pobox.com (peter royal) Date: Mon, 31 Aug 2015 07:40:24 -0500 Subject: [undertow-dev] Who Needs JAX-RS... In-Reply-To: References: Message-ID: You are blocking the IO thread in each of your handlers. When each handler is a class, you can do: if( exchange.isInIoThread()) { exchange.dispatch(this); return; } but since you are using lambda's, that won't work. In this case, you might want to just pass a Runnable to exchange.dispatch() that will put you on a worker pool thread where it is safe to block on the Await.result call. an alternate (but lacking the timeout option) method I use is to leverage the JDK8 CompletableFuture and use .thenAccept / .exceptionally to return the response when available. -pete On 2015-08-29 21:00, Steve Logue wrote: > Hi Folks, I'm definitely new to Undertow and super impressed with it. However the docs are a bit thin in regards to using the RoutingHandler and doing full async processing. May I ask for a quick check of my approach to using Undertow and trying not to block anywhere: > https://github.com/bitvector2/microservice2/blob/master/src/main/java/org/bitvector/microservice2/HttpActor.java [1] > > -STEVEl > > -- > > http://www.bitvector.org/ [2] > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev [3] -- (peter.royal|osi)@pobox.com - http://fotap.org/~osi [4] Links: ------ [1] https://github.com/bitvector2/microservice2/blob/master/src/main/java/org/bitvector/microservice2/HttpActor.java [2] http://www.bitvector.org/ [3] https://lists.jboss.org/mailman/listinfo/undertow-dev [4] http://fotap.org/~osi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150831/56a13b61/attachment.html From toby at tcrawley.org Mon Aug 31 11:33:29 2015 From: toby at tcrawley.org (Toby Crawley) Date: Mon, 31 Aug 2015 11:33:29 -0400 Subject: [undertow-dev] Possible session lookup bug when no session cookie present In-Reply-To: <1036716020.10850736.1440801457304.JavaMail.zimbra@redhat.com> References: <1036716020.10850736.1440801457304.JavaMail.zimbra@redhat.com> Message-ID: Okay. I filed https://issues.jboss.org/browse/UNDERTOW-528 On Fri, Aug 28, 2015 at 6:37 PM, Stuart Douglas wrote: > This is a bug. > > Stuart > > ----- Original Message ----- >> From: "Toby Crawley" >> To: undertow-dev at lists.jboss.org >> Sent: Saturday, 29 August, 2015 4:41:49 AM >> Subject: [undertow-dev] Possible session lookup bug when no session cookie present >> >> With this commit[1], calls to Sessions.getOrCreateSession() from >> within a handler where no session cookie was sent with the request >> result in a new Session being created every time, with the last >> Session created actually being the one stored when the exchange is >> completed. >> >> This means that the following in a handler results in "foo" not being >> in the session on the next request: >> >> Sessions.getOrCreateSession(exchange).setAttribute("foo", "bar"); >> Sessions.getOrCreateSession(exchange); >> >> Before [1], the second getOrCreateSession() call would return the same >> Session object as the first call, not overwriting the one already >> attached to the request, and "foo" would be preserved. >> >> I'm not sure if you consider this a bug or not, but wanted to point it >> out just in case. We discovered this in an Immutant test when >> upgrading from undertow 1.1.0, and we were able to work around it with >> a small change to that test. I don't believe this will affect any >> Immutant users, since we handle all Session access for them, and call >> getOrCreateSession() only once during regular operation. >> >> Let me know if you do consider this a bug, and I'll file a JIRA. >> >> - Toby >> >> [1]: >> https://github.com/undertow-io/undertow/commit/a97fec29f379fff6cb5a74ae9a39177a9c36d4ae >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> From bitvector2 at gmail.com Mon Aug 31 12:08:16 2015 From: bitvector2 at gmail.com (Steve Logue) Date: Mon, 31 Aug 2015 09:08:16 -0700 Subject: [undertow-dev] Who Needs JAX-RS... In-Reply-To: References: Message-ID: Thanks for looking - how does it look now? This is actually what I had beforehand at some point. Now it uses a lambda statement to dispatch to the handler method on a worker thread. -STEVEl On Mon, Aug 31, 2015 at 5:40 AM, peter royal wrote: > You are blocking the IO thread in each of your handlers. > > > > When each handler is a class, you can do: > > > > if( exchange.isInIoThread()) { > > exchange.dispatch(this); > > return; > > } > > > > but since you are using lambda's, that won't work. In this case, you might > want to just pass a Runnable to exchange.dispatch() > > > > that will put you on a worker pool thread where it is safe to block on the > Await.result call. > > > > an alternate (but lacking the timeout option) method I use is to leverage > the JDK8 CompletableFuture and use .thenAccept / .exceptionally to return > the response when available. > > > > -pete > > > > > > > > > > On 2015-08-29 21:00, Steve Logue wrote: > > Hi Folks, I'm definitely new to Undertow and super impressed with it. > However the docs are a bit thin in regards to using the RoutingHandler and > doing full async processing. May I ask for a quick check of my approach to > using Undertow and trying not to block anywhere: > > > https://github.com/bitvector2/microservice2/blob/master/src/main/java/org/bitvector/microservice2/HttpActor.java > > -STEVEl > > > -- > > http://www.bitvector.org/ > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > -- > (peter.royal|osi)@pobox.com - http://fotap.org/~osi > -- http://www.bitvector.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150831/9eaa01d1/attachment.html From miere.teixeira at gmail.com Mon Aug 31 20:28:06 2015 From: miere.teixeira at gmail.com (Miere Teixeira) Date: Tue, 01 Sep 2015 00:28:06 +0000 Subject: [undertow-dev] Who Needs JAX-RS... In-Reply-To: References: Message-ID: Steve, At my first look, I felt like you were facing the issue that Peter have pointed out. Taking a deeper look into your code, I found out what you have explained on your last email (line 47 of your source code). You are right, it seems that you aren't blocking your IO threads. Just keep in mind that it will always dispatch your request into a Worker thread. By design, HttpHandler could be nested in a chain of handlers, and some built in HttpHandlers will dispatch your request into a Worker thread (as AuthenticationCallHandler, per example). Thus, if you plan to wrap your requests with such handlers all of your requests will be dispatched into Worker threads twice per request. To avoid this, you should apply the fix that Peter have suggested already. Regards, Miere On Mon, Aug 31, 2015 at 1:08 PM Steve Logue wrote: > Thanks for looking - how does it look now? This is actually what I had > beforehand at some point. Now it uses a lambda statement to dispatch to > the handler method on a worker thread. > > -STEVEl > > > On Mon, Aug 31, 2015 at 5:40 AM, peter royal > wrote: > >> You are blocking the IO thread in each of your handlers. >> >> >> >> When each handler is a class, you can do: >> >> >> >> if( exchange.isInIoThread()) { >> >> exchange.dispatch(this); >> >> return; >> >> } >> >> >> >> but since you are using lambda's, that won't work. In this case, you >> might want to just pass a Runnable to exchange.dispatch() >> >> >> >> that will put you on a worker pool thread where it is safe to block on >> the Await.result call. >> >> >> >> an alternate (but lacking the timeout option) method I use is to leverage >> the JDK8 CompletableFuture and use .thenAccept / .exceptionally to return >> the response when available. >> >> >> >> -pete >> >> >> >> >> >> >> >> >> >> On 2015-08-29 21:00, Steve Logue wrote: >> >> Hi Folks, I'm definitely new to Undertow and super impressed with it. >> However the docs are a bit thin in regards to using the RoutingHandler and >> doing full async processing. May I ask for a quick check of my approach to >> using Undertow and trying not to block anywhere: >> >> >> https://github.com/bitvector2/microservice2/blob/master/src/main/java/org/bitvector/microservice2/HttpActor.java >> >> -STEVEl >> >> >> -- >> >> http://www.bitvector.org/ >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> >> -- >> (peter.royal|osi)@pobox.com - http://fotap.org/~osi >> > > > > -- > > http://www.bitvector.org/ > _______________________________________________ > 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/20150901/50f9f15e/attachment.html From sdouglas at redhat.com Mon Aug 31 20:45:38 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 31 Aug 2015 20:45:38 -0400 (EDT) Subject: [undertow-dev] Possible session lookup bug when no session cookie present In-Reply-To: References: <1036716020.10850736.1440801457304.JavaMail.zimbra@redhat.com> Message-ID: <423172232.11623478.1441068338285.JavaMail.zimbra@redhat.com> I have released 1.2.11.Final with this fix. Stuart ----- Original Message ----- > From: "Toby Crawley" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Tuesday, 1 September, 2015 1:33:29 AM > Subject: Re: [undertow-dev] Possible session lookup bug when no session cookie present > > Okay. I filed https://issues.jboss.org/browse/UNDERTOW-528 > > On Fri, Aug 28, 2015 at 6:37 PM, Stuart Douglas wrote: > > This is a bug. > > > > Stuart > > > > ----- Original Message ----- > >> From: "Toby Crawley" > >> To: undertow-dev at lists.jboss.org > >> Sent: Saturday, 29 August, 2015 4:41:49 AM > >> Subject: [undertow-dev] Possible session lookup bug when no session cookie > >> present > >> > >> With this commit[1], calls to Sessions.getOrCreateSession() from > >> within a handler where no session cookie was sent with the request > >> result in a new Session being created every time, with the last > >> Session created actually being the one stored when the exchange is > >> completed. > >> > >> This means that the following in a handler results in "foo" not being > >> in the session on the next request: > >> > >> Sessions.getOrCreateSession(exchange).setAttribute("foo", "bar"); > >> Sessions.getOrCreateSession(exchange); > >> > >> Before [1], the second getOrCreateSession() call would return the same > >> Session object as the first call, not overwriting the one already > >> attached to the request, and "foo" would be preserved. > >> > >> I'm not sure if you consider this a bug or not, but wanted to point it > >> out just in case. We discovered this in an Immutant test when > >> upgrading from undertow 1.1.0, and we were able to work around it with > >> a small change to that test. I don't believe this will affect any > >> Immutant users, since we handle all Session access for them, and call > >> getOrCreateSession() only once during regular operation. > >> > >> Let me know if you do consider this a bug, and I'll file a JIRA. > >> > >> - Toby > >> > >> [1]: > >> https://github.com/undertow-io/undertow/commit/a97fec29f379fff6cb5a74ae9a39177a9c36d4ae > >> _______________________________________________ > >> undertow-dev mailing list > >> undertow-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/undertow-dev > >> > From kakonyi.istvan at alerant.hu Mon Aug 31 03:43:02 2015 From: kakonyi.istvan at alerant.hu (=?iso-8859-2?Q?K=E1konyi_Istv=E1n?=) Date: Mon, 31 Aug 2015 07:43:02 +0000 Subject: [undertow-dev] Extending io.undertow.servlet.spec.HttpSessionImpl Message-ID: Hi Team! I am involved in a github project that try to implement a SIP Application Server under wildfy 8 (check https://github.com/Mobicents/sip-servlets/issues/3 for more detail). According to SIP Servlet spec we have to implement a ConvergedHttpSession class that provides access to HttpSession related functionality which is only present in a converged HTTP/SIP container. In a converged container, an instance of HttpSession can be cast to ConvergedHttpSession in order to access methods available only to converged applications. Wildfly 8 uses undertow-servlet project for session handling and I noticed that currently it is not possible to extend io.undertow.servlet.spec.HttpSessionImpl (it has only a private constructor method and a static method for instantiation), so we are stuck in the implementation a little bit because of that limitation. Do you have any suggestion how to resolve this problem? Is there a chance to change HttpSessionImpl's constructor to "protected" in order to be able to extend it? Best Regards, Istvan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150831/9ed2eac7/attachment.html From sdouglas at redhat.com Mon Aug 31 21:20:41 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 31 Aug 2015 21:20:41 -0400 (EDT) Subject: [undertow-dev] Who Needs JAX-RS... In-Reply-To: References: Message-ID: <176268384.11631736.1441070441871.JavaMail.zimbra@redhat.com> This is not really correct, as you are setting the exchange into blocking mode and reading from an input stream. If you want to go full async there are a few things you need to remove the 'startBlocking()' call. To read the request entity the easiest way before Undertow 1.3 (which is still not quite final) is to use io.undertow.util.StringReadChannelListener. If you are a recent 1.3.0 beta you can use the new HttpServerExchange.getRequestReceiver() API. Here is an example of a handler that uses StringReadChannelListener to simply attach the post data to the exchange: https://github.com/undertow-io/undertow.js/blob/master/src/main/java/io/undertow/js/StringReadHandler.java You can then get it in the next handler using the StringReadHandler.DATA attachment key. Stuart ----- Original Message ----- > From: "Steve Logue" > To: undertow-dev at lists.jboss.org > Sent: Sunday, 30 August, 2015 12:00:49 PM > Subject: [undertow-dev] Who Needs JAX-RS... > > Hi Folks, I'm definitely new to Undertow and super impressed with it. However > the docs are a bit thin in regards to using the RoutingHandler and doing > full async processing. May I ask for a quick check of my approach to using > Undertow and trying not to block anywhere: > > https://github.com/bitvector2/microservice2/blob/master/src/main/java/org/bitvector/microservice2/HttpActor.java > > -STEVEl > > > -- > > http://www.bitvector.org/ > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Mon Aug 31 21:22:48 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 31 Aug 2015 21:22:48 -0400 (EDT) Subject: [undertow-dev] Extending io.undertow.servlet.spec.HttpSessionImpl In-Reply-To: References: Message-ID: <1005909629.11632003.1441070568048.JavaMail.zimbra@redhat.com> What exactly is a ConvergedHttpSession ? HttpSessionImpl is not really designed to be extended, the underlying functionality is provided by the Undertow SessionManager which can be extended. One possibility would be to just create a HttpServletRequest wrapper than returns a delegate than implements ConvergedHttpSession. Would this meet your requirements? Stuart ----- Original Message ----- > From: "K?konyi Istv?n" > To: undertow-dev at lists.jboss.org > Sent: Monday, 31 August, 2015 5:43:02 PM > Subject: [undertow-dev] Extending io.undertow.servlet.spec.HttpSessionImpl > > > > Hi Team! > > > > I am involved in a github project that try to implement a SIP Application > Server under wildfy 8 (check > https://github.com/Mobicents/sip-servlets/issues/3 for more detail). > > > > According to SIP Servlet spec we have to implement a ConvergedHttpSession > class that provides access to HttpSession related functionality which is > only present in a converged HTTP/SIP container. In a converged container, an > instance of HttpSession can be cast to ConvergedHttpSession in order to > access methods available only to converged applications. > > > > Wildfly 8 uses undertow-servlet project for session handling and I noticed > that currently it is not possible to extend > io.undertow.servlet.spec.HttpSessionImpl (it has only a private constructor > method and a static method for instantiation), so we are stuck in the > implementation a little bit because of that limitation. > > > > Do you have any suggestion how to resolve this problem? Is there a chance to > change HttpSessionImpl?s constructor to ?protected? in order to be able to > extend it? > > > > Best Regards, > > Istvan > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From miere.teixeira at gmail.com Mon Aug 31 22:51:00 2015 From: miere.teixeira at gmail.com (Miere Teixeira) Date: Tue, 01 Sep 2015 02:51:00 +0000 Subject: [undertow-dev] Who Needs JAX-RS... In-Reply-To: <176268384.11631736.1441070441871.JavaMail.zimbra@redhat.com> References: <176268384.11631736.1441070441871.JavaMail.zimbra@redhat.com> Message-ID: Btw, Stuart, Quite interesting this new non-blocking API that was introduced in the 1.3.0 version. Can you tell me where is a good place to be notified about the 1.3.0's roadmap and the upcoming new features? On Mon, Aug 31, 2015 at 10:21 PM Stuart Douglas wrote: > This is not really correct, as you are setting the exchange into blocking > mode and reading from an input stream. > > If you want to go full async there are a few things you need to remove the > 'startBlocking()' call. To read the request entity the easiest way before > Undertow 1.3 (which is still not quite final) is to use > io.undertow.util.StringReadChannelListener. If you are a recent 1.3.0 beta > you can use the new HttpServerExchange.getRequestReceiver() API. > > Here is an example of a handler that uses StringReadChannelListener to > simply attach the post data to the exchange: > > > https://github.com/undertow-io/undertow.js/blob/master/src/main/java/io/undertow/js/StringReadHandler.java > > You can then get it in the next handler using the StringReadHandler.DATA > attachment key. > > Stuart > > ----- Original Message ----- > > From: "Steve Logue" > > To: undertow-dev at lists.jboss.org > > Sent: Sunday, 30 August, 2015 12:00:49 PM > > Subject: [undertow-dev] Who Needs JAX-RS... > > > > Hi Folks, I'm definitely new to Undertow and super impressed with it. > However > > the docs are a bit thin in regards to using the RoutingHandler and doing > > full async processing. May I ask for a quick check of my approach to > using > > Undertow and trying not to block anywhere: > > > > > https://github.com/bitvector2/microservice2/blob/master/src/main/java/org/bitvector/microservice2/HttpActor.java > > > > -STEVEl > > > > > > -- > > > > http://www.bitvector.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150901/5cbab84a/attachment.html From sdouglas at redhat.com Mon Aug 31 23:06:25 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 31 Aug 2015 23:06:25 -0400 (EDT) Subject: [undertow-dev] Who Needs JAX-RS... In-Reply-To: References: <176268384.11631736.1441070441871.JavaMail.zimbra@redhat.com> Message-ID: <174477647.11659442.1441076785160.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Miere Teixeira" > To: "Stuart Douglas" , "Steve Logue" > > Cc: undertow-dev at lists.jboss.org > Sent: Tuesday, 1 September, 2015 12:51:00 PM > Subject: Re: [undertow-dev] Who Needs JAX-RS... > Btw, Stuart, > Quite interesting this new non-blocking API that was introduced in the 1.3.0 > version. It is still possible to do non blocking with the XNIO channel API in prior versions (which is what StringReadChannelListener uses), this new API is just easier to use. > Can you tell me where is a good place to be notified about the 1.3.0's > roadmap and the upcoming new features? 1.3.0.Final will be released just before Wildfly 10 (which is currently planned for early October). In general 1.3.x beta releases are quite stable, most of the core functionality remains unchanged. Stuart > On Mon, Aug 31, 2015 at 10:21 PM Stuart Douglas < sdouglas at redhat.com > > wrote: > > This is not really correct, as you are setting the exchange into blocking > > mode and reading from an input stream. > > > If you want to go full async there are a few things you need to remove the > > 'startBlocking()' call. To read the request entity the easiest way before > > Undertow 1.3 (which is still not quite final) is to use > > io.undertow.util.StringReadChannelListener. If you are a recent 1.3.0 beta > > you can use the new HttpServerExchange.getRequestReceiver() API. > > > Here is an example of a handler that uses StringReadChannelListener to > > simply > > attach the post data to the exchange: > > > https://github.com/undertow-io/undertow.js/blob/master/src/main/java/io/undertow/js/StringReadHandler.java > > > You can then get it in the next handler using the StringReadHandler.DATA > > attachment key. > > > Stuart > > > ----- Original Message ----- > > > > From: "Steve Logue" < bitvector2 at gmail.com > > > > > To: undertow-dev at lists.jboss.org > > > > Sent: Sunday, 30 August, 2015 12:00:49 PM > > > > Subject: [undertow-dev] Who Needs JAX-RS... > > > > > > > > Hi Folks, I'm definitely new to Undertow and super impressed with it. > > > However > > > > the docs are a bit thin in regards to using the RoutingHandler and doing > > > > full async processing. May I ask for a quick check of my approach to > > > using > > > > Undertow and trying not to block anywhere: > > > > > > > > https://github.com/bitvector2/microservice2/blob/master/src/main/java/org/bitvector/microservice2/HttpActor.java > > > > > > > > -STEVEl > > > > > > > > > > > > -- > > > > > > > > http://www.bitvector.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150831/14e15920/attachment-0001.html