Re: Tomcat URL encoding
You need to enable this through the ALLOW_BACKSLASH property: https://tomcat.apache.org/tomcat-8.5-doc/config/systemprops.html On Thu, Jun 15, 2017 at 2:44 PM, Cai, Charles [COMRES/RTC/RTC] < charles@emerson.com> wrote: > Hi Guys, > > Looking for help here after search on the web for couple hours: > > I'm currently doing some testing on Tomcat 8.5.9 I'm trying to encode > all the URL that is requesting to my server. > One thing I have noticed it wasn't working is the `\` (back slash) can't > be allowed in the URL. > > I'm getting the error saying: > INFO [https-jsse-nio-8443-exec-10] > org.apache.coyote.http11.Http11Processor.service > Error parsing HTTP request header > Note: further occurrences of HTTP header parsing errors will be logged at > DEBUG level. > java.lang.IllegalArgumentException: Invalid character found in the > request target. The valid characters are defined in RFC 7230 and RFC 3986 > > The test requesting URL is like this: > https://localhost:8443/passthrough.jsp?ntUserName=comany\testuser > > Currenty, I tried those two approachs: > 1st, set the server.xml with URIEncoding: > http://tomcat.apache.org/tomcat-7.0-doc/config/http.html > > 2nd, add the following filter: > https://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q1 > > It should be like this after the encoding (replace `\` with `%5C` ) : > https://localhost:8443/passthrough.jsp?ntUserName=comany%5Ctestuser > > but none of those options worked for me. > > Thank you > > Charles Cai > >
Re: AsynContext.dispatch() with encoded URI
Issue created https://bz.apache.org/bugzilla/show_bug.cgi?id=61185. On Tue, Jun 13, 2017 at 6:25 PM, Mark Thomas <ma...@apache.org> wrote: > On 13/06/17 21:30, Rossen Stoyanchev wrote: > > hi, > > > > The spec says: > > > > "If the AsyncContext was initialized via the startAsync(ServletRequest, > > ServletResponse) and the request passed is an instance of > > HttpServletRequest , then the dispatch is to the URI returned by > > HttpServletRequest.getRequestURI()" > > > > However AsyncContextImpl seems to be using the servletPath: > > https://github.com/apache/tomcat/blob/9af8708d7ea3817df47f34146a6ff8 > 02d96980fa/java/org/apache/catalina/core/AsyncContextImpl.java#L156-L163 > > > > So given a URL with an encoded slash (and > > UDecoder.ALLOW_ENCODED_SLASH=true): > > /foo/vv%2F1234/add/2 > > > > The dispatch ends up going to: > > /foo/vv/1234/add/2 > > > > Is this intentional? It contradicts the spec. > > The commit that introduced this change is: > https://svn.apache.org/viewvc?view=revision=1497474 > > The fix to ServletRequest.getContextPath() was made a little later: > https://svn.apache.org/viewvc?view=revision=1593621 > > This looks like a fairly minor bug that should be an easy fix. Please > open a bugzilla issue for this. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
AsynContext.dispatch() with encoded URI
hi, The spec says: "If the AsyncContext was initialized via the startAsync(ServletRequest, ServletResponse) and the request passed is an instance of HttpServletRequest , then the dispatch is to the URI returned by HttpServletRequest.getRequestURI()" However AsyncContextImpl seems to be using the servletPath: https://github.com/apache/tomcat/blob/9af8708d7ea3817df47f34146a6ff802d96980fa/java/org/apache/catalina/core/AsyncContextImpl.java#L156-L163 So given a URL with an encoded slash (and UDecoder.ALLOW_ENCODED_SLASH=true): /foo/vv%2F1234/add/2 The dispatch ends up going to: /foo/vv/1234/add/2 Is this intentional? It contradicts the spec. Thanks, Rossen
WebSocket strack trace when browser tab closed
When a browser tab is a closed a stack trace shows up (see below). I think the stack trace means the closing didn't completely cleanly because the client didn't wait. Hence probably nothing to worry about, yet the logs fill up with stack traces. Is there anything that can be done to improve logging in this case and to avoid raising alarm? I thought i'd discuss here before opening a ticket. java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: Connection reset by peer at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:243) at org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:487) at org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:441) at org.apache.tomcat.websocket.WsFrameBase.processDataControl(WsFrameBase.java:324) at org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:270) at org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:116) at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:54) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsReadListener.onDataAvailable(WsHttpUpgradeHandler.java:194) at org.apache.coyote.http11.upgrade.AbstractServletInputStream.onDataAvailable(AbstractServletInputStream.java:203) at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDispatch(AbstractProcessor.java:92) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:609) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1736) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1695) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Connection reset by peer at org.apache.tomcat.websocket.FutureToSendHandler.get(FutureToSendHandler.java:102) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:238) ... 16 common frames omitted Caused by: java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at sun.nio.ch.IOUtil.write(IOUtil.java:65) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:128) at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:185) at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWriteInternal(NioServletOutputStream.java:94) at org.apache.coyote.http11.upgrade.NioServletOutputStream.doWrite(NioServletOutputStream.java:61) at org.apache.coyote.http11.upgrade.AbstractServletOutputStream.writeInternal(AbstractServletOutputStream.java:153) at org.apache.coyote.http11.upgrade.AbstractServletOutputStream.write(AbstractServletOutputStream.java:121) at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:94) at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:81) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:393) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:287) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:233) ... 16 common frames omitted
Re: WebSocket strack trace when browser tab closed
On Fri, Sep 5, 2014 at 9:33 AM, Mark Thomas ma...@apache.org wrote: On 05/09/2014 13:46, Rossen Stoyanchev wrote: When a browser tab is a closed a stack trace shows up (see below). I think the stack trace means the closing didn't completely cleanly because the client didn't wait. Hence probably nothing to worry about, yet the logs fill up with stack traces. Is there anything that can be done to improve logging in this case and to avoid raising alarm? I thought i'd discuss here before opening a ticket. Tomcat version? 7.0.54 but also occurs with 8.0.12
Re: WebSocket strack trace when browser tab closed
On Fri, Sep 5, 2014 at 10:26 AM, Mark Thomas ma...@apache.org wrote: On 05/09/2014 15:17, Mark Thomas wrote: On 05/09/2014 15:06, Rossen Stoyanchev wrote: On Fri, Sep 5, 2014 at 9:33 AM, Mark Thomas ma...@apache.org wrote: On 05/09/2014 13:46, Rossen Stoyanchev wrote: When a browser tab is a closed a stack trace shows up (see below). I think the stack trace means the closing didn't completely cleanly because the client didn't wait. Hence probably nothing to worry about, yet the logs fill up with stack traces. Is there anything that can be done to improve logging in this case and to avoid raising alarm? I thought i'd discuss here before opening a ticket. Tomcat version? 7.0.54 but also occurs with 8.0.12 Thanks. I see what is going on. The IOException is handled but not when it is wrapped with ExecutionException. We should be able to fix that... I take that back. Tomcat is wrapping the ExecutionException in an IOException and is handling the IOException. Tomcat isn't logging this - the Endpoint is in the onError() method. This looks like an application question rather than a Tomcat one. Ok, that wasn't immediately obvious. Thanks for the quick response. I'll have a look.
Re: Tomcat opening thousands of files
I gave this a quick try with the spring-websocket-portfolio sample [1] with Tomcat 8. The output of the lsof command is just over 200 initially and then goes up a little but not much (about 10). From the client-side I configured the SockJS client to use the WebSocket transport (i.e. using Tomcat's WebSocket engine on the server side) first and then tried the iframe-eventsource transport (SSE) which uses Tomcat's Servlet 3 async request support to stream messages over HTTP. No difference. Prashant you'll need to narrow it down a bit to see what is the key to reproducing the issue. Rossen [1] https://github.com/rstoyanchev/spring-websocket-portfolio On Mon, Jun 16, 2014 at 1:25 PM, Prashant Deva prashant.d...@gmail.com wrote: hmm, we are just using spring websockets to send messages. In fact there is only two 'topics' in total, so there isnt much the application is doing quite frankly. do you think this is a spring issue? Prashant On Mon, Jun 16, 2014 at 10:10 AM, David kerber dcker...@verizon.net wrote: On 6/16/2014 12:57 PM, Prashant Deva wrote: I am using Tomcat 7.0.53 with Spring 4 websockets (spring's SockJS support). I notice that tomcat opens thousands of files. Correction: your application opens thousands of files, or leaves them open when it should have closed them. Just running for a few hours I noticed, it opened 16,552 files: root@dripcast:~# lsof -p 22691 | wc -l 16552 Our logs are full of this exception thrown tons of times every second: org.apache.tomcat.util.net.AprEndpoint$Acceptor run SEVERE: Socket accept failed org.apache.tomcat.jni.Error: 24: Too many open files at org.apache.tomcat.jni.Socket.accept(Native Method) at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:992) at java.lang.Thread.run(Thread.java:745) Here is a sample of some of the open files, using lsof. What can we do to fix this? java2056 root *904u sock0,7 0t0 77846 can't identify protocol java2056 root *905u IPv6 76695 0t0TCP dripcast:https-pppoe.95-55-165-198.dynamic.avangarddsl.ru:1376 (ESTABLISHED) java2056 root *906u IPv6 74369 0t0TCP dripcast:https-fibre.backbonetechnology.com:46415 (ESTABLISHED) java2056 root *907u IPv6 76696 0t0TCP dripcast:https-outbound.kenshoo.com:14292 (ESTABLISHED) java2056 root *908u sock0,7 0t0 76697 can't identify protocol java2056 root *909u sock0,7 0t0 76698 can't identify protocol java2056 root *910u 0,90 7351 anon_inode java2056 root *911u 0,90 7351 anon_inode java2056 root *912u 0,90 7351 anon_inode java2056 root *913u 0,90 7351 anon_inode java2056 root *914u 0,90 7351 anon_inode java2056 root *915u sock0,7 0t0 76699 can't identify protocol java2056 root *916u sock0,7 0t0 76700 can't identify protocol java2056 root *917u sock0,7 0t0 76701 can't identify protocol java2056 root *918u sock0,7 0t0 76702 can't identify protocol java2056 root *919u sock0,7 0t0 77845 can't identify protocol java2056 root *920u sock0,7 0t0 76705 can't identify protocol java2056 root *921u IPv6 76906 0t0TCP dripcast:https-c-67-185-79-130.hsd1.wa.comcast.net:61280 (ESTABLISHED) java2056 root *922u 0,90 7351 anon_inode java2056 root *923u sock0,7 0t0 77847 can't identify protocol java2056 root *924u sock0,7 0t0 75196 can't identify protocol java2056 root *925u sock0,7 0t0 76907 can't identify protocol java2056 root *926u IPv6 76908 0t0TCP dripcast:https-cdm-75-108-116-63-nixa.mid.suddenlink.net:56996 (ESTABLISHED) java2056 root *927u 0,90 7351 anon_inode java2056 root *928u IPv6 76909 0t0TCP dripcast:https-fibre.backbonetechnology.com:46416 (ESTABLISHED) java2056 root *929u sock0,7 0t0 76910 can't identify protocol java2056 root *930u sock0,7 0t0 76911 can't identify protocol java2056 root *931u IPv6 76912 0t0TCP dripcast:https-outbound.kenshoo.com:14309 (ESTABLISHED) java2056 root *932u 0,90 7351 anon_inode java2056 root *933u 0,90 7351 anon_inode java2056 root *934u 0,9
Re: Tomcat opening thousands of files
On Mon, Jun 16, 2014 at 4:04 PM, Prashant Deva prashant.d...@gmail.com wrote: Rossen, Did you use an external queue? Yes I did have the sample configured to use RabbitMQ for broadcasting messages. That's running as a separate process though so it shouldn't change the output of lsof. How many clients were connected at the same time? In the sample, just one. I also ran a load test with 500 concurrent users (1 million messages) and the file descriptor count remains stable (around 500). I'd reverse the question, how many users do you have to run with to demonstrate the issue? Rossen
Re: CSRF protection in Tomcat 7
Spring Security provides CSRF protection as well: http://docs.spring.io/spring-security/site/docs/3.2.2.RELEASE/reference/htmlsingle/#csrf On Mon, Mar 24, 2014 at 3:49 PM, Akash Jain akash.delh...@gmail.com wrote: How can I prevent CSRF protection using Tomcat 7 ? I have heard that tomcat 7 provides CSRF filter http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/filters/CsrfPreventionFilter.html But is it thread safe ? Or shall we do a custom protection in our spring 3 application ?
Re: WebSocket - very slow socket write (~15 min)
Hi- Any comments? I suspect an issue with the reliability of the timeout setting on Linux since the same behaves more reliably on Windows. In any case a 15 minute write to a socket with timeout setting of 20 seconds seems like a bug. Thanks On Wed, Mar 19, 2014 at 10:19 PM, Rossen Stoyanchev rstoyanc...@gopivotal.com wrote: hi, The scenario involves a mobile phone switching from wifi to (unstable) mobile network. The phone looses the connection but the server doesn't seem aware. Basically the server tries to send a message and blocks the thread on which this is done. From the logs it seems to take about 15 minutes before a java.net.SocketException: Broken pipe finally occurs. Is this expected behavior or an issue? I've seen the websocket-how-to on setting BLOCKING_SEND_TIMEOUT. However I would have expected a timeout based on the default value of 20 seconds. Also it says the property is configurable through the WebSocketSession but for something like this I would expect a global setting. Is there such a way to do that? The issue was originally reported here [1]. It's a long thread and might not add to much more. It's worth pointing out the issue seems to be reproducible with even 1 phone. Also it could not be reproduced on a windows server with the same tomcat7 server (7.0.52). Here is the stack of the the writing thread: - java.net.SocketOutputStream.socketWrite0(java.io.FileDescriptor, byte[], int, int) @bci=0 (Compiled frame; information may be imprecise) - java.net.SocketOutputStream.socketWrite(byte[], int, int) @bci=52, line=113 (Compiled frame) - java.net.SocketOutputStream.write(byte[], int, int) @bci=4, line=159 (Compiled frame) - org.apache.coyote.http11.upgrade.BioServletOutputStream.doWrite(boolean, byte[], int, int) @bci=8, line=37 (Compiled frame) - org.apache.coyote.http11.upgrade.AbstractServletOutputStream.writeInternal(byte[], int, int) @bci=24, line=125 (Compiled frame) - org.apache.coyote.http11.upgrade.AbstractServletOutputStream.write(byte[], int, int) @bci=16, line=92 (Compiled frame) - org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(boolean) @bci=68, line=94 (Compiled frame) - org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(javax.websocket.SendHandler, java.nio.ByteBuffer[]) @bci=12, line=81 (Compiled frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(org.apache.tomcat.websocket.WsRemoteEndpointImplBase$MessagePart) @bci=349, line=378 (Compiled frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(byte, java.nio.ByteBuffer, boolean, javax.websocket.SendHandler) @bci=99, line=279 (Compiled frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.write() @bci=97, line=672 (Interpreted frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(java.nio.CharBuffer, boolean) @bci=43, line=210 (Interpreted frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(java.lang.String, boolean) @bci=13, line=185 (Interpreted frame) - org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(java.lang.String, boolean) @bci=6, line=49 (Compiled frame) Rossen
WebSocket - very slow socket write (~15 min)
hi, The scenario involves a mobile phone switching from wifi to (unstable) mobile network. The phone looses the connection but the server doesn't seem aware. Basically the server tries to send a message and blocks the thread on which this is done. From the logs it seems to take about 15 minutes before a java.net.SocketException: Broken pipe finally occurs. Is this expected behavior or an issue? I've seen the websocket-how-to on setting BLOCKING_SEND_TIMEOUT. However I would have expected a timeout based on the default value of 20 seconds. Also it says the property is configurable through the WebSocketSession but for something like this I would expect a global setting. Is there such a way to do that? The issue was originally reported here [1]. It's a long thread and might not add to much more. It's worth pointing out the issue seems to be reproducible with even 1 phone. Also it could not be reproduced on a windows server with the same tomcat7 server (7.0.52). Here is the stack of the the writing thread: - java.net.SocketOutputStream.socketWrite0(java.io.FileDescriptor, byte[], int, int) @bci=0 (Compiled frame; information may be imprecise) - java.net.SocketOutputStream.socketWrite(byte[], int, int) @bci=52, line=113 (Compiled frame) - java.net.SocketOutputStream.write(byte[], int, int) @bci=4, line=159 (Compiled frame) - org.apache.coyote.http11.upgrade.BioServletOutputStream.doWrite(boolean, byte[], int, int) @bci=8, line=37 (Compiled frame) - org.apache.coyote.http11.upgrade.AbstractServletOutputStream.writeInternal(byte[], int, int) @bci=24, line=125 (Compiled frame) - org.apache.coyote.http11.upgrade.AbstractServletOutputStream.write(byte[], int, int) @bci=16, line=92 (Compiled frame) - org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(boolean) @bci=68, line=94 (Compiled frame) - org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(javax.websocket.SendHandler, java.nio.ByteBuffer[]) @bci=12, line=81 (Compiled frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(org.apache.tomcat.websocket.WsRemoteEndpointImplBase$MessagePart) @bci=349, line=378 (Compiled frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(byte, java.nio.ByteBuffer, boolean, javax.websocket.SendHandler) @bci=99, line=279 (Compiled frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.write() @bci=97, line=672 (Interpreted frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(java.nio.CharBuffer, boolean) @bci=43, line=210 (Interpreted frame) - org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(java.lang.String, boolean) @bci=13, line=185 (Interpreted frame) - org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(java.lang.String, boolean) @bci=6, line=49 (Compiled frame) Rossen
Re: WebSocket - very slow socket write (~15 min)
Oops, and here is the (missing) link to original report: [1] https://github.com/rstoyanchev/spring-websocket-portfolio/issues/31
Re: Tomcat and Spring Framework
On Mon, Mar 10, 2014 at 3:58 PM, Mark H. Wood mw...@iupui.edu wrote: It's probably worth asking what full-fledged enterprise applications means. I'm not aware of any specification with that title. Indeed there is no such specification. The point is that Java enterprise development is not always defined nor does it have to be defined by specs. The spec development process is tricky at best. You have to do it not too early (ahead of experience) and not too late either. Open source is actually in a much better position to evolve continuously by capturing developer feedback and providing results quickly. So certainly don't discount just because it's not a spec. Rossen
Re: Severe 7.0.47 startup performance regression
On Thu, Dec 5, 2013 at 7:05 AM, Mark Thomas ma...@apache.org wrote: There is also the programmatic interface to WebSockets so once there is a way to disable the SCI, you can use the programmatic interface to set everything up. Yes, the very existence of a programmatic interface alternative more or less implies there should be a way to disable the SCI and still be able to use WebSocket. Is it not possible to use an absolute-ordering element in web.xml? I was under the impression that's the mechanism for applications to control which web fragments to include or exclude. My understanding from the EG discussions was that SCI was chosen precisely because it is an existing mechanism that is understood, so I don't understand the reason why a new mechanism is needed to control SCI scanning. Rossen
Re: Severe 7.0.47 startup performance regression
On Thu, Dec 5, 2013 at 10:57 AM, Mark Thomas ma...@apache.org wrote: On 05/12/2013 14:22, Rossen Stoyanchev wrote: On Thu, Dec 5, 2013 at 7:05 AM, Mark Thomas ma...@apache.org wrote: There is also the programmatic interface to WebSockets so once there is a way to disable the SCI, you can use the programmatic interface to set everything up. Yes, the very existence of a programmatic interface alternative more or less implies there should be a way to disable the SCI and still be able to use WebSocket. Is it not possible to use an absolute-ordering element in web.xml? That provides a way to exclude JARs from scanning (which should be most of the problem) but not classes. Okay, I wasn't aware of that. It would have been useful to somehow exclude the WAR itself too, so it's all one mechanism. I was under the impression that's the mechanism for applications to control which web fragments to include or exclude. My understanding from the EG discussions was that SCI was chosen precisely because it is an existing mechanism that is understood, so I don't understand the reason why a new mechanism is needed to control SCI scanning. I think there is still a use for being able to disable container provided SCIs on a per context basis outside of what is available in the spec. That said, if no-one agrees with me then I have plenty of other things to be working on. I agree there should be a way to disable container provided SCI. My surprise was that there isn't already a way to do that.
Re: Websockets with tomcat clustering and session replication
On Sun, Dec 1, 2013 at 4:33 PM, Nir A n...@netomedia.com wrote: My POC web application has one html page with javascript web socket send\recieve messages. What i did notice that might shade light on whats the problem is the following scenario: If i press f5 on the browser, the web page is loaded and a new http handshake is taking place. when that happens all the attributes do replicate!!! Is there a way to make the attribute replicate without the need of refreshing the page? In HTTP you have many requests associated with a session id. With session replication, each new request could go to a different server and still access the same HTTP session attributes. In WebSocket on the other hand there is a single connection the server and if you lose it, you have to reconnect, which is probably what pressing F5 does for you. Unless I'm missing something, you have to detect when the WebSocket connection is closed on client side and reconnect. Rossen
Re: Exception by upgrading to WebSocket connection in 8.0.0-RC1
On Fri, Aug 16, 2013 at 4:58 AM, Sergey Shcherbakov sshcherba...@gopivotal.com wrote: Thank you for the hints! Upgraded to SF 4.0.0.BUILD-SNAPSHOT (14.08.2013) and now getting another exception: 2013-08-16 10:49:02,711 15913 ERROR [http-nio-8080-exec-4] org.apache.coyote.http11.Http11NioProtocol - Error reading request, ignored java.lang.NullPointerException: null at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.init( WsRemoteEndpointImplServer.java:57) ~[tomcat-embed-core-8.0.0-RC1.jar:8.0.0-RC1] FWIW I've been using 8.0 RC1 (the standalone version), maybe there is an issue related to the embedded version? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exception by upgrading to WebSocket connection in 8.0.0-RC1
On Thu, Aug 15, 2013 at 12:39 PM, Nick Williams nicho...@nicholaswilliams.net wrote: I suspect that as both Spring 4 and Tomcat 8 are both in RC / milestone stage that Tomcat changed in a way Spring wasn't expecting. Right. This is already fixed actually. Just use Spring Framework 4.0.0.BUILD-SNAPSHOT. Once the ticket below is completed, the underlying cause for this issue should go away by the way: https://issues.apache.org/bugzilla/show_bug.cgi?id=55314 Rossen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: websockets questions
Andre, if you happen to use the Spring Framework already, we have a milestone release (version 4.0 M1) that provides fallback options based on the SockJS protocol. The next milestone 2 due in a week will provide higher level (sub-protocol) support for messaging patterns such as pub-sub and point-to-point. Rossen
Maven plugin for Tomcat 8?
Is there any way to use the Tomcat maven plugin with Tomcat 8 (i.e. trunk snapshots)? The documentation lists how to configure Tomcat 6 and 7 only [1]. Rossen [1] http://tomcat.apache.org/maven-plugin-trunk/
Re: IOException from the response during an async request
Mark, While there is no response on the Servlet spec list, I have some follow-up questions: If you call complete() you'll end up with an IllegalStateException when the error handler kicks in. You have to use dispatch(). The error handle kicks in as soon as the dispatch() tries to write to the response. Do you mean dispatch() + write to the response from within the dispatched thread thereby causing an error? I actually have no reason to write to the response at that point. I'm just trying to complete the async request and release any associated Servlet container resources. I did try dispatch() and then complete() from within the dispatched thread. It leads to a similar ISE from AsyncStateMachine. Lastly if I do call complete() without dispatch, thereby causing the ISE, does that actually complete the async request and release any container resources? I'm just trying to decide if this is something I can live with for now while the EG decides. Thanks, Rossen
Re: IOException from the response during an async request
The questions have been posted on the Servlet spec user list: https://java.net/projects/servlet-spec/lists/users/archive/2013-05/message/5 On Sun, May 5, 2013 at 1:34 PM, Mark Thomas ma...@apache.org wrote: On 05/05/2013 17:29, Rossen Stoyanchev wrote: - Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Sunday, May 5, 2013 11:35:54 AM Subject: Re: IOException from the response during an async request From what I can see to complete the async request in this (or any async scenario) one has to call asyncContext.dispatch(), wait for the dispatch, and then call asyncContext.complete() in the dispatched thread, or let the dispatched thread complete. And this is true even if the IOException occurred in the brief period after startAsync but before the initial container thread has exited. In the non-error case, you can call complete() or dispatch(). The non-error case is (currently) different. If you call complete() you'll end up with an IllegalStateException when the error handler kicks in. You have to use dispatch(). The error handle kicks in as soon as the dispatch() tries to write to the response. I have no need to write to the response. I know it blew up and am trying to find a way to complete the request. Javadoc for complete() says it is legal to call it without making further qualifications. Based on that alone I would expect complete() to just work. In the non-error case it does. The error handling for errors on non-container threads is not well specified. I presume the error handler kicks as a result of the IOException from the response? No. The IOException sets a flag that an error has occurred. Once the control returns to the container the error handling kicks in as soon as that flag is checked. And it probably notifies listeners asynchronously No. Listeners are notified synchronously. so by the time it gets around to doing that, I've already caught the exception and called complete(). No. Calling complete() hands control back to the container. If this is true there seems to be an inherent race condition. The analysis is way off. There is no race condition here. I.e. even if dispatch, couldn't the dispatch complete sooner? Potentially the error flag could be checked sooner for both complete() and dispatch(). However, I'm not sure at this point what affect that would have on the current error handling. Given that onError handlers aren't going to do I/O would, would it be feasible to call them synchronously? They are called synchronously. This is a single threaded ordering problem not a multi-threading timing problem. Or at least have some synchronization that holds up completion if error handlers have not been notified. That solution is trying to solve a problem that doesn't exist. Some guidance from the EG would be good here. It does seem more natural that a call to complete() should be sufficient in this case. However, that appears to preclude the error handlers from firing since the description of error handlers describes the request completing after the handler is fired. Maybe: complete() - no error handler dispatch() - error handler From an application perspective, it would be best to aim for consistent behavior for complete(). The dispatch doesn't give any benefit for the application for the added complexity and effort. One for the Servlet EG I think. It would be useful to clarify indeed. Are you posting the question or should I? Go for it. The questions as I see them are: 1. What error handling, if any, is triggered if an Exception occurs during asynchronous processing (e.g. an IOException because the client dropped the connection) a) on a container thread b) on a non-container thread After our I'm leaning towards none for both. 2. After any such exception what mechanisms are available for the application to complete async processing? I'm leaning towards: complete() and dispatch() With dispatch likely to be a poor choice if there has been an IO error as the chances of being able to return anything to the user are slim (but if/when that does fail AsyncListener.onError() will be triggered as per the current spec). Essentially Tomcat does all of this apart from allowing complete() (because the error flag get checked). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Status 204 (no content) and Content-Type header
Thanks! - Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Saturday, May 4, 2013 5:57:15 PM Subject: Re: Status 204 (no content) and Content-Type header On 04/05/2013 21:21, Mark Thomas wrote: On 04/05/2013 20:43, Rossen Stoyanchev wrote: It appears that Tomcat ignores the Content-Type header when the status is set to 204 (No Content). Correct. It happens in AbstractHttp11Processor.prepareResponse() I can see the rational for that, however is there a strong reason why Tomcat should care if it is set by the application? No. I took a look at RFC 2616. Section 10.2.5 states that a 204 response may contain updated metainformation in the form of entity headers and, as per section 7.1, Content-Type is an entity header so it should be not be skipped if set for a 204 response. On those grounds, this is a Tomcat bug. There are some corner cases [1]. That looks more like a bug in 3rd-party code. Bugs in 3rd party code are rarely sufficient justification for changing Tomcat's behaviour. In this case, the RFC2616 argument is a much stronger one and it looks to me like the code will be changed (regardless of [1], not because of it). Fixed in trunk and 7.0.x and will be in 7.0.40 onwards. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
IOException from the response during an async request
When a request has been put into async mode (via request.startAsync), the
response may remain open long after the initial container thread has exited.
Meanwhile a non-container thread is allowed to write to the response but if an
IOException occurs, there is obviously no way to report it to the client since
the error implies we're unable to write to the response any more.
From what I can see to complete the async request in this (or any async
scenario) one has to call asyncContext.dispatch(), wait for the dispatch, and
then call asyncContext.complete() in the dispatched thread, or let the
dispatched thread complete. And this is true even if the IOException occurred
in the brief period after startAsync but before the initial container thread
has exited.
This is based on the Javadoc of asyncContext.complete() by the way:
* pIt is legal to call this method any time after a call to
* {@link ServletRequest#startAsync()} or
* {@link ServletRequest#startAsync(ServletRequest, ServletResponse)},
* and before a call to one of the ttdispatch/tt methods
* of this class.
It seems rather convoluted for dealing with exceptions from the response
especially in cases where the client has gone away, so I just wanted to confirm
it's the correct way and the only way.
Thanks,
Rossen
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IOException from the response during an async request
- Original Message -
From: Mark Thomas ma...@apache.org
To: Tomcat Users List users@tomcat.apache.org
Sent: Sunday, May 5, 2013 11:35:54 AM
Subject: Re: IOException from the response during an async request
From what I can see to complete the async request in this (or any
async scenario) one has to call asyncContext.dispatch(), wait for
the dispatch, and then call asyncContext.complete() in the dispatched
thread, or let the dispatched thread complete. And this is true
even if the IOException occurred in the brief period after startAsync
but before the initial container thread has exited.
In the non-error case, you can call complete() or dispatch().
The non-error case is (currently) different.
If you call complete() you'll end up with an IllegalStateException
when the error handler kicks in. You have to use dispatch(). The error
handle kicks in as soon as the dispatch() tries to write to the response.
I have no need to write to the response. I know it blew up and am trying to
find a way to complete the request.
Javadoc for complete() says it is legal to call it without making further
qualifications. Based on that alone I would expect complete() to just work.
I presume the error handler kicks as a result of the IOException from the
response? And it probably notifies listeners asynchronously so by the time it
gets around to doing that, I've already caught the exception and called
complete(). If this is true there seems to be an inherent race condition. I.e.
even if dispatch, couldn't the dispatch complete sooner? Given that onError
handlers aren't going to do I/O would, would it be feasible to call them
synchronously? Or at least have some synchronization that holds up completion
if error handlers have not been notified.
This is based on the Javadoc of asyncContext.complete() by the way:
* pIt is legal to call this method any time after a call to *
{@link ServletRequest#startAsync()} or * {@link
ServletRequest#startAsync(ServletRequest, ServletResponse)}, * and
before a call to one of the ttdispatch/tt methods * of this
class.
It seems rather convoluted for dealing with exceptions from the
response especially in cases where the client has gone away, so I
just wanted to confirm it's the correct way and the only way.
Some guidance from the EG would be good here. It does seem more
natural that a call to complete() should be sufficient in this case. However,
that appears to preclude the error handlers from firing since the
description of error handlers describes the request completing after
the handler is fired.
Maybe:
complete() - no error handler
dispatch() - error handler
From an application perspective, it would be best to aim for consistent
behavior for complete(). The dispatch doesn't give any benefit for the
application for the added complexity and effort.
One for the Servlet EG I think.
It would be useful to clarify indeed. Are you posting the question or should I?
Thanks,
Rossen
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Status 204 (no content) and Content-Type header
It appears that Tomcat ignores the Content-Type header when the status is set to 204 (No Content). I can see the rational for that, however is there a strong reason why Tomcat should care if it is set by the application? There are some corner cases [1]. Rossen [1] https://github.com/sockjs/sockjs-protocol/blob/master/sockjs-protocol-0.3.3.py#L746 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Standalone use of WebSocket client
Is the (JSR-356) WebSocket client in trunk meant to be usable in a standalone app? I have a Maven app that depends on tomcat-websocket and tomcat-websocket-api that gives the below exception. java.lang.NoClassDefFoundError: org/apache/tomcat/util/codec/binary/Base64 at org.apache.tomcat.websocket.WsWebSocketContainer.generateWsKeyValue(WsWebSocketContainer.java:348) at org.apache.tomcat.websocket.WsWebSocketContainer.createRequestHeaders(WsWebSocketContainer.java:338) at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:169) The tomcat-util jar in the lib folder of Tomcat contains this class but the tomcat-util jar in Maven doesn't. thanks, Rossen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Standalone use of WebSocket client
- Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, April 30, 2013 5:35:55 PM Subject: Re: Standalone use of WebSocket client The Maven snapshot probably isn't recent enough. Yep. That is it. Let me know if you want me to push another snapshot. I'd like another snapshot but I'm okay waiting till tomorrow if there is an automated nightly build. Thanks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AsyncListener.onError and disconnected client
- Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, April 25, 2013 8:42:55 AM Subject: Re: AsyncListener.onError and disconnected client It is. The issue is when is happens. The issue is that there is no event (I am aware of) that the container can monitor. BIO - Only know once a read/write fails. NIO - A current read/write will fail. The socket can be explicitly tested (but isn't currently) If the socket is in the poller I'd expect an error event If the socket was added to the poller I'd expect an error event APR - A current read/write will fail. If the socket is in the poller I'd expect an error event If the socket was added to the poller I'd expect an error event It might be possible to test the socket but I haven't checked There are times when a socket is not being used for read/write and is not in a poller (e.g. when the app is doing some processing that doesn't require output to the user agent). You won't get a notification of disconnect in this case until the app has finished. I wonder (for NIO and APR) if you could always have the socket in the poller in order to detect a disconnect? Would it be feasible to test sockets periodically? I can imagine some such logic is used to track async request timeouts. Possibly not all sockets, but only the ones in async mode, which should be a smaller subset. Since the recommended time for long poll duration is around 30 seconds, checking every 5 seconds would go a long way. Of course if keeping the socket in the poller is possible, instant detection (as with WebSockets) would be ideal. This really comes down to how the spec has been written. onError is for errors that happen in the container during dispatch (i.e. at the end of the async phase) that the app does not have visibility of. It allows the container to tell the app that the request did not complete normally. It is not intended for IO errors that happen during the async phase which the app can just catch. Thanks for all the explanations! Rossen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AsyncListener.onError and disconnected client
- Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 24, 2013 2:14:53 PM Subject: Re: AsyncListener.onError and disconnected client On 24/04/2013 18:38, Rossen Stoyanchev wrote: - Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 24, 2013 12:47:54 PM Subject: Re: AsyncListener.onError and disconnected client On 24/04/2013 16:33, Rossen Stoyanchev wrote: Hi, I've seen various discussions here and on the web but I haven't found a conclusive answer. Why does an AsyncListener not receive onError notifications when a client disconnects? Because the Servlet EG says that is the required behaviour. The EG is currently revisiting that decision. See https://java.net/jira/browse/SERVLET_SPEC-44 Thanks for that reference. Is there something in the spec that explicitly makes requires this? Not that I am aware of which why I said EG rather than specification. The JIRA ticket is about adding a disconnect callback but I can imagine in the very least, onComplete can be called. After the connection is over. onComplete should be called once the connection times out. My understanding is that onComplete is always called regardless of how the async request completed, i.e. following onTimeout, or onError. I would expect it to be called after a client disconnect as well for consistency. Also I wonder if a disconnect method is even needed? The onError method could be called indicating that the asynchronous operation has failed to complete (from the Javadoc). That's actually what I expected when I first tried. To my knowledge there is nothing inherent in NIO and TCP that prevents the server from detecting that the client has disconnected. The WebSocket implementation detects disconnected clients immediately and other HTTP servers (e.g. node) seem to be able to do this. What is it about the Servlet async support that prevents it from knowing when a client has disconnected? It would mean having to ditch the BIO connector / or not being able to pass the TCK (assuming the TCK tested this) when using the BIO connector. I guess this goes back to the previous question about whether there is an explicit requirement and therefore test. Why would a TCK test explicitly check that disconnects are not communicated to AsyncListeners? Or is it a more indirect consequence of some other requirement? My point was that if a disconnect event was added to the spec then the BIO connector could never be spec compliant. If I understand correctly, you're saying the BIO connector can not detect a client disconnect. On reflection, it might not be that bad. The event could be fired just not when the client disconnects. It would have to wait until an attempt was made to read from / write to the socket. That's actually not very different from the current situation where I catch any exceptions while trying to write to the response and then call asyncContext.complete(). I suppose it would make it more clear that a client has disconnected (as opposed to some other error), but once writing to the response has raised an error, it doesn't make a big difference what the error is. Rossen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AsyncListener.onError and disconnected client
Hi, I've seen various discussions here and on the web but I haven't found a conclusive answer. Why does an AsyncListener not receive onError notifications when a client disconnects? The scenario is that async processing starts (via request.startAsync), the Servlet container thread is exited, and then at some point before the async request completes, the client goes away (e.g. browser tab is closed). The only way I've found to detect the client has gone away is to write to and flush the servlet response buffer. To my knowledge there is nothing inherent in NIO and TCP that prevents the server from detecting that the client has disconnected. The WebSocket implementation detects disconnected clients immediately and other HTTP servers (e.g. node) seem to be able to do this. What is it about the Servlet async support that prevents it from knowing when a client has disconnected? Thanks, Rossen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AsyncListener.onError and disconnected client
- Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 24, 2013 12:47:54 PM Subject: Re: AsyncListener.onError and disconnected client On 24/04/2013 16:33, Rossen Stoyanchev wrote: Hi, I've seen various discussions here and on the web but I haven't found a conclusive answer. Why does an AsyncListener not receive onError notifications when a client disconnects? Because the Servlet EG says that is the required behaviour. The EG is currently revisiting that decision. See https://java.net/jira/browse/SERVLET_SPEC-44 Thanks for that reference. Is there something in the spec that explicitly makes requires this? The JIRA ticket is about adding a disconnect callback but I can imagine in the very least, onComplete can be called. After the connection is over. To my knowledge there is nothing inherent in NIO and TCP that prevents the server from detecting that the client has disconnected. The WebSocket implementation detects disconnected clients immediately and other HTTP servers (e.g. node) seem to be able to do this. What is it about the Servlet async support that prevents it from knowing when a client has disconnected? It would mean having to ditch the BIO connector / or not being able to pass the TCK (assuming the TCK tested this) when using the BIO connector. I guess this goes back to the previous question about whether there is an explicit requirement and therefore test. Why would a TCK test explicitly check that disconnects are not communicated to AsyncListeners? Or is it a more indirect consequence of some other requirement? Not sure about APR/native. I'd need to look at the docs and probably run some tests. Thanks, Rossen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
