re: getServerPort always return 80
Hi, any other know this problem? I meet it again today. A server has an Internet IP and when nginx listen to 81，the request.getServerPort() return 80.
AW: AW: Tomcat dedicated server
Hi Chris, ah.. yes. You are right, I overlooked the available 16 GB Ram. Long time ago, when I used a physical server with 16 GB but in cloud environment, ram is money. Greetings, Thomas -Ursprüngliche Nachricht- Von: Christopher Schultz Gesendet: Donnerstag, 20. Januar 2022 13:01 An: users@tomcat.apache.org Betreff: Re: AW: Tomcat dedicated server Thomas, On 1/20/22 04:16, Thomas Hoffmann (Speed4Trade GmbH) wrote: > just one remark: Take care about the 32 GB. Configuring more than 32 GB, the > Java Pointers will use 64 Bit and thus need double the space. > Thus 34 GB memory can be worse than 31 GB. > See also > https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-me > mory-oddities/ > > Just my 2 cents. While this is indeed true (and can be surprising), it is not relevant. Nobody with 16GiB of physical memory has any business attempting to use a 32GiB heap. -chris > -Ursprüngliche Nachricht- > Von: Olaf Kock > Gesendet: Donnerstag, 20. Januar 2022 09:54 > An: users@tomcat.apache.org > Betreff: Re: Tomcat dedicated server > > Hi Lance > > On 19.01.22 23:35, Campbell, Lance wrote: >> On a Tomcat 9.x dedicated Linux server with 16G of memory, how much memory >> would you allocate for the OS? >> >> Assume there is no file processing taking place. Also assume Tomcat is >> communicating primarily with a PostgreSQL database and Apache web server >> each running on their own dedicated servers. The Tomcat application server >> is the only thing running on the Linux server. > > It depends (TM) > > Without knowing your application, the load (e.g. number of concurrent > users) and general setup, there's no way to tell. I'd rather handle > the question the other way around: How much memory does (your > application > on) Tomcat require. Tomcat itself is happy with just a little bit of memory, > but applications vary widely. Also, some applications are memory-bound, some > are I/O-bound, some are CPU-bound. So memory might not be your bottleneck to > worry about. > > You should load-test your application with a realistic load (plus > margin) and keep an eye on memory consumption. But in the end you'll find out > what is the first bottleneck to appear. It might not be memory. > > But to come back closer to your original question: I recommend to > deactivate swapspace for production servers, and configure -Xms equal > to -Xmx, so that you find shortages of memory early (when you start > the > application) rather than Sunday night at 3am. You might want to leave > 1-2G for the OS and start testing this way, or rather test how little > memory your app requires to run and add margin. My rule of thumb is: > The more memory there is to be claimed in GC, the longer a full GC run > takes. Often, many short but frequent GC runs are preferable to fewer > but longer lasting. (I didn't check if this still applies to the newer > generation of garbage collectors, so take this GC-statement with a > grain of salt) > > Olaf > > > > - > 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 > - 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
[ANN] Apache Tomcat 10.0.16 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 10.0.16. This release is targeted at Jakarta EE 9. Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without changes. Java EE applications designed for Tomcat 9 and earlier may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically convert them to Jakarta EE and copy them to the webapps directory. This conversion is performed using the Apache Tomcat migration tool for Jakarta EE tool which is also available as a separate download for off-line use. Apache Tomcat 10 is an open source software implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations specifications. The notable changes compared to 10.0.14 include: - Add recycling check in the input and output stream isReady to try to give a more informative ISE when the facade has been recycled. - Implement support for HTTP/1.1 upgrade when the request includes a body. The maximum permitted size of the body is controlled by maxSavePostSize. - Improve handling of various cases where one request/response processing thread attempts to manage the asynchronous IO for a different request/response Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-10.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-10.cgi Migration guides from Apache Tomcat 7.0.x, 8.5.x and 9.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat jdbc connections
Alan, On 1/20/22 09:33, Alan F wrote: I have an issue with connections on Tomcat9 Oracle showing connections made for about 2seconds then dropped again. Is this normal when the server is not being used? You mean like, a connection is made, no queries are executed, and then the connection is terminated? Presumably, you have an application running on Tomcat with a JDBC connection configured. Are you using Tomcat's built-in pooling, or is your application managing its own pooling/connections? Do you have any background tasks (in the JVM) that will run even when there is no user activity? Cache-management? Lazy-writes? Are you using Tomcat's clustering? Are you using a database-backed session management or any kind? Are the connections definitely being made from the application itself and/or Tomcat? Or do you just see those connections coming from the IP where the application is running? Do you have any background tasks (outside the JVM) that will run even when there are no user actions? For example, some monitoring system that pings the server to say "can you reach the database?" -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 Encrpytion of JDBC
Harri, On 1/20/22 11:37, Harri Pesonen wrote: Vault for Apache Tomcat: https://github.com/web-servers/tomcat-vault It hides the secrets in another encrypted file, and password for that file is then in another file... So it just makes it more difficult to access the secrets, but at least they are not in plain text. What this does is satisfy the following "security" requirement: [ ] Have you ensured that no credentials are stored unencrypted in Tomcat's conf/server.xml file? [X] Check! Nice job. It doesn't answer the question "do you have plaintext credentials in any configuration files" because whatever auditor is asking would give you a bad grade. As soon as that auditor learns about Vault for Apache Tomcat, they will ask: [ ] Have you ensured that no credentials are stored unencrypted in Tomcat's conf/server.xml file? [ ] Have you ensured that no credentials are stored unencrypted in Vault for Tomcat's vault-config.xml file? Then we'll get questions about whether there is a Vault for Vault for Apache Tomcat. Someone should patch VfAT so it has a new feature which is the number of configuration files it should use for encryption. So you can set it to e.g. "4" and then you get these files: vault-config.xml vault-config-1.xml vault-config-2.xml vault-config-3.xml And the -3 file contains the plaintext password used to unlock -2 which unlocks -1 which unlocks vault-config.xml. Hey, three layers of encryption! Super secure! -chris -Original Message- From: Orendt, John Sent: torstai 20. tammikuuta 2022 18.11 To: users@tomcat.apache.org Subject: RE: Tomcat 9 Encrpytion of JDBC [Et saa yleensä sähköpostia osoitteesta john.p.ore...@medtronic.com.invalid. Lue lisää siitä, miksi tämä on tärkeää, osoitteesta http://aka.ms/LearnAboutSenderIdentification.] Hi There are at least two types of mutual authentication. 1. Device Client A and Server B 2. Human A via browser and Server B All the scenarios you mention have been solved. You just need to know how. X509 certs, the chain of trust, TPMs and HSMs are some the of parts of the solution for both types. Internet Banking does exist. John Orendt john.p.ore...@medtronic.com -Original Message- From: Christopher Schultz Sent: Tuesday, January 18, 2022 11:32 AM To: users@tomcat.apache.org Subject: Re: Tomcat 9 Encrpytion of JDBC John, On 1/18/22 08:37, Orendt, John wrote: Secrets are more secure with the use of a Trusted Platform Module (TPM) and / or a Hardware Security Module (HSM). Secrets need to be protected both at rest and in transit. Sure. Where you put the password for the TPM or HSM? Or do you enter the password for your HSM/TPM every time you start a process that needs access to secrets? How do you handle unattended restarts? How do you handle massive deployments? Do you manually-enter a password on 1000 servers as they all launch together? On all these kinds of deployments, you usually use a key server. But then how do you authenticate to the key server? With another secret. It's secrets all the way down. At some point, you must trust something, and that something you trust can't be a human, because that doesn't scale or isn't practical for some other reason. I'd love to hear a practical solution to the "secret at rest" problem that actually makes some sense and doesn't just hand-wave the problem off to another component that is Somebody Else's Problem. -chris -Original Message- From: Alan F Sent: Friday, January 14, 2022 2:05 PM To: Tomcat Users List Subject: RE: Tomcat 9 Encrpytion of JDBC OK thanks Bill! -Original Message- From: Bill Stewart Sent: 14 January 2022 19:02 To: Tomcat Users List Subject: Re: Tomcat 9 Encrpytion of JDBC On Fri, Jan 14, 2022 at 10:25 AM Alan F wrote: Interested to know your best practices on securing jdbc plain text passwords, in my last place they used a mechanism to encrypt all passwords. Is this the best method as I read some people don't recommend this. Any details or procs on best practice appreciated. The "best practice," generally speaking, is that doing so is basically pointless from a security perspective. https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld efense.com%2Fv3%2F__https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisp ladata=04%7C01%7Charri.pesonen%40sinch.com%7C318adb49672e4fe13aa1 08d9dc2f9971%7C3b518aae89214a7b8497619d756ce20e%7C0%7C0%7C637782919266 275465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=mMjmECMDtbO%2Fa5ovQgdahIl aq%2FZdVBEnzoRAyy7oYQA%3Dreserved=0 y/TOMCAT/Password__;!!NFcUtLLUcw!Bhr3E8c3AZFikCj4AHarnHl2emUxh99SUwhyn Fa-FKWZahvlpv0TmiVo5DveVMgMyg3NbQ$ Bill [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or
Re: Tomcat 9 Encrpytion of JDBC
John, On 1/20/22 11:10, Orendt, John wrote: There are at least two types of mutual authentication. 1. Device Client A and Server B 2. Human A via browser and Server B All the scenarios you mention have been solved. You just need to know how. X509 certs, the chain of trust, TPMs and HSMs are some the of parts of the solution for both types. Okay, let's take X.509 certs as an example. Your server needs to sign messages sent to the client to provide authentication (to the client). For that you need the key, unencrypted. So how do you unlock the key without having the password around? Let's take TPM as another example: the key is in the TPM and it's (somewhat) tamper-proof and you can't extract it. Some software on the machine where the TPM is located asks the TPM to sign or decrypt something using the key. But how does the software authenticate to the TPM? (Hint: it doesn't). The trust is established by simple physical connection. So, let's get back to encrypting your JDBC password in your conf/server.xml file. If you encrypt that, you have to put the encryption key elsewhere. Fine, you say, I'll use a "remote key-service" where I supply an encrypted secret to the service and it returns the unencrypted password I can then use to connect to my JDBC server. Well, how do you authenticate to the key-service? Is it another physical presence thing? IP allow-listing? Whatever it is, it's almost exactly as secure as having the password right there in the file on the machine without all the hand-waving and complexity. "Oh, but if the server is stolen or data is exfiltrated then OMG what do we do?" Well, first of all, you don't allow connections to your database from random strangers: that password is only useful when used locally. So the "secret" of the password getting out isn't really a problem. Fine, rotating the password would be a good idea, but the password should be useless without that other security control: presence in a (relatively) trusted position. Internet Banking does exist. Yep, and I've never had anyone from the banking industry tell me how they protect their TLS keys in some super-secure way that uses TPMs, HSMs, and X.509 certifictes. Maybe it's a closely-guarded secret that they aren't allowed to tell anybody. If you think you have an idea that meaningfully improves security and ALSO does not rely on hand-waving to simply move the problem somewhere else, I'd love to hear it. -chris -Original Message- From: Christopher Schultz Sent: Tuesday, January 18, 2022 11:32 AM To: users@tomcat.apache.org Subject: Re: Tomcat 9 Encrpytion of JDBC John, On 1/18/22 08:37, Orendt, John wrote: Secrets are more secure with the use of a Trusted Platform Module (TPM) and / or a Hardware Security Module (HSM). Secrets need to be protected both at rest and in transit. Sure. Where you put the password for the TPM or HSM? Or do you enter the password for your HSM/TPM every time you start a process that needs access to secrets? How do you handle unattended restarts? How do you handle massive deployments? Do you manually-enter a password on 1000 servers as they all launch together? On all these kinds of deployments, you usually use a key server. But then how do you authenticate to the key server? With another secret. It's secrets all the way down. At some point, you must trust something, and that something you trust can't be a human, because that doesn't scale or isn't practical for some other reason. I'd love to hear a practical solution to the "secret at rest" problem that actually makes some sense and doesn't just hand-wave the problem off to another component that is Somebody Else's Problem. -chris -Original Message- From: Alan F Sent: Friday, January 14, 2022 2:05 PM To: Tomcat Users List Subject: RE: Tomcat 9 Encrpytion of JDBC OK thanks Bill! -Original Message- From: Bill Stewart Sent: 14 January 2022 19:02 To: Tomcat Users List Subject: Re: Tomcat 9 Encrpytion of JDBC On Fri, Jan 14, 2022 at 10:25 AM Alan F wrote: Interested to know your best practices on securing jdbc plain text passwords, in my last place they used a mechanism to encrypt all passwords. Is this the best method as I read some people don't recommend this. Any details or procs on best practice appreciated. The "best practice," generally speaking, is that doing so is basically pointless from a security perspective. https://urldefense.com/v3/__https://cwiki.apache.org/confluence/displa y/TOMCAT/Password__;!!NFcUtLLUcw!Bhr3E8c3AZFikCj4AHarnHl2emUxh99SUwhyn Fa-FKWZahvlpv0TmiVo5DveVMgMyg3NbQ$ Bill [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it
RE: Tomcat 9 Encrpytion of JDBC
Vault for Apache Tomcat: https://github.com/web-servers/tomcat-vault It hides the secrets in another encrypted file, and password for that file is then in another file... So it just makes it more difficult to access the secrets, but at least they are not in plain text. -Harri -Original Message- From: Orendt, John Sent: torstai 20. tammikuuta 2022 18.11 To: users@tomcat.apache.org Subject: RE: Tomcat 9 Encrpytion of JDBC [Et saa yleensä sähköpostia osoitteesta john.p.ore...@medtronic.com.invalid. Lue lisää siitä, miksi tämä on tärkeää, osoitteesta http://aka.ms/LearnAboutSenderIdentification.] Hi There are at least two types of mutual authentication. 1. Device Client A and Server B 2. Human A via browser and Server B All the scenarios you mention have been solved. You just need to know how. X509 certs, the chain of trust, TPMs and HSMs are some the of parts of the solution for both types. Internet Banking does exist. John Orendt john.p.ore...@medtronic.com -Original Message- From: Christopher Schultz Sent: Tuesday, January 18, 2022 11:32 AM To: users@tomcat.apache.org Subject: Re: Tomcat 9 Encrpytion of JDBC John, On 1/18/22 08:37, Orendt, John wrote: > Secrets are more secure with the use of a Trusted Platform Module > (TPM) and / or a Hardware Security Module (HSM). > > Secrets need to be protected both at rest and in transit. Sure. Where you put the password for the TPM or HSM? Or do you enter the password for your HSM/TPM every time you start a process that needs access to secrets? How do you handle unattended restarts? How do you handle massive deployments? Do you manually-enter a password on 1000 servers as they all launch together? On all these kinds of deployments, you usually use a key server. But then how do you authenticate to the key server? With another secret. It's secrets all the way down. At some point, you must trust something, and that something you trust can't be a human, because that doesn't scale or isn't practical for some other reason. I'd love to hear a practical solution to the "secret at rest" problem that actually makes some sense and doesn't just hand-wave the problem off to another component that is Somebody Else's Problem. -chris > -Original Message- > From: Alan F > Sent: Friday, January 14, 2022 2:05 PM > To: Tomcat Users List > Subject: RE: Tomcat 9 Encrpytion of JDBC > > OK thanks Bill! > > -Original Message- > From: Bill Stewart > Sent: 14 January 2022 19:02 > To: Tomcat Users List > Subject: Re: Tomcat 9 Encrpytion of JDBC > > On Fri, Jan 14, 2022 at 10:25 AM Alan F wrote: > > >> Interested to know your best practices on securing jdbc plain text >> passwords, in my last place they used a mechanism to encrypt all passwords. >> Is this the best method as I read some people don't recommend this. >> Any details or procs on best practice appreciated. >> > > The "best practice," generally speaking, is that doing so is basically > pointless from a security perspective. > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.com%2Fv3%2F__https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisp > ladata=04%7C01%7Charri.pesonen%40sinch.com%7C318adb49672e4fe13aa1 > 08d9dc2f9971%7C3b518aae89214a7b8497619d756ce20e%7C0%7C0%7C637782919266 > 275465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=mMjmECMDtbO%2Fa5ovQgdahIl > aq%2FZdVBEnzoRAyy7oYQA%3Dreserved=0 > y/TOMCAT/Password__;!!NFcUtLLUcw!Bhr3E8c3AZFikCj4AHarnHl2emUxh99SUwhyn > Fa-FKWZahvlpv0TmiVo5DveVMgMyg3NbQ$ > > Bill > [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this > email is proprietary to Medtronic and is intended for use only by the > individual or entity to which it is addressed, and may contain > information that is private, privileged, confidential or exempt from > disclosure under applicable law. If you are not the intended recipient > or it appears that this mail has been forwarded to you without proper > authority, you are notified that any use or dissemination of this > information in any manner is strictly prohibited. In such cases, > please delete this mail from your records. To view this notice in > other languages you can either select the following link or manually > copy and paste the link into the address bar of a web browser: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Femail > disclaimer.medtronic.com%2Fdata=04%7C01%7Charri.pesonen%40sinch.c > om%7C318adb49672e4fe13aa108d9dc2f9971%7C3b518aae89214a7b8497619d756ce2 > 0e%7C0%7C0%7C637782919266275465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata= > %2Fcv%2B6vRuz8ox1ipRnMTOWZxpz2%2BBKJ%2BHlfBh8iDg5m4%3Dreserved=0 > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail:
[ANN] Apache Tomcat 10.1.0-M10 (alpha) available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 10.1.0-M10 (alpha). Apache Tomcat 10 is an open source software implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations specifications. Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without changes. Java EE applications designed for Tomcat 9 and earlier may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically convert them to Jakarta EE and copy them to the webapps directory. This conversion is performed using the Apache Tomcat migration tool for Jakarta EE tool which is also available as a separate download for off-line use. Apache Tomcat 10.1.0-M10 is a milestone release of the 10.1.x branch and has been made to provide users with early access to the new features in Apache Tomcat 10.1.x so that they may provide feedback. The notable changes compared to 10.1.0-M8 include: - Add recycling check in the input and output stream isReady to try to give a more informative ISE when the facade has been recycled. - Implement support for HTTP/1.1 upgrade when the request includes a body. The maximum permitted size of the body is controlled by maxSavePostSize. - Improve handling of various cases where one request/response processing thread attempts to manage the asynchronous IO for a different request/response Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-10.1-doc/changelog.html Downloads: http://tomcat.apache.org/download-10.cgi Migration guides from Apache Tomcat 7.0.x, 8.5.x and 9.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat jdbc connections
On 20/01/2022 14:33, Alan F wrote: I have an issue with connections on Tomcat9 Oracle showing connections made for about 2seconds then dropped again. Is this normal when the server is not being used? Seems unlikely. Can you provide the DataSource configuration? Remember to obfuscate any sensitive data. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 9 Encrpytion of JDBC
Hi There are at least two types of mutual authentication. 1. Device Client A and Server B 2. Human A via browser and Server B All the scenarios you mention have been solved. You just need to know how. X509 certs, the chain of trust, TPMs and HSMs are some the of parts of the solution for both types. Internet Banking does exist. John Orendt john.p.ore...@medtronic.com -Original Message- From: Christopher Schultz Sent: Tuesday, January 18, 2022 11:32 AM To: users@tomcat.apache.org Subject: Re: Tomcat 9 Encrpytion of JDBC John, On 1/18/22 08:37, Orendt, John wrote: > Secrets are more secure with the use of a Trusted Platform Module > (TPM) and / or a Hardware Security Module (HSM). > > Secrets need to be protected both at rest and in transit. Sure. Where you put the password for the TPM or HSM? Or do you enter the password for your HSM/TPM every time you start a process that needs access to secrets? How do you handle unattended restarts? How do you handle massive deployments? Do you manually-enter a password on 1000 servers as they all launch together? On all these kinds of deployments, you usually use a key server. But then how do you authenticate to the key server? With another secret. It's secrets all the way down. At some point, you must trust something, and that something you trust can't be a human, because that doesn't scale or isn't practical for some other reason. I'd love to hear a practical solution to the "secret at rest" problem that actually makes some sense and doesn't just hand-wave the problem off to another component that is Somebody Else's Problem. -chris > -Original Message- > From: Alan F > Sent: Friday, January 14, 2022 2:05 PM > To: Tomcat Users List > Subject: RE: Tomcat 9 Encrpytion of JDBC > > OK thanks Bill! > > -Original Message- > From: Bill Stewart > Sent: 14 January 2022 19:02 > To: Tomcat Users List > Subject: Re: Tomcat 9 Encrpytion of JDBC > > On Fri, Jan 14, 2022 at 10:25 AM Alan F wrote: > > >> Interested to know your best practices on securing jdbc plain text >> passwords, in my last place they used a mechanism to encrypt all passwords. >> Is this the best method as I read some people don't recommend this. >> Any details or procs on best practice appreciated. >> > > The "best practice," generally speaking, is that doing so is basically > pointless from a security perspective. > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/displa > y/TOMCAT/Password__;!!NFcUtLLUcw!Bhr3E8c3AZFikCj4AHarnHl2emUxh99SUwhyn > Fa-FKWZahvlpv0TmiVo5DveVMgMyg3NbQ$ > > Bill > [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this > email is proprietary to Medtronic and is intended for use only by the > individual or entity to which it is addressed, and may contain > information that is private, privileged, confidential or exempt from > disclosure under applicable law. If you are not the intended recipient > or it appears that this mail has been forwarded to you without proper > authority, you are notified that any use or dissemination of this > information in any manner is strictly prohibited. In such cases, > please delete this mail from your records. To view this notice in > other languages you can either select the following link or manually > copy and paste the link into the address bar of a web browser: > http://emaildisclaimer.medtronic.com > > - > 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
[ANN] Apache Tomcat 9.0.58 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 9.0.58. Apache Tomcat 9 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and JASPIC technologies. Apache Tomcat 9.0.58 is a bugfix and feature release. The notable changes compared to 9.0.56 include: - Add recycling check in the input and output stream isReady to try to give a more informative ISE when the facade has been recycled. - Implement support for HTTP/1.1 upgrade when the request includes a body. The maximum permitted size of the body is controlled by maxSavePostSize. - Improve handling of various cases where one request/response processing thread attempts to manage the asynchronous IO for a different request/response. Along with lots of other bug fixes and improvements. Please refer to the change log for the complete list of changes: https://tomcat.apache.org/tomcat-9.0-doc/changelog.html Downloads: https://tomcat.apache.org/download-90.cgi Migration guides from Apache Tomcat 7.x and 8.x: https://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat jdbc connections
I have an issue with connections on Tomcat9 Oracle showing connections made for about 2seconds then dropped again. Is this normal when the server is not being used? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 8.5.75 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.5.75. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and Java Authentication Service Provider Interface for Containers technologies. Apache Tomcat 8.5.75 is a bugfix and feature release. (Note that Tomcat 8.5.74 was not released.) The notable changes compared to 8.5.73 include: - JmxRemoteLifecycleListener has been removed. - Provide protection against a known OS bug that causes the acceptor to report an incoming connection more than once. - Fix several potential JVM crashes when using the APR connector. - Implement a workaround for a JVM bug that can trigger a file descriptor leak when using multi-part upload and the application does not explicitly close an input stream for an uploaded file that was cached on disk. - Fix exceptions when the security manager is enabled and the first request received after starting is an HTTP request to a TLS enabled NIO2 connector. - Implement support for HTTP/1.1 upgrade when the request includes a body. The maximum permitted size of the body is controlled by maxSavePostSize. - Improve handling of various cases where one request/response processing thread attempts to manage the asynchronous IO for a different request/response. Along with lots of other bug fixes and improvements. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.5-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 7.x and 8.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dedicated server
Mark, On 1/20/22 04:18, Mark Thomas wrote: On 20/01/2022 08:54, Olaf Kock wrote: My rule of thumb is: The more memory there is to be claimed in GC, the longer a full GC run takes. Nope. The time a GC run takes is proportional to the size of objects in memory that do not need to be GC'd. GC walks the active object tree so it is the active objects that matter. Doesn't this depend upon which "space" is being cleaned? The young generations (by whatever name, depending upon the GC engine being used) work this way, but the "older" generations usually have to be "cleaned" (rather than "prompted and abandoned"). But of course, the older generations typically have far less garbage to be collected than the younger generations which have large numbers of allocations and deallocations all the time. Generally, the more memory you give the JVM to work with, the lower the impact of GC for both pauses and throughput. A rule of thumb I have seen in the past (may be out of date for current JVMs) is that the JVM needs roughly 5x the steady state memory requirements for GC to work most efficiently. That's an interesting anecdote; it seems like a very large factor to me. Something else Olaf said is worth repeating: setting -Xms and -Xmx to the same value for a server process is a good idea, otherwise the memory spaces will have to be periodically re-organized and expanded which just waste resources. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Tomcat dedicated server
Thomas, On 1/20/22 04:16, Thomas Hoffmann (Speed4Trade GmbH) wrote: just one remark: Take care about the 32 GB. Configuring more than 32 GB, the Java Pointers will use 64 Bit and thus need double the space. Thus 34 GB memory can be worse than 31 GB. See also https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-memory-oddities/ Just my 2 cents. While this is indeed true (and can be surprising), it is not relevant. Nobody with 16GiB of physical memory has any business attempting to use a 32GiB heap. -chris -Ursprüngliche Nachricht- Von: Olaf Kock Gesendet: Donnerstag, 20. Januar 2022 09:54 An: users@tomcat.apache.org Betreff: Re: Tomcat dedicated server Hi Lance On 19.01.22 23:35, Campbell, Lance wrote: On a Tomcat 9.x dedicated Linux server with 16G of memory, how much memory would you allocate for the OS? Assume there is no file processing taking place. Also assume Tomcat is communicating primarily with a PostgreSQL database and Apache web server each running on their own dedicated servers. The Tomcat application server is the only thing running on the Linux server. It depends (TM) Without knowing your application, the load (e.g. number of concurrent users) and general setup, there's no way to tell. I'd rather handle the question the other way around: How much memory does (your application on) Tomcat require. Tomcat itself is happy with just a little bit of memory, but applications vary widely. Also, some applications are memory-bound, some are I/O-bound, some are CPU-bound. So memory might not be your bottleneck to worry about. You should load-test your application with a realistic load (plus margin) and keep an eye on memory consumption. But in the end you'll find out what is the first bottleneck to appear. It might not be memory. But to come back closer to your original question: I recommend to deactivate swapspace for production servers, and configure -Xms equal to -Xmx, so that you find shortages of memory early (when you start the application) rather than Sunday night at 3am. You might want to leave 1-2G for the OS and start testing this way, or rather test how little memory your app requires to run and add margin. My rule of thumb is: The more memory there is to be claimed in GC, the longer a full GC run takes. Often, many short but frequent GC runs are preferable to fewer but longer lasting. (I didn't check if this still applies to the newer generation of garbage collectors, so take this GC-statement with a grain of salt) Olaf - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dedicated server
Lance, On 1/19/22 17:35, Campbell, Lance wrote: On a Tomcat 9.x dedicated Linux server with 16G of memory, how much memory would you allocate for the OS? Assume there is no file processing taking place. Also assume Tomcat is communicating primarily with a PostgreSQL database and Apache web server each running on their own dedicated servers. The Tomcat application server is the only thing running on the Linux server. You need to provide a lot more information. Some application servers can get away with a tiny amount of memory -- say, 64 megabytes of heap space -- and others needs many gigabytes. Are you maintaining large caches of objects? Are you handling large result sets from your database where those results need to temporarily reside in memory? Do you expect large numbers of logged-in users with HttpSession object which contain large amounts of stuff? If none of the above are true, you may not need very much of that 16GiB of RAM you have there. At $work, we run application servers which have 8GiB of physical RAM and we run 4 separate JVM+Tomcat+application instances on each of them. The application with the largest heap space is set to 640MiB. We have several hundred users logged-in on each node at any given time and we have plenty of heap space. Only *you* can tell what kind of memory requirements your application has. Usually "more is better" but sometimes, "more" just adds unnecessary costs. If you only have OS + JVM/Tomcat/application running on this machine, I would set your heap to something conservative like 8GiB and monitor the application over time: see what memory-load your users are putting on it. SAVE YOUR DATA OVER TIME! If you see a saw-tooth pattern of used-heap (which is great!), look at the minimum value of that sawtooth pattern over time and that's essentially the minimum memory you need. Whatever you add on top of that gives you room to expand to more concurrent users, or handle larger temporary memory-usage scenarios, such as collating a large data set in memory (instead of having the database do it for you, for example). Hope that helps, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dedicated server
Hi Mark On 20.01.22 10:18, Mark Thomas wrote: > On 20/01/2022 08:54, Olaf Kock wrote: > >> My rule of thumb is: The >> more memory there is to be claimed in GC, the longer a full GC run >> takes. > > Nope. > > The time a GC run takes is proportional to the size of objects in > memory that do not need to be GC'd. GC walks the active object tree so > it is the active objects that matter. > > Generally, the more memory you give the JVM to work with, the lower > the impact of GC for both pauses and throughput. > > A rule of thumb I have seen in the past (may be out of date for > current JVMs) is that the JVM needs roughly 5x the steady state memory > requirements for GC to work most efficiently. > Thank you for setting my ancient rule of thumb straight - noted and mentally corrected, this is really useful. Obviously, the last time that I needed to squeeze the last bit of performance out of a machine is so old that I never needed to revert that ancient rule of thumb - now I have a cause to do so. @Lance: I take it back and claim the opposite :) Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dedicated server
On 20/01/2022 08:54, Olaf Kock wrote: My rule of thumb is: The more memory there is to be claimed in GC, the longer a full GC run takes. Nope. The time a GC run takes is proportional to the size of objects in memory that do not need to be GC'd. GC walks the active object tree so it is the active objects that matter. Generally, the more memory you give the JVM to work with, the lower the impact of GC for both pauses and throughput. A rule of thumb I have seen in the past (may be out of date for current JVMs) is that the JVM needs roughly 5x the steady state memory requirements for GC to work most efficiently. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Tomcat dedicated server
Hello Lance, just one remark: Take care about the 32 GB. Configuring more than 32 GB, the Java Pointers will use 64 Bit and thus need double the space. Thus 34 GB memory can be worse than 31 GB. See also https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-memory-oddities/ Just my 2 cents. Greetings, Thomas -Ursprüngliche Nachricht- Von: Olaf Kock Gesendet: Donnerstag, 20. Januar 2022 09:54 An: users@tomcat.apache.org Betreff: Re: Tomcat dedicated server Hi Lance On 19.01.22 23:35, Campbell, Lance wrote: > On a Tomcat 9.x dedicated Linux server with 16G of memory, how much memory > would you allocate for the OS? > > Assume there is no file processing taking place. Also assume Tomcat is > communicating primarily with a PostgreSQL database and Apache web server each > running on their own dedicated servers. The Tomcat application server is the > only thing running on the Linux server. It depends (TM) Without knowing your application, the load (e.g. number of concurrent users) and general setup, there's no way to tell. I'd rather handle the question the other way around: How much memory does (your application on) Tomcat require. Tomcat itself is happy with just a little bit of memory, but applications vary widely. Also, some applications are memory-bound, some are I/O-bound, some are CPU-bound. So memory might not be your bottleneck to worry about. You should load-test your application with a realistic load (plus margin) and keep an eye on memory consumption. But in the end you'll find out what is the first bottleneck to appear. It might not be memory. But to come back closer to your original question: I recommend to deactivate swapspace for production servers, and configure -Xms equal to -Xmx, so that you find shortages of memory early (when you start the application) rather than Sunday night at 3am. You might want to leave 1-2G for the OS and start testing this way, or rather test how little memory your app requires to run and add margin. My rule of thumb is: The more memory there is to be claimed in GC, the longer a full GC run takes. Often, many short but frequent GC runs are preferable to fewer but longer lasting. (I didn't check if this still applies to the newer generation of garbage collectors, so take this GC-statement with a grain of salt) Olaf - 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
Re: Tomcat dedicated server
Hi Lance On 19.01.22 23:35, Campbell, Lance wrote: > On a Tomcat 9.x dedicated Linux server with 16G of memory, how much memory > would you allocate for the OS? > > Assume there is no file processing taking place. Also assume Tomcat is > communicating primarily with a PostgreSQL database and Apache web server each > running on their own dedicated servers. The Tomcat application server is the > only thing running on the Linux server. It depends (TM) Without knowing your application, the load (e.g. number of concurrent users) and general setup, there's no way to tell. I'd rather handle the question the other way around: How much memory does (your application on) Tomcat require. Tomcat itself is happy with just a little bit of memory, but applications vary widely. Also, some applications are memory-bound, some are I/O-bound, some are CPU-bound. So memory might not be your bottleneck to worry about. You should load-test your application with a realistic load (plus margin) and keep an eye on memory consumption. But in the end you'll find out what is the first bottleneck to appear. It might not be memory. But to come back closer to your original question: I recommend to deactivate swapspace for production servers, and configure -Xms equal to -Xmx, so that you find shortages of memory early (when you start the application) rather than Sunday night at 3am. You might want to leave 1-2G for the OS and start testing this way, or rather test how little memory your app requires to run and add margin. My rule of thumb is: The more memory there is to be claimed in GC, the longer a full GC run takes. Often, many short but frequent GC runs are preferable to fewer but longer lasting. (I didn't check if this still applies to the newer generation of garbage collectors, so take this GC-statement with a grain of salt) Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
