Re: AT WITS END regarding JVM arguments
Seems to me that a paraphrase of the third paragraph quoted above ought to be added -- PROMINENTLY -- to the comment lines at the top of catalina.bat and catalina.sh, to keep midrange jocks like me from driving ourselves nuts trying to manipulate services the wrong way. On 9/1/16, 3:52 PM, André Warnier (tomcat) wrote: Maybe reading this would have helped : http://wiki.apache.org/tomcat/FAQ/Windows#Q11 (I wrote that, at a time just after when I was just as puzzled as you are about these curious Windows thingies..) Thanks. It definitely helps explain what these things are, but I think the prominent notice I suggested for the preambles of the catalina.bat and catalina.sh procedure files would be better at alerting those who aren't WinDoze service jocks that for a WinDoze service installation, a setenv.bat or a setenv.sh (or any modification of existing *.bat or *.sh) would be a monumental waste of time and a source of potentially lethal (or at least insanity-inducing) levels of frustration. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AT WITS END regarding JVM arguments
On 01.09.2016 22:30, James H. H. Lampert wrote: On 9/1/16, 12:14 PM, Olaf Kock wrote: if I'm remembering correctly, parameters for services are stored somewhere in the registry. Instead of poking there, you should use the tomcatw.exe executable which parameterizes the service. I hope that memory serves me right - it's been a long time since I last touched windows. Last time I saw it, it spawned a dialog with proper input fields for anything you might want to configure. setenv.bat would be used if you start through startup.bat or catalina.bat - but is not touched by a service, as a service doesn't use the batch files at all. Thanks. Your memory serves both of us quite well. Seems to me that a paraphrase of the third paragraph quoted above ought to be added -- PROMINENTLY -- to the comment lines at the top of catalina.bat and catalina.sh, to keep midrange jocks like me from driving ourselves nuts trying to manipulate services the wrong way. Maybe reading this would have helped : http://wiki.apache.org/tomcat/FAQ/Windows#Q11 (I wrote that, at a time just after when I was just as puzzled as you are about these curious Windows thingies..) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AT WITS END regarding JVM arguments
On 9/1/16, 12:14 PM, Olaf Kock wrote: if I'm remembering correctly, parameters for services are stored somewhere in the registry. Instead of poking there, you should use the tomcatw.exe executable which parameterizes the service. I hope that memory serves me right - it's been a long time since I last touched windows. Last time I saw it, it spawned a dialog with proper input fields for anything you might want to configure. setenv.bat would be used if you start through startup.bat or catalina.bat - but is not touched by a service, as a service doesn't use the batch files at all. Thanks. Your memory serves both of us quite well. Seems to me that a paraphrase of the third paragraph quoted above ought to be added -- PROMINENTLY -- to the comment lines at the top of catalina.bat and catalina.sh, to keep midrange jocks like me from driving ourselves nuts trying to manipulate services the wrong way. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AT WITS END regarding JVM arguments
James, On 9/1/2016 11:36 AM, James H. H. Lampert wrote: > Ladies and Gentlemen: > > One of our Tomcat servers (refreshed from > apache-tomcat-7.0.67-windows-x86.zip) is running AS A SERVICE on a > Windows box. > > And we need to set JVM Options of > -Djavax.servlet.request.encoding=UTF-8 > -Dfile.encoding=UTF-8 > -Djava.awt.headless=true > > Unlike IBM Midrange boxes, on which I can, with a simple OS command, > list all the JVMs currently running on the system, and look up the > arguments, environment variables, system properties, &c, I can't find > any way to verify the JVM arguments (this box has only a JRE, not a > JDK), other than what gets sent to the log file. I even tried installing > a trial of JProfiler, but if checking arguments is in there, it's > well-hidden! > > I just tried adding a "setenv.bat" to the "bin" directory, containing > >> SET CATALINA_OPTS=-Djava.awt.headless=true >> -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 > > and after stopping and starting the service, even after rebooting the > Windows box, "headless" cannot be found in the log file, and neither can > I find "UTF." > > WHAT COULD BE GOING WRONG HERE? > > -- > JHHL I'm not a Windows person, but here's how I did it: 1. Do a normal installation of Tomcat with service.bat service.bat install 2. Start up the Windows monitor service tomcat7w.exe 3. Navigate to the Java tab 4. Select the Java Options: window 5. Add your additional requirements 1 per line: -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 -Djava.awt.headless=true 6. Start Tomcat 7. Observe logs in %CATALINA_BASE%\logs tomcat7-stderr.2016-09-01.log INFO: Command line argument: -Djavax.servlet.request.encoding=UTF-8 INFO: Command line argument: -Dfile.encoding=UTF-8 INFO: Command line argument: -Djava.awt.headless=true Now you could probably add these with tomcat7 //US//Tomcat7 with the suitable ++JvmOptions arguments, but it looks like it replaces the original ++JvmOptions. That means you'd have to duplicate the original options (see service.bat) as well as add the above three options. tomcat7w.exe seems easier, but if you're doing unattended installations modifying service.bat (or creating your own tomcat7.exe command line) might be easier. See the following: https://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html as a reference. . . . just my two cents /mde/ signature.asc Description: OpenPGP digital signature
[CsrfPreventionFilter] Adding base app URL as an entryPoint
I want to have my landing page be accessible without using a nonce but right now I'm getting a 403. I do have a separate login page that works without a nonce. The pertinent section of my web.xml is as follows: entryPoints /, /login.jsp, /JS/MIST.js I also tried "/*" without success. I saw another config using just "/" but I don't know if that person's config was successful - at least I believe my line of thinking is similar to others. Appreciative of any useful help... - Joe
Re: AT WITS END regarding JVM arguments
Am 01.09.2016 um 20:36 schrieb James H. H. Lampert: > ... > I just tried adding a "setenv.bat" to the "bin" directory, containing > >> SET CATALINA_OPTS=-Djava.awt.headless=true >> -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 > > and after stopping and starting the service, even after rebooting the > Windows box, "headless" cannot be found in the log file, and neither > can I find "UTF." Hi James, if I'm remembering correctly, parameters for services are stored somewhere in the registry. Instead of poking there, you should use the tomcatw.exe executable which parameterizes the service. I hope that memory serves me right - it's been a long time since I last touched windows. Last time I saw it, it spawned a dialog with proper input fields for anything you might want to configure. setenv.bat would be used if you start through startup.bat or catalina.bat - but is not touched by a service, as a service doesn't use the batch files at all. Best, Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AT WITS END regarding JVM arguments
Hi James, On Thu, Sep 1, 2016 at 2:36 PM, James H. H. Lampert < jam...@touchtonecorp.com> wrote: > Ladies and Gentlemen: > > One of our Tomcat servers (refreshed from > apache-tomcat-7.0.67-windows-x86.zip) > is running AS A SERVICE on a Windows box. > > And we need to set JVM Options of > -Djavax.servlet.request.encoding=UTF-8 > -Dfile.encoding=UTF-8 > -Djava.awt.headless=true > > Unlike IBM Midrange boxes, on which I can, with a simple OS command, list > all the JVMs currently running on the system, and look up the arguments, > environment variables, system properties, &c, I can't find any way to > verify the JVM arguments (this box has only a JRE, not a JDK), other than > what gets sent to the log file. I even tried installing a trial of > JProfiler, but if checking arguments is in there, it's well-hidden! > > I just tried adding a "setenv.bat" to the "bin" directory, containing > > SET CATALINA_OPTS=-Djava.awt.headless=true > -Djavax.servlet.request.encoding=UTF-8 >> -Dfile.encoding=UTF-8 >> > > and after stopping and starting the service, even after rebooting the > Windows box, "headless" cannot be found in the log file, and neither can I > find "UTF." > > WHAT COULD BE GOING WRONG HERE? > > -- > JHHL > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > I don't run Tomcat on Windows so there might be a typo in this line here but in your setenv.bat have you tried something like: SET JAVA_OPTS="%JAVA_OPTS% -Djava.awt.headless=true -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8" instead of using CATALINA_OPTS? We use JAVA_OPTS in our setenv.sh file for Linux, perhaps it will work for Windows as well ... - Jim
AT WITS END regarding JVM arguments
Ladies and Gentlemen: One of our Tomcat servers (refreshed from apache-tomcat-7.0.67-windows-x86.zip) is running AS A SERVICE on a Windows box. And we need to set JVM Options of -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 -Djava.awt.headless=true Unlike IBM Midrange boxes, on which I can, with a simple OS command, list all the JVMs currently running on the system, and look up the arguments, environment variables, system properties, &c, I can't find any way to verify the JVM arguments (this box has only a JRE, not a JDK), other than what gets sent to the log file. I even tried installing a trial of JProfiler, but if checking arguments is in there, it's well-hidden! I just tried adding a "setenv.bat" to the "bin" directory, containing SET CATALINA_OPTS=-Djava.awt.headless=true -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 and after stopping and starting the service, even after rebooting the Windows box, "headless" cannot be found in the log file, and neither can I find "UTF." WHAT COULD BE GOING WRONG HERE? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cookie-related regression in Tomcat 8.5?
I found the problem, and you're right that the cookie was failing validation. The app was prepending a dot to the domain name so that the cookie would affect both the domain and all subdomains. I understand that it's no longer necessary to prepend the dot, and removing the prepended dot fixes the problem. However, this does seem to be a difference in the behavior of Tomcat 8.0 and 8.5, It should probably be mentioned in https://tomcat.apache.org/migration-85.html. On Mon, Aug 29, 2016 at 2:35 AM, Mark Thomas wrote: > On 29/08/2016 03:09, Mike Wertheim wrote: > > I took a look using the LiveHttpHeaders Chrome extension. > > > > It's very simple. Tomcat 8.0.33 is setting the Set-Cookie header in the > > response, and Tomcat 8.5.4 is not setting the Set-Cookie header in the > > response. > > Check the logs for errors. I suspect the cookie isn't being sent because > it is failing validation. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
AW: AW: TCNative 1.2.8 with openssl 1.1.0
Chris, > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Mark, > > On 8/31/16 7:21 AM, Mark Thomas wrote: > > On 31/08/2016 12:18, Kreuser, Peter wrote: > >> > >> Christopher, > >> > >>> On 8/30/16 10:18 AM, Kreuser, Peter wrote: > >>> > >>> On 30/08/2016 10:23, Kreuser, Peter wrote: > >>> > >>> Hi all, > >>> > >>> I have compiled tcnative 1.2.8 with the new openssl 1.1.0 (ldd > >>> proves that it is linked). I have set the cipher string to the > >>> newly supported ciphers: > >>> > >>> ciphers="ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:E > C > >>> > >>> > >> > >> testssl.sh is running with an openssl 1.0.2 compiled with > >> CHACHA20-support. > >> > >> I tried to manually access the website with this version and > >> ECDHE-ECDSA-CHACHA20-POLY1305 without success. > > > > Don't you need a DSA cert to use that cipher? > > Yep. It's used for authentication only -- EDCHE is of course being > used for key exchange. > > Nice catch. Peter, this isn't working because this cipher suite can't > be used with your RSA certificate: you'll need a DSA cert. > as send to Mark before, ECDHE-RSA-CHACHA20-POLY1305 isn't working either. Plus testssl.sh is trying all ciphers no matter if key exchange is DSA or RSA. See: Testing all 181 locally available ciphers against the server, ordered by encryption strength Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (RFC) --- xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 256 AESGCM256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc028 ECDHE-RSA-AES256-SHA384 ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA x9f DHE-RSA-AES256-GCM-SHA384 DH 2048AESGCM256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 x6b DHE-RSA-AES256-SHA256 DH 2048AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 x39 DHE-RSA-AES256-SHADH 2048AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA x9d AES256-GCM-SHA384 RSAAESGCM256 TLS_RSA_WITH_AES_256_GCM_SHA384 x3d AES256-SHA256 RSAAES 256 TLS_RSA_WITH_AES_256_CBC_SHA256 x35 AES256-SHARSAAES 256 TLS_RSA_WITH_AES_256_CBC_SHA xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 256 AESGCM128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 xc027 ECDHE-RSA-AES128-SHA256 ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 xc013 ECDHE-RSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA x9e DHE-RSA-AES128-GCM-SHA256 DH 2048AESGCM128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 x67 DHE-RSA-AES128-SHA256 DH 2048AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 x33 DHE-RSA-AES128-SHADH 2048AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA x9c AES128-GCM-SHA256 RSAAESGCM128 TLS_RSA_WITH_AES_128_GCM_SHA256 x3c AES128-SHA256 RSAAES 128 TLS_RSA_WITH_AES_128_CBC_SHA256 x2f AES128-SHARSAAES 128 TLS_RSA_WITH_AES_128_CBC_SHA Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [SOLVED] mod_jk/1.2.37 Apache/2.4.7 (Ubuntu): AJP established connections pile up, connection_pool_timeout has no effect?
>From: Hildegard Meier [mailto:daku8...@gmx.de] >Sent: Thursday, September 01, 2016 10:14 AM >To: users@tomcat.apache.org >Subject: [SOLVED] mod_jk/1.2.37 Apache/2.4.7 (Ubuntu): AJP established >connections pile up, connection_pool_timeout has >no effect? > >Dear Guido, > >many thanks for Your answer. many thanks for your feedback, too. > >It looks, like the parameter reply_timeout=180 was the solution. I added >that parameter yesterday and was not sure if >that would help and since I go to vacation in short time, I asked in this list >in parallel to maybe solve the problem before >vacation in another way. >[...] >Why the backend applications so often do not give any response, I think is >another issue for the developers. > >But maybe the importance of changing the reply_timeout parameter from default >value "infinit" to a even very high value of >30 min should be stated even more prominent in the worker documentation. I set this even lower (to 120s) because it's said it's the timeout for reading of each packet and no application on the Tomcat should take so much time to send any part of an answers. I might be of worth if you pass the URIs of the dangling requests to developers. Because not finished, they are not logged. But you may take a look on the scoreboards of the Apache or the Tomcat. On Tomcat, it available via an MBean, you may read out it via JMX or via the http-proxy of the Tomcat Manager application. I may send you a script as a pointer, if you like. Guido
Re: ClientAbortException / IOException occurs only when using HttpServletResponseWrapper
On 01/09/2016 08:09, Mark Thomas wrote: On 31 August 2016 13:22:34 BST, Olivier Jaquemet wrote: Hi all, We are encountering a weird but frequent exception when users try to access AVI video playback on IE11. My analysis is that it's a bad behavior of Tomcat when using HttpServletResponseWrapper. I did not want to immediately create a bug report, first because you might have other insight on the subject, and also because the bug affects all tomcat version, thus I wanted to be sure on the appropriate way to report. Indeed the bug report page (https://tomcat.apache.org/bugreport.html) does not explain what to do if bugs affect several version of Tomcat. Only enter bug for the latest version ? Enter bug serval time ? Or maybe there is a way to select multiple product at once ? Open one bug against the earliest affected version. Patches, if any, are most useful if against trunk. I have setup a very simple reproduction webapp (2 nearly empty class, one html, one video) that can be downloaded here : https://www.dropbox.com/s/q61obn8381hugug/test.war?dl=0 (204.72 KB) This webapp is configured with a simple servlet filter, doing nothing special but wrapping the response using a simple HttpServletResponseWrapper (not doing anything at all) and logging request information on exception. To help demonstrate the cause of the problem, the filter expose an init parameter "wrap-response" in web.xml which quickly allows the webapp to be tested with 2 behavior : response wrapped (to exhibit the bug) or not (to behave properly). The home page contains a video player with a very small AVI file. The reproduction steps : * Start Tomcat (any version) with the webapp above * Access the index page using IE 11 on Windows 7 (very important : clear browser cache between each test) --> The exception at the end of this message occurs. * Edit web.xml, set "wrap-response" init parameter to false * Repeat the test with IE (don't forget to clear cache!) --> No exception. The problem may be workaround by modifying Tomcat's web.xml by disabling Accept-Ranges support. useAcceptRanges false Because the ClientAbortException/IOException does not occurs if the response is not wrapped, and does not occurs either if acceptRange is disabled, it really make me think that is a bug in Tomcat (and not a behavior of the client contrary to what ClientAbortException implies). Hmm. The dependence on range support makes me want to double check what the filter is doing. There was an issue with filters, range support and the default servlet several years back. I need to remind myself of the details. Bug verified to exist in all following version (with a default install) (using JDK 1.8.0_102-b14 on Win7 SP1): Apache Tomcat/7.0.70 Apache Tomcat/8.0.36 Apache Tomcat/8.5.4 Apache Tomcat/9.0.0.M9 ** Should I fill the bug report? and if so, on which product should I report the bug ? ** Yes. Against 7.0.x unless 6.0.x is affected as well. I plan to look at this once the current set of releases is complete unless someone else beats me to it. Mark I could verify that the bug also exists in 6.0.45, thus I have entered the following bug report : https://bz.apache.org/bugzilla/show_bug.cgi?id=60076 Thank you Mark. Thanks for your help, Olivier The exception : org.apache.catalina.connector.ClientAbortException: java.io.IOException: Une connexion établie a été abandonnée par un logiciel de votre ordinateur hôte at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:396) at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:344) at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:421) at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:409) at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:97) at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:90) at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:961) at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:398) at javax.servlet.http.HttpServlet.service(HttpServlet.java:622) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at com.example.BasicFilter.doFilter(BasicFilter.java:37) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache
[SOLVED] mod_jk/1.2.37 Apache/2.4.7 (Ubuntu): AJP established connections pile up, connection_pool_timeout has no effect?
Dear Guido, many thanks for Your answer. It looks, like the parameter reply_timeout=180 was the solution. I added that parameter yesterday and was not sure if that would help and since I go to vacation in short time, I asked in this list in parallel to maybe solve the problem before vacation in another way. The documentation for reply_timeout (https://tomcat.apache.org/connectors-doc/reference/workers.html) says "By default (value zero) the webserver will wait forever which could be an issue for you." and it looks, like this really was an issue for us. It looks to me, like the JBoss backends do not give any reply to ajp requests sometimes(often?) and they are then kept established forever and pile up. They are not interpreted as idle, and therefore they do not get removed by JkWatchDog. Why the backend applications so often do not give any response, I think is another issue for the developers. But maybe the importance of changing the reply_timeout parameter from default value "infinit" to a even very high value of 30 min should be stated even more prominent in the worker documentation. > you wrote, you're using the worker MPM. What are the pool sizes for child > workers and it's threads, i.e. the values for ServerLimit, ThreadsPerChild? > And what's the minimum thread pool size, i.e. MinSpareThreads? /etc/apache2/mods-enabled/mpm_worker.conf StartServers2 MinSpareThreads25 MaxSpareThreads75 ThreadLimit64 ThreadsPerChild35 MaxRequestWorkers 560 MaxConnectionsPerChild 1 > But even if the number of connections is unexpected high -- this will not > consome more memory time by time after establishing. I don't know, but I started investigating the Apache because it nearly run out of RAM some days ago, as Nagios informed. And the RAM usage of Apache clearly correlates with the count of AJP connections, as the Nagios graphs show. Now, with connection pool cleanup working since yesterday, the count of AJP connections is radical lower then before, and also the RAM usage is radical lower in parallel :-) Many thanks again, and best regards, Hilde - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
