DO NOT REPLY [Bug 51181] Add support for Web Sockets
https://issues.apache.org/bugzilla/show_bug.cgi?id=51181 --- Comment #39 from Mark Thomas ma...@apache.org 2012-02-19 16:35:14 UTC --- Short update for folks not following the dev list. - added fragmented packet support - added *very* basic test client -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: AccessLogValve enhancement
Mark, On 2/15/12 4:33 PM, Mark Thomas wrote: I also be +1 to considering making this the sole way AccessLogValve logging may be output. The only possible reason why we wouldn't want to do this is that lots of users simply cannot figure out how to configure the loggers. Yes, it's really not all that hard and it's fairly well-documented, but at least with the output file name in the Valve attributes, there's no question where the log messages are going. Philosophically, I'm not really sure why the flexibility of a full-featured logging system (JULI, log4j, etc.) is required for access logging: there's not much opportunity to use all the features they provide (log level filtering, log-message aggregation to log files and log-file multiplexing/splitting). Access logs typically log one thing (accesses), log it all the time, and always write to the same log file. I'm not adverse to the patch, I just don't really see a need for it. -chris signature.asc Description: OpenPGP digital signature
Re: AccessLogValve enhancement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/02/2012 17:20, Christopher Schultz wrote: Mark, On 2/15/12 4:33 PM, Mark Thomas wrote: I also be +1 to considering making this the sole way AccessLogValve logging may be output. The only possible reason why we wouldn't want to do this is that lots of users simply cannot figure out how to configure the loggers. Yes, it's really not all that hard and it's fairly well-documented, but at least with the output file name in the Valve attributes, there's no question where the log messages are going. Fair point. Philosophically, I'm not really sure why the flexibility of a full-featured logging system (JULI, log4j, etc.) is required for access logging: there's not much opportunity to use all the features they provide (log level filtering, log-message aggregation to log files and log-file multiplexing/splitting). Access logs typically log one thing (accesses), log it all the time, and always write to the same log file. I'm not adverse to the patch, I just don't really see a need for it. I was coming from the I'd rather not maintain a bunch of code to solve a problem that the logging frameworks have already solved (threading, roll-over, output to multiple destinations) angle. You know me, always happy to delete some code from the Tomcat code base. My main point is that it is something worthy of discussion. And that is what we are doing. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPQTZBAAoJEBDAHFovYFnneXEQAJucbwt4zm/gTv093FuwfC0Y m6bJDiObPzaxuZNnWvaKKwM1XY4ZCGCkKV7H5xoZQIuMOnzMVm1Z/9qcuMiiuml+ UoUxAH1mZoKeyDmRxAgl7DhYYwVf3XPAnL+oI2K/XuxNRuJvehUQRm3ouxZeO81a gTKs3GYA/ZxVL0p7fJ1pPnh44xqg4ly7dDLaUx5dVZU6WJ/14pwuIwQCCLDu9C+r FvC2k/Bc13fXxrAzYuTiat83DztEMohRPXmyxVUnM4XG+eM1jMub31/4+6S9TrSt 2TX6lRmzw36khrYUKYWsmPJxsS+5rSVaaOfO5ekSUzLnuhshoAEUYe1pPzVTHd02 1a7njJuqzdKNjU4B1sfWivLXPspmhmK6pnUtmoIF98NRr1XsMe9O/4AhG7NUIpoX Ci7Nd1WygWUdn9evMxzcUhtrmkAbvcMuQ+71737Xn8OJKDzvdc0b6p6ZEgm8cHnB QHM+whU38Cb6Vy+vlyFQpwmJ8qolRrT2Ob76h22pZxm9PDQF18OWU6tqi3EabjU+ 9YV1fPPJNjrvNk9H27vaQIurrXMhX5yTZGb7PsVSinjXbq4zNEWZlcQSI5t+Pf5K 5AaRnxcptDIFcv+y9YFZv4ecqOPFHCUj03XSjRLBZd1V2vUdbkuTmpToLLo4Mwwp Rzy9If3xAw9+lSqza8hS =t+lP -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51197] sendError/sendRedirect don't work with AsyncContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=51197 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from Konstantin Kolinko knst.koli...@gmail.com 2012-02-20 01:00:26 UTC --- (In reply to comment #4) There is a unit test already for this issue that passes. I expanded it to cover calling sendError in a new thread and the same thread (this is one of the specifics the report is lacking) and both tests pass with BIO. For reference, the test is TestAsyncContextImpl - search for 51197 and see r1124342 and r1290875 The test does not check what response text is sent to the client. It just checks response status and the access log. It might be that client is responded with correct HTTP status line, but HTTP response content is empty. 1. I tried to update the doTestBug51197(..) test in TestAsyncContextImpl to test for error message, but it is not trivial. As of now it is not possible to use the ByteChunk passed to getUrl() call. The URLConnection used to implement getUrl() cannot read content if response code is = 400. If I remove status code check in TomcatBaseTest#getUrl() to always read response text regardless of status code, it just fails with an IOException: [[[ Testcase: testBug51197b took 4,188 sec Caused an ERROR Server returned HTTP response code: 400 for URL: http://localhost:3596/asyncErrorServlet java.io.IOException: Server returned HTTP response code: 400 for URL: http://localhost:3596/asyncErrorServlet at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1485) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139) at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:239) at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:206) at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:200) at org.apache.catalina.core.TestAsyncContextImpl.doTestBug51197(TestAsyncContextImpl.java:1207) at org.apache.catalina.core.TestAsyncContextImpl.testBug51197b(TestAsyncContextImpl.java:1177) Caused by: java.io.IOException: Server returned HTTP response code: 400 for URL: http://localhost:3596/asyncErrorServlet at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1436) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379) at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:232) ]]] 2. I enabled access log in the test, by adding the following line to build.properties: test.accesslog=true The access log shows as if error message was sent to the client - see bytes count in the last column: [[[ 127.0.0.1 - - [20/Feb/2012:04:14:50 +0400] GET /asyncErrorServlet HTTP/1.1 400 5 http-bio-127.0.0.1-auto-32-exec-2 3985 127.0.0.1 - - [20/Feb/2012:04:14:56 +0400] GET /asyncErrorServlet HTTP/1.1 400 5 http-bio-127.0.0.1-auto-33-exec-3 4000 127.0.0.1 - - [20/Feb/2012:04:15:50 +0400] GET /asyncErrorServlet HTTP/1.1 400 5 http-nio-127.0.0.1-auto-32-exec-2 4000 127.0.0.1 - - [20/Feb/2012:04:15:56 +0400] GET /asyncErrorServlet HTTP/1.1 400 5 http-nio-127.0.0.1-auto-33-exec-3 4000 127.0.0.1 - - [20/Feb/2012:04:16:57 +0400] GET /asyncErrorServlet HTTP/1.1 400 5 http-apr-127.0.0.1-auto-32-exec-3 4000 127.0.0.1 - - [20/Feb/2012:04:17:02 +0400] GET /asyncErrorServlet HTTP/1.1 400 5 http-apr-127.0.0.1-auto-33-exec-4 4000 ]]] 3. Finally I was able to reproduce the issue. I extracted AsyncErrorServlet as a standalone class, configured a simple web application and tried to access it directly. It reproduces the issue! The response is empty. Moreover access log shows that only 5 bytes were sent to the client. [[[ 127.0.0.1 - - [20/Feb/2012:04:39:53 +0400] GET /test/asyncErrorServlet?status=404treaded=true HTTP/1.1 404 5 127.0.0.1 - - [20/Feb/2012:04:40:03 +0400] GET /test/asyncErrorServlet?status=404treaded=false HTTP/1.1 404 5 127.0.0.1 - - [20/Feb/2012:04:40:42 +0400] GET /test/asyncErrorServlet HTTP/1.1 500 1472 ]]] I converted the constructor arguments to request parameters. If I call the servlet without arguments it fails on parseInt call, and see above - it responds with proper error 500 message of 1472 bytes. I will attach the war below. 4. sendError() call as used in Comment 3 interacts with error handling. I have not tested how it behaves when there is a custom error page configured. 5. BTW, r1290875 has not been merged into 7.0.x yet. -- Configure bugmail:
DO NOT REPLY [Bug 51197] sendError/sendRedirect don't work with AsyncContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=51197 --- Comment #6 from Konstantin Kolinko knst.koli...@gmail.com 2012-02-20 01:21:48 UTC --- Created attachment 28356 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28356 test.war - Reproducer for issue in Comment 3 WAR that reproduces the issue. [[[ 127.0.0.1 - - [20/Feb/2012:04:39:53 +0400] GET /test/asyncErrorServlet?status=404treaded=true HTTP/1.1 404 5 ]]] I made a typo while testing it, it should have been s/treaded/threaded/. An odd thing is that I do not see any difference whether threaded is true or false. The request takes ~3 seconds to execute regardless of that parameter. [[[ 127.0.0.1 - - [20/Feb/2012:04:16:57 +0400] GET /asyncErrorServlet HTTP/1.1 400 5 http-apr-127.0.0.1-auto-32-exec-3 4000 127.0.0.1 - - [20/Feb/2012:04:17:02 +0400] GET /asyncErrorServlet HTTP/1.1 400 5 http-apr-127.0.0.1-auto-33-exec-4 4000 ]]] Apparently 5 above was the size. The 4000 is the timing. Why it is 4000 and not 3000 (TIMEOUT)? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: AccessLogValve enhancement
My initial motivation for doing this was in trying to figure out a way to have the logs automatically delete old ones eventually. I couldn't find a way to do it, looked at the source, and got a bit sidetracked. The rest is history On Feb 19, 2012 12:50 PM, Mark Thomas ma...@apache.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/02/2012 17:20, Christopher Schultz wrote: Mark, On 2/15/12 4:33 PM, Mark Thomas wrote: I also be +1 to considering making this the sole way AccessLogValve logging may be output. The only possible reason why we wouldn't want to do this is that lots of users simply cannot figure out how to configure the loggers. Yes, it's really not all that hard and it's fairly well-documented, but at least with the output file name in the Valve attributes, there's no question where the log messages are going. Fair point. Philosophically, I'm not really sure why the flexibility of a full-featured logging system (JULI, log4j, etc.) is required for access logging: there's not much opportunity to use all the features they provide (log level filtering, log-message aggregation to log files and log-file multiplexing/splitting). Access logs typically log one thing (accesses), log it all the time, and always write to the same log file. I'm not adverse to the patch, I just don't really see a need for it. I was coming from the I'd rather not maintain a bunch of code to solve a problem that the logging frameworks have already solved (threading, roll-over, output to multiple destinations) angle. You know me, always happy to delete some code from the Tomcat code base. My main point is that it is something worthy of discussion. And that is what we are doing. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPQTZBAAoJEBDAHFovYFnneXEQAJucbwt4zm/gTv093FuwfC0Y m6bJDiObPzaxuZNnWvaKKwM1XY4ZCGCkKV7H5xoZQIuMOnzMVm1Z/9qcuMiiuml+ UoUxAH1mZoKeyDmRxAgl7DhYYwVf3XPAnL+oI2K/XuxNRuJvehUQRm3ouxZeO81a gTKs3GYA/ZxVL0p7fJ1pPnh44xqg4ly7dDLaUx5dVZU6WJ/14pwuIwQCCLDu9C+r FvC2k/Bc13fXxrAzYuTiat83DztEMohRPXmyxVUnM4XG+eM1jMub31/4+6S9TrSt 2TX6lRmzw36khrYUKYWsmPJxsS+5rSVaaOfO5ekSUzLnuhshoAEUYe1pPzVTHd02 1a7njJuqzdKNjU4B1sfWivLXPspmhmK6pnUtmoIF98NRr1XsMe9O/4AhG7NUIpoX Ci7Nd1WygWUdn9evMxzcUhtrmkAbvcMuQ+71737Xn8OJKDzvdc0b6p6ZEgm8cHnB QHM+whU38Cb6Vy+vlyFQpwmJ8qolRrT2Ob76h22pZxm9PDQF18OWU6tqi3EabjU+ 9YV1fPPJNjrvNk9H27vaQIurrXMhX5yTZGb7PsVSinjXbq4zNEWZlcQSI5t+Pf5K 5AaRnxcptDIFcv+y9YFZv4ecqOPFHCUj03XSjRLBZd1V2vUdbkuTmpToLLo4Mwwp Rzy9If3xAw9+lSqza8hS =t+lP -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket progress report
Hi Mark, I noticed you wrote a websocket test client, I haven't looked at it extensively but I wanted to ask - have you considered using Autobahn for testing? It's rather extensive opensource websocket testing suite. It already contains a lot of stuff we need to test including fragmentation testing. On Fri, Feb 17, 2012 at 14:50, Mark Thomas ma...@apache.org wrote: On 16/02/2012 04:01, Petr Praus wrote: Hello, attached is our patch. It applies cleanly on top of current trunk rev. 1244719. It has rudimentary support for fragmentation (callback after last frame), supports close messages and ping/pong. Sorry for not sending a patchset but I thought it wouldn't really make sense, since there were quite a lot of back and forth changes. Let me know if I should send a patchset instead. The final diff is fine to work with from my point of view. (Jonathan's summary) Echoing fragments. Close messages. Pings/pongs. Just barely works. :) Fragmentation support is very limited: a mere callback when last frame received. Repeating what I already wrote in BZ on fragmentation so there is a complete set of review comments in one place I am extremely reluctant to apply the current fragmentation patch. It relies on buffering individual fragments and - given the maximum fragment size - that is simply not going to scale. This is why the current API is built on streams and does not buffer unless the message based API is used. I'd like to fully explore the possibility of supporting fragments without using buffering before starting down that path. I understand your concern, the main idea was that the logic that pertains only to a single frame and the information about the frame itself should be encapsulated there. What about letting the client code know there's a new frame before we begin reading the data but still keep the frames encapsulated in WebSocketFrame? Sends normal closing reply messages and some protocol error closes. Answers pings with pongs. The fragmentation implementation is likely to impact how this is done, so I'd like to resolve that issue first and then come back to this. Moving towards a better application API. I think I know what you mean by this but please could you explain in more detail. The servlet container is doing something I don't understand with rapid connection attempts…not sure what's up. Tell us what you observe and we might be able to explain it. I renamed StreamInbound to WebSocketConnection since it's bidirectional. This looks to be related to the refactoring. I'm more worried about design and features than I am naming right now. Also I gave the upgrade processors close() methods. That isn't how socket closure needs to be managed. You'll get away with it with BIO but things are very likely blow up (with a JVM core) when you do that with APR. You need to let the surrounding Protocol handle that by returning the correct socket state. Fixed a number of bugs, including Please enumerate all the bugs you fixed so I can ensure that part of the patch is pulled forward ASAP. a switch statement with accidentally cascading cases, That looks to be deliberate to me, although a bunch of TODOs wouldn't have hurt. This was actually a bug in my code in WebSocketFrame, it wasn't deliberate :) and a problem with in Conversions.byteArrayToLong(). Thanks. Fixed. General comment: The code style of a patch needs to be consistent with the Tomcat code style. Braces on a new line is the obvious thing that jumped out at me as I read the patch. Actually, this looks to be confined to a single class. Thanks for the comment, we'll try to keep it consistent. Yes, I know the Tomcat code base isn't internally consistent style wise. The code is 10+ years old and it shows. Use the code in the current websocket package as a basis. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-test : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on tomcat-trunk-dbcp exists, no need to add for property tomcat-dbcp-src.jar. -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -DEBUG- Dependency on tomcat-trunk-dbcp exists, no need to add for property tomcat-dbcp.home. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/build/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_work/build_tomcat-trunk_tomcat-trunk-test.html Work Name: build_tomcat-trunk_tomcat-trunk-test (Type: Build) Work ended in a state of : Failed Elapsed: 21 mins 8 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-20022012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20022012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20022012-native-src.tar.gz -Dexamples.sources.skip=true -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps -Djdt.jar=/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20022012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-src.jar -Dtest.accesslog=true -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/ srv/gump/public/workspace/commons-dbcp-1.x -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-20022012.jar test [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-trunk/outp ut/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-util.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-tr
