Re: Form based auth does not provide the option to show error reason in the error page

2021-10-15 Thread Christopher Schultz

Werner,

On 10/15/21 09:10, Werner Dähn wrote:

Thanks Mark. Why do you believe the refactoring is difficult? All we
actually need is access to the response object.


... which requires a lot of refactoring. Have a look at all the code 
that handles authentication in Tomcat.


This would allow to add session data, URL parameters, whatever. And 
this response object is available everywhere except in the actual 
RealmBase. By my analysis the change would be rather simple and 
provide a feedback channel. If that feedback channel is used and for 
what, is a separate discussion and decided by the real implementer.
What you really want is the request object, not the response. You can't 
set attributes on the response, but the request has that, plus it has 
all kinds of other juicy information such as the user's IP address (to 
be used for per-user IP-based access-checks), secondary authentication 
information in the form of (previously-set) request attributes and/or 
request parameters.


I'm 100% in favor of adding the request to the whole authentication 
ecosystem. Correct me if I'm wrong, markt, but I think the whole idea of 
JASPIC was to allow essentially arbitrary, pluggable front-ends *and* 
back-ends into the authentication system. If that's the case, I'd love 
to know how to take a vanilla FORM username+password configuration using 
FormAuthenticator + DataSourceRealm and make it work using whatever 
JASPIC magic needs to be configured just to do the same work. 
Presumably, it's not terribly difficult from there to introduce things 
like "also pass the request" through all that from front-end to back-end.



https://bz.apache.org/bugzilla/show_bug.cgi?id=65635


-chris


On Fri, Oct 15, 2021 at 2:01 PM Mark Thomas  wrote:


On 15/10/2021 07:05, Werner Dähn wrote:




So why has this not been done? What am I missing?


Accepted security good practice is not to provide any information to a
user as to the reason for a failed authentication. The idea is that it
could help an attacker by, for example, letting them know they have a
valid user name but an invalid password.

I'm not entirely convinced by the arguments used to support the above
position. They generally seem to be based on the assumption that a brute
force attack is possible. I'd argue that any system susceptible to a
brute force attack has problems irrespective of whether it provides
feedback on authentication failures.

I do think there is an argument to be made that trading reduced
usability (no feedback on authentication failures) for allegedly better
security (brute force attacks are harder) is not a sensible trade-off.
That said, I appear to be in the minority. Again.


Does an enhancement request exist??


No.

I do think there is an argument for providing information on the reason
for the authentication failure via a mechanism that allows system
administrators to decide if they want to pass it on to the users or not.
Something like a request attribute that could be included in a custom
error page for example.

However, the current Tomcat code for authentication is structured in
such a way that exposing the reason for an authentication failure would
require a reasonable amount of refactoring. I don't think an enhancement
request along these lines will be rejected, but neither do I think it
will be implemented quickly. I'd expect a fair amount of discussion
about how to refactor the Realm interface to expose this information.

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



Re: Tomcat 9.0.x JDBC connection pool does not always remove abandoned connections

2021-10-14 Thread Christopher Schultz

Gerhardt,

On 10/12/21 13:27, Martin, Gerhardt A wrote:

Running Tomcat 9.0.50 on Centos 7.9.x Linux and using Tomcat JDBC connection 
pool to connect to my application's databases. My app connects to about a dozen 
read only databases and one read/write database. Here is a typical resource 
definition with tuning configurations for the pool and the MSSQL server JDBC 
driver:



Note that these are the only relevant attributes:

> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"

You are using tomcat-pool, not the default commons-dbcp.


maxActive="20"
initialSize="1"
maxIdle="8"
minIdle="1"
maxWait="5000"
testOnBorrow="false" 
testWhileIdle="false" 
testOnConnect="false" 
testOnReturn="false" 
timeBetweenEvictionRunsMillis="1"

removeAbandonedTimeout="15"
removeAbandoned="true"
logAbandoned="false"
minEvictableIdleTimeMillis="90"
maxAge="60"





Important NOTE: the framework we employ does NOT execute more than one SQL statement 
per borrow from the connection pool. It's a constant cycle of getConnection(borrow) 
->execute 1 SQL->closeConnection(return)


That's kind of wasteful, but okay.


Why are we configured this way:
Ultimately we need to fail fast to avoid our APP going into death by stuck 
threads when we lose connectivity to the backend databases for a short period 
of time. ( for example a short 10 second period where the DB(s) is/are 
unreachable from the app servers).


Is this common?


-We want the evictor thread (Pool Cleaner) to run every 10 seconds
-We are only using the Pool Cleaner to clobber busy connections that have been 
running 15 seconds or more
   NOTE: we rarely see SQL that takes longer than 2 seconds, most are sub 100ms 
and the avg is about 4ms


Note that the connections aren't clobbered; they are simply dropped from 
the pool. The work they generated is still continuing...



-We are not testing connections period
-We want our connections replaced with new fresh connections after 10 mins of 
use hence we set maxAge=60
The connection pool settings work hand in hand with properties set on the SQL 
server JDBC driver in the URL:
The driver will kill any SQL that takes longer than 10 seconds


Ouch.


-When everything else is OK, then the connection itself is returned intact back 
to the connection pool
-When the DB is unreachable, there is another timer cancelQueryTimeout set to 
10 seconds which is a safety valve for cases where the message to the DB server 
to cancel the SQL gracefully does not make it to the DB. After the
cancleQueryTimeout, the client side of the driver gives up. This is problematic 
because it actually returns a bad connection back to the connection pool.

The combination of the connection pool settings to run the Pool cleaner every 
10 seconds and removeAbandoned of 15 seconds should work together to remove any 
connection whose SQL execution time went past 10 seconds before the 
cancelQueryTimeout kicks in. This should prevent returning bad connections to 
the pool when bad things happen like a network switch going offline temporarily 
and dropping all packets between the app server hosting tomcat and the database 
server.


Sounds like you really just want to be validating connections, but you 
have explicitly disabled that feature. Why?



NOTE that for the MSSQL server driver all their timeouts default to wait indefinitely. 
This is one of the prime reasons why even short outages can kill our APP with stuck 
threads. Our Web app hits tomcat about 2000 requests per minute and each request is going 
to fire on AVG ~6 SQL statements so we are running about 12K SQL hits per minute. If we 
lose connectivity to a database for even 15 seconds without a means to fail fast we could 
easily overcome the allotted number of threads which will create a "log jam" 
that can take a very long time to recover.


Why doesn't your query-timeout handle this situation?


So I am very sorry for all this lenghty background but I thought it might help 
for readers and potential responders to know a bit about why we do what we do 
in our connection pool.

Finally now onto the problem:

I was running a load test and simulating the temporary loss of connectivity to one or 
more of the databases used in the APP and I noticed a strange behavior that does not 
align with my understanding of how Tomcat JDBC removeAbandoned works. While most of my 
database connections coming from the pool did die shortly after the simulation started 
and "failed fast" there were a few connections that actually ran for up to 5 
minutes before they terminated themselves. Given the configuration I explained I would 
have expected no database connection that was interacting with the database to live 
beyond 30 seconds. ( giving that there could be some forward/reverse lag in the evictor 
thread timing where there could be a slight chance that the first run of the evictor 
thread might not catch every connection that was at the 15 seconds mark.)


Remember that the pool won't 

Re: Missing TLS cipher suite definition

2021-10-11 Thread Christopher Schultz

Mark,

On 10/10/21 13:47, Mark Thomas wrote:

On 10/10/2021 13:00, Christopher Schultz wrote:

On 10/9/21 04:52, Mark Thomas wrote:




If the user is using e.g. BouncyCastle, IBM's JRE, Corretto, etc. 
those ciphers might be available in those environments. (It looks like 
BC supports this cipher suite, but I couldn't find any information on 
IBM or Corretto stating one way or the other).


We have supported cipher lists from at least some of those in the
test suite checking for missing mappings. There is always the scope
to [add] additional supported cipher lists from other JVMs and/or
JSSE providers.

+1

Will them being missing from the Ciphers enum prevent them from being 
used at all? OR will it only prevent them from being aliases of each 
other?


Looking at the source, my reading is a cipher needs to be in Ciphers to 
used.


I'll note that in that case it is a DSA based cipher suite so I'd be 
surprised to find it in use in a production scenario.


It's ECDSA, which is what you'd naturally be using if you were to be 
using EC keys. Not everyone uses RSA, though it still has most of the 
market-share. Let's Encrypt will use ECDSA if requested.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Missing TLS cipher suite definition

2021-10-10 Thread Christopher Schultz

Mark,

On 10/9/21 04:52, Mark Thomas wrote:

On 08/10/2021 19:34, Farber, Ilja wrote:

Hi all,

I noticed org.apache.tomcat.util.net.openssl.ciphers.Cipher does not 
define the cipher suites defined by rfc 6367 and 6209. The ciphers are 
listed

https://docs.oracle.com/javase/9/docs/specs/security/standard-names.html

and should be valid for TLS 1.2.



For example TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256


The above cipher is 0xC05C and is present in Ciphers.


or TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256


The above cipher is 0xC086. As far as I am aware it is neither supported 
by Java nor OpenSSL hence it is not present in Ciphers.



Is there a reason, why these cipher suites are not in enum Cipher?


The purpose of the Enum is to map between Java cipher definitions and 
OpenSSL cipher definitions. If a cipher is unsupported by both there is 
no point including it.


There are Tomcat unit tests that should check for unknown ciphers so I'd 
expect any new ciphers to trigger test failures. We do see these from 
time to time as OpenSSL adjusts its ciphers so I think they are working 
correctly.


If you are aware of a cipher that is supported by any current version of 
Java or OpenSSL that is missing from Ciphers and isn't triggering a test 
failure then please bring it to our attention.


If the user is using e.g. BouncyCastle, IBM's JRE, Corretto, etc. those 
ciphers might be available in those environments. (It looks like BC 
supports this cipher suite, but I couldn't find any information on IBM 
or Corretto stating one way or the other).


Will them being missing from the Ciphers enum prevent them from being 
used at all? OR will it only prevent them from being aliases of each other?


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



[ANN] Apache Tomcat 8.5.72 available

2021-10-10 Thread Christopher Schultz

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.72.

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.72 is a bugfix and feature release. The notable 
changes compared to 8.5.71 include:


- Fix an issue that caused some Servlet non-blocking API reads of the
HTTP request body to incorrectly use blocking IO

- Further robustness improvements to HTTP/2 flow control window management

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: [OT] Specifying a Custom Authenticator Class

2021-10-07 Thread Christopher Schultz

Jerry,

On 10/6/21 15:09, Jerry Malcolm wrote:
Chris, thanks so much.  But please bear with me.  I'm in the slow 
group I think I have a pretty good handle on creating the 
authenticator.  But take me from the top, using manager as an example. 
In the web.xml file it has login auth-method set to BASIC.  I'm assuming 
that invokes BasicAuthenticator.  But I don't see a value configured in 
any  context file for BasicAuthenticator unless I'm just missing it.


You didn't miss it. If there are no Valves configured for the 
application (in META-INF/context.xml), then Tomcat will use the 
 from WEB-INF/web.xml to choose the right one to use. Since 
you have BASIC in there, Tomcat automatically (and silently) adds 
BasicAuthentiator to the Manager web application.



If I wanted to change manager to use my authenticator, would I need
to change web.xml's auth-method to "malcolm"?
No, you can leave this BASIC, or remove it entirely. It doesn't really 
matter.


I figured I would change the 
web.xml auth-method and then change the default BasicAuthenicator value 
to my own authenticator valve.  But I can't find it.  Do I add this 
context/valve to the host definition in server.xml, to the 
/conf/context.xml, to the Catalina default-context.xml or does it 
matter?  Sorry I'm not getting it.  I've been with TC for many years. 
But this is an area I've never dealt with until now.


Yep, just add a  to your META-INF/context.xml which specifies 
your custom authenticator as the class name.


Hope that helps,
-chris


On 10/5/2021 1:54 PM, Christopher Schultz wrote:

Jerry,

On 10/5/21 12:23, Jerry Malcolm wrote:

hi Chris, thanks for the feedback.

I'm not using JWTs.  I'm just sending a base64 token made up of 
"a:b:c:d:e".   I don't mind cloning the BasicAuthenticator if that's 
what's required.  I'm still not understanding how TC will handle my 
modified header.


It won't. You'll have to do that yourself.

I assume that if TC finds an Authorization header with the word 
Basic, it will route to the standard BasicAuthenticator class. 


If that's been configured, yes.

What would I do in order to tell TC if it finds an auth header with 
the word "Malcolm" as the prefix instead of "Basic" that it should 
route to my custom Authenticator class?


You'd have to install your own Authenticator (a Valve) in your 
. markt posted how to do this on 10/2 in this thread.


You can look at how the BasicAuthenticator does things to orient 
yourself. Feel free to extend BasicAuthenticator and override whatever 
you need. Ultimately, it will need to do whatever you need it to do 
and then set a Principal on the request (and/or session). Again, 
looking at the BasicAuthenticator source will help a lot.


-chris


On 10/5/2021 9:50 AM, Christopher Schultz wrote:

Jerry,

On 10/4/21 22:40, Jerry Malcolm wrote:
I really don't care whether it's called Basic, Malcolm, 
RollYourOwn, or whatever.  I was just emulating techniques I've had 
to implement as a client for credit card gateways and other 
services in the past that all use BASIC prefix with their own token 
definition.  I can easily rename the Authorization  header prefix 
or not even call the header "Authorization".  The main thing is 
there is a base64 token associated with it.  Our application has a 
mobile app with a rather large REST api.  The security requirements 
of this product far exceed id:pw authentication.  We have 
additional pre-shared keys, timestamps, and other undisclosed data 
built into the raw token that is converted to base64 and added to 
the header. This REST api authentication is implemented and working 
without problems.


Here's the situation.  There is a certain amount of user data that 
is not yet displayable in the current version of the mobile app. We 
have a couple of links to the main web site where the user can view 
the remainder of their data.  I don't want to throw up a login 
screen when a user, who is already logged into the app, clicks the 
link to view the data that is on the web site.  But I also want to 
maintain the same level of security as we have with REST to 
establish the session.  The server already knows how to 
authenticate from the REST api tokens.  I simply want to use the 
same token and the same auth code to "login" the user and create a 
session just like I can do with request.login( id, pw ), but using 
my own authentication code from the auth header token.


Sounds like you are using JWTs.

Something that Tomcat doesn't currently allow you to do (because 
it's not supported by the Servlet Spec) is just shove a Principal 
into the container and say "here you go".


This would be immensely helpful for any kind of SSO mechanism. I 
have build 3 different SSO mechanisms into my product, and I can do 
it because I'm not using Tomcat's container-provided authentication. 
I would really REALLY like to get away from what I'm using and back 
into more &qu

Re: [OT] Specifying a Custom Authenticator Class

2021-10-05 Thread Christopher Schultz

Jerry,

On 10/5/21 12:23, Jerry Malcolm wrote:

hi Chris, thanks for the feedback.

I'm not using JWTs.  I'm just sending a base64 token made up of 
"a:b:c:d:e".   I don't mind cloning the BasicAuthenticator if that's 
what's required.  I'm still not understanding how TC will handle my 
modified header.


It won't. You'll have to do that yourself.

I assume that if TC finds an Authorization header with 
the word Basic, it will route to the standard BasicAuthenticator class. 


If that's been configured, yes.

What would I do in order to tell TC if it finds an auth header with the 
word "Malcolm" as the prefix instead of "Basic" that it should route to 
my custom Authenticator class?


You'd have to install your own Authenticator (a Valve) in your 
. markt posted how to do this on 10/2 in this thread.


You can look at how the BasicAuthenticator does things to orient 
yourself. Feel free to extend BasicAuthenticator and override whatever 
you need. Ultimately, it will need to do whatever you need it to do and 
then set a Principal on the request (and/or session). Again, looking at 
the BasicAuthenticator source will help a lot.


-chris


On 10/5/2021 9:50 AM, Christopher Schultz wrote:

Jerry,

On 10/4/21 22:40, Jerry Malcolm wrote:
I really don't care whether it's called Basic, Malcolm, RollYourOwn, 
or whatever.  I was just emulating techniques I've had to implement 
as a client for credit card gateways and other services in the past 
that all use BASIC prefix with their own token definition.  I can 
easily rename the Authorization  header prefix or not even call the 
header "Authorization".  The main thing is there is a base64 token 
associated with it.  Our application has a mobile app with a rather 
large REST api.  The security requirements of this product far exceed 
id:pw authentication.  We have additional pre-shared keys, 
timestamps, and other undisclosed data built into the raw token that 
is converted to base64 and added to the header.  This REST api 
authentication is implemented and working without problems.


Here's the situation.  There is a certain amount of user data that is 
not yet displayable in the current version of the mobile app.  We 
have a couple of links to the main web site where the user can view 
the remainder of their data.  I don't want to throw up a login screen 
when a user, who is already logged into the app, clicks the link to 
view the data that is on the web site.  But I also want to maintain 
the same level of security as we have with REST to establish the 
session.  The server already knows how to authenticate from the REST 
api tokens.  I simply want to use the same token and the same auth 
code to "login" the user and create a session just like I can do with 
request.login( id, pw ), but using my own authentication code from 
the auth header token.


Sounds like you are using JWTs.

Something that Tomcat doesn't currently allow you to do (because it's 
not supported by the Servlet Spec) is just shove a Principal into the 
container and say "here you go".


This would be immensely helpful for any kind of SSO mechanism. I have 
build 3 different SSO mechanisms into my product, and I can do it 
because I'm not using Tomcat's container-provided authentication. I 
would really REALLY like to get away from what I'm using and back into 
more "mainstream" principal management.


I think I'll bring this onto the dev@ mailing list because I've been 
waiting far too long to make this move.


An earlier post suggested I just implement a CredentialHandler, which 
would be great.  But it looked like the credential handler is given 
"id/pw" extracted from the base64.  Or will it actually return 
whatever it finds in the base64 token?  "A:B:C:D:E:F" instead of 
"id:pw"?   If it does just return the base64 decoded string, that 
would definitely make it much simpler to implement, but then that 
would still require I use "Basic" as the prefix in order for all of 
the normal tomcat auth header processing to work to send to my custom 
credential handler, correct?  I realize that renaming the header 
prefix to "Malcolm" or whatever would be  more architecturally pure. 
But how much more code is involved to get the same result if my 
authorization header prefix is now "Malcolm" instead of "Basic"?


If your Authorization header isn't formatted like this, then you can 
forget using the BasicAuthenticator without modification:


Authorization: base64(stuff + ":" + more stuff)

If you use a CredentialHandler, you'll only get the password and 
whatever is in the user-database as the "password" for the matching 
user. You won't get the actual username in the CredentialHandler.


But if your header is formatted enough like HTTP Basic and you can 
match input-password (or whatever) against the stored credential 
without the userna

Re: [OT] Specifying a Custom Authenticator Class

2021-10-05 Thread Christopher Schultz

Jerry,

On 10/4/21 22:40, Jerry Malcolm wrote:
I really don't care whether it's called Basic, Malcolm, RollYourOwn, or 
whatever.  I was just emulating techniques I've had to implement as a 
client for credit card gateways and other services in the past that all 
use BASIC prefix with their own token definition.  I can easily rename 
the Authorization  header prefix or not even call the header 
"Authorization".  The main thing is there is a base64 token associated 
with it.  Our application has a mobile app with a rather large REST 
api.  The security requirements of this product far exceed id:pw 
authentication.  We have additional pre-shared keys, timestamps, and 
other undisclosed data built into the raw token that is converted to 
base64 and added to the header.  This REST api authentication is 
implemented and working without problems.


Here's the situation.  There is a certain amount of user data that is 
not yet displayable in the current version of the mobile app.  We have a 
couple of links to the main web site where the user can view the 
remainder of their data.  I don't want to throw up a login screen when a 
user, who is already logged into the app, clicks the link to view the 
data that is on the web site.  But I also want to maintain the same 
level of security as we have with REST to establish the session.  The 
server already knows how to authenticate from the REST api tokens.  I 
simply want to use the same token and the same auth code to "login" the 
user and create a session just like I can do with request.login( id, pw 
), but using my own authentication code from the auth header token.


Sounds like you are using JWTs.

Something that Tomcat doesn't currently allow you to do (because it's 
not supported by the Servlet Spec) is just shove a Principal into the 
container and say "here you go".


This would be immensely helpful for any kind of SSO mechanism. I have 
build 3 different SSO mechanisms into my product, and I can do it 
because I'm not using Tomcat's container-provided authentication. I 
would really REALLY like to get away from what I'm using and back into 
more "mainstream" principal management.


I think I'll bring this onto the dev@ mailing list because I've been 
waiting far too long to make this move.


An earlier post suggested I just implement a CredentialHandler, which 
would be great.  But it looked like the credential handler is given 
"id/pw" extracted from the base64.  Or will it actually return whatever 
it finds in the base64 token?  "A:B:C:D:E:F" instead of "id:pw"?   If it 
does just return the base64 decoded string, that would definitely make 
it much simpler to implement, but then that would still require I use 
"Basic" as the prefix in order for all of the normal tomcat auth header 
processing to work to send to my custom credential handler, correct?  I 
realize that renaming the header prefix to "Malcolm" or whatever would 
be  more architecturally pure.  But how much more code is involved to 
get the same result if my authorization header prefix is now "Malcolm" 
instead of "Basic"?


If your Authorization header isn't formatted like this, then you can 
forget using the BasicAuthenticator without modification:


Authorization: base64(stuff + ":" + more stuff)

If you use a CredentialHandler, you'll only get the password and 
whatever is in the user-database as the "password" for the matching 
user. You won't get the actual username in the CredentialHandler.


But if your header is formatted enough like HTTP Basic and you can match 
input-password (or whatever) against the stored credential without the 
username, then maybe you can get away with only a CredentialHandler.


-chris


On 10/4/2021 8:49 AM, Christopher Schultz wrote:

Michael,

On 10/3/21 11:58, Michael Osipov wrote:

Am 2021-10-02 um 02:48 schrieb Jerry Malcolm:
I need to write a custom BasicAuthenticator class to decode a 
specialized encoding of the authToken.  I have been scouring google 
for info.  I found one post where the answer included the statement:


This would clearly violate Basic auth scheme and the according RFC. I 
highly recommend against. Don't abuse Basic. Create your own 
scheme/header and solve your problem with it.


This is a very good point.

Instead of:

Authorization: Basic [base64stuff]

Using "Bearer" might be a better choice, though that is also covered 
by a specific RFC and might be confusing to overload that token 
("Bearer") for another purpose.


You could just do:

Authorization: Malcolms [token]

If you are going to write a custom authenticator, anyway. You'll need 
to have a custom client, of course, but you will already have that 
kind of thing because no standard HTTP client would format your 
authentication tokens in this way.


Another dumb question: why use your own custom stuff instead of the 
st

Re: Specifying a Custom Authenticator Class

2021-10-05 Thread Christopher Schultz

Mark,

On 10/5/21 04:46, Mark Thomas wrote:

On 05/10/2021 03:40, Jerry Malcolm wrote:
An earlier post suggested I just implement a CredentialHandler, which 
would be great.  But it looked like the credential handler is given 
"id/pw" extracted from the base64.  Or will it actually return 
whatever it finds in the base64 token?  "A:B:C:D:E:F" instead of "id:pw"?


CredentialHandler only gets passed the password.



Yes, but if the (base64-decoded) token from the user looks like:

username:a:b:c:d:e

Then the credential handler will get "a:b:c:d:e" as the "password".

I realize that renaming the header prefix to "Malcolm" or whatever 
would be  more architecturally pure.  But how much more code is 
involved to get the same result if my authorization header prefix is 
now "Malcolm" instead of "Basic"?


Probably not that much. Looking at Tomcat's BasicAuthenticator you'd 
have to override most of it to do this anyway so I'd probably copy it as 
the starting point and then edit it.


+1

-chris


On 10/4/2021 8:49 AM, Christopher Schultz wrote:

Michael,

On 10/3/21 11:58, Michael Osipov wrote:

Am 2021-10-02 um 02:48 schrieb Jerry Malcolm:
I need to write a custom BasicAuthenticator class to decode a 
specialized encoding of the authToken.  I have been scouring google 
for info.  I found one post where the answer included the statement:


This would clearly violate Basic auth scheme and the according RFC. 
I highly recommend against. Don't abuse Basic. Create your own 
scheme/header and solve your problem with it.


This is a very good point.

Instead of:

Authorization: Basic [base64stuff]

Using "Bearer" might be a better choice, though that is also covered 
by a specific RFC and might be confusing to overload that token 
("Bearer") for another purpose.


You could just do:

Authorization: Malcolms [token]

If you are going to write a custom authenticator, anyway. You'll need 
to have a custom client, of course, but you will already have that 
kind of thing because no standard HTTP client would format your 
authentication tokens in this way.


Another dumb question: why use your own custom stuff instead of the 
standard(s)?


-chris

-
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



Re: Specifying a Custom Authenticator Class

2021-10-04 Thread Christopher Schultz

Michael,

On 10/3/21 11:58, Michael Osipov wrote:

Am 2021-10-02 um 02:48 schrieb Jerry Malcolm:
I need to write a custom BasicAuthenticator class to decode a 
specialized encoding of the authToken.  I have been scouring google 
for info.  I found one post where the answer included the statement:


This would clearly violate Basic auth scheme and the according RFC. I 
highly recommend against. Don't abuse Basic. Create your own 
scheme/header and solve your problem with it.


This is a very good point.

Instead of:

Authorization: Basic [base64stuff]

Using "Bearer" might be a better choice, though that is also covered by 
a specific RFC and might be confusing to overload that token ("Bearer") 
for another purpose.


You could just do:

Authorization: Malcolms [token]

If you are going to write a custom authenticator, anyway. You'll need to 
have a custom client, of course, but you will already have that kind of 
thing because no standard HTTP client would format your authentication 
tokens in this way.


Another dumb question: why use your own custom stuff instead of the 
standard(s)?


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Specifying a Custom Authenticator Class

2021-10-03 Thread Christopher Schultz

Jerry,

On 10/1/21 20:48, Jerry Malcolm wrote:
I need to write a custom BasicAuthenticator class to decode a 
specialized encoding of the authToken.  I have been scouring google for 
info.  I found one post where the answer included the statement:


"Extending from AuthenticatorBase is a great idea, and you can avoid 
Tomcat's standard authenticator by configuring your authenticator as a 
in your application's META-INF/context.xml file."


That is  precisely what I want to do. But I cannot find any 
documentation on how to configure a different authenticator class in a 
context.xml file.  I'm sure I'm just missing it, or I'm using totally 
incorrect words in the googe searches to find it.


Can someone please point me to the documentation for this?


How is your header value different from typical HTTP Basic?

You may be able to get away with an implementation of the 
CredentiaHandler instead of the Authenticator.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: manager best practice

2021-10-01 Thread Christopher Schultz

Greg,

On 9/28/21 06:52, Greg Huber wrote:

Hello,

Are there any best practice notes for the manager app?

eg, if include the app in webapps I get a context on my site, do I 
create a long name for the folder (the url) to hide it?


eg folder called reallylongmanager1234567890

so I get http://xxx.site/reallylongmanager1234567890

Or is there a better way?


Hiding the name is just security-by-obscurity. But in this case, it's a 
useful one if you want to go through the effort. No script kiddie is 
going to scan the internet for host/reallylongmanager1234567890, they'll 
try host/manager and, getting a 404, will move-on to others.


At $work, we enable the RemoteAddrValve and make sure it only allows 
connections from localhost. It turns out this is the default these days, 
so I may adjust my build process to stop doing that explicitly. We also 
require authentication so local miscreants, if they exist, can't mess 
with our applications. Well, at least non-root miscreants. ;)


We also run everything through a reverse proxy (httpd) and only map our 
"real" web applications from the outside world into the back-end Tomcat 
notes. This is the real protection: you can't get to our manager from 
the outside world at all.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: tomcat presentations on ApacheCon 2021

2021-10-01 Thread Christopher Schultz

Mark,

On 9/27/21 16:21, Mark Thomas wrote:

On 27/09/2021 20:27, Усманов Азат Анварович wrote:


Hi everyone! Does anybody know where/when to find the  
video/audio/slides (if any) from the last weeks's tomcat track on 
ApacheCon 2021?Because I completely missed it last week.
  I'm assuming all of these would be added to tomcat presentations 
page http://tomcat.apache.org/presentations.html or  
https://www.youtube.com/c/ApacheTomcatOfficial/videos at some point in 
time.I'm in no rush , just wanna make sure  I haven't missed anything 
which could be useful on a  daily basis. Especialy considering the 
fact that  I've had a few aha ("I wish I'd knew this earlier") type  
moments after watching  tomcat presentations before.


The conference team has a few hundred videos to process. They should 
start to appear over the next few weeks. Mine was pretty much the same 
as the one from ApacheCon Asia which is already available.


+1

Also the team who processes those videos are all at another conference 
this week, so nothing has yet been done for ApacheCon.


I'm the track chair, and I'll be helping to get the Tomcat-related talks 
up on YouTube as soon as possible.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: How can I set the version of sessionId cookie which tomcat send to the client to 0?

2021-10-01 Thread Christopher Schultz

Kuang Neu,

On 9/25/21 04:48, Yi Kuang Niu wrote:

As is known,when the client accesses the server, the server will create a 
session and send the sessionId (in the form of cookie) to the client.But these 
days,I met a problem.I found the IE11 browser doesn’t support cookie if the 
cookie version is 1.In client side,every time a new request is sent to the 
server,tomcat will always set a new sessionId as cookie.But when I simulate 
manually as tomcat to send the sessionId(cookie version is 0) to client in 
IE11,the session works well,and the problem above didn't exist.Therefore,how 
can I set the configuration of tomcat to ensure it will always send the version 
0 cookie of sessionId to client?
I would be much grateful if you could help me solve this problem.Looking 
forward to hearing from you!


Could this be your issue?

https://stackoverflow.com/a/3470/276232

If not, maybe you can give us some more information?

- Tomcat version
- Contents of cookie which is ignored
- URL you are trying to access (specifically, protocol and whether the 
hostname matches any domain that might be a part of the cookie)


I'm using Tomcat 8.5 and I don't get a v1 cookie. I get:

Set-Cookie JSESSIONID=[id]; Path=/context; HttpOnly; SameSite=Lax

I have manually set SameSite=Lax due to my own requirements. No version. 
No domain. Nothing funny.


Does anybody really use MSIE 11?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Supported signature algorithms in Tomcat 8.5

2021-09-24 Thread Christopher Schultz

Sreevidya,

On 9/23/21 22:11, Mandava, Sreevidya wrote:

Attached my certs.


Details for your certificates:

rsatestca:
Certificate type: RSA 2048-bit
Signature algorithm: sha256WithRSAEncryption

This is a self-signed certificate.

ecdsatestclient:
Certificate type: EC curve=prime256v1
Signature algorithm: sha256WithRSAEncryption

So yes, you are indeed using an EC key with an RSA signature. Uncommon, 
but certainly not impossible.


The error message they were getting were "unsupported signature 
algorithm ecdsa_sha1". Unfortunately don't have the logs and can't

paste the actual client cert. I only have a packet capture during the
failure and I was comparing tomcat logs from successful case and the
packet capture from failure case. I noticed that the only difference
is when the tomcat is requesting for client certificate it is sending
list of acceptable/supported certificate types and signature
algorithms. I am trying to understand where tomcat gets those values
from? We don't enable/disable any signature algorithms  in our
java.security or java.policy files or in Catalina.policy files. The
only place we specify any ciphers is in our connector
(connector.txt). How does tomcat determine what to send as an
acceptable/supported certificate type or signature algorithm?
I don't see any ECDSA_SHA1 in use in the certs themselves. Perhaps the 
problem is some algorithm chosen at runtime? ECDSA_SHA1 might be chosen 
as a part of the cipher suite chosen by the server.


What version of Java are you using?

Here is your connector (minus some irrelevant info):



Are you using the "rsatestca" certificate for your server, or something 
else? You have only enabled RSA cipher suites. I'm not sure what that 
will do when you have a mixed-key-type certificate chain for the 
client-certificate.


Is there any particular reason why you are using RSA for the CA and EC 
for the client-cert?


-chris


-Original Message-----
From: Christopher Schultz 
Sent: Wednesday, September 22, 2021 6:16 PM
To: users@tomcat.apache.org
Subject: {EXTERNAL} Re: Supported signature algorithms in Tomcat 8.5

CAUTION: The message originated from an EXTERNAL SOURCE. Please use caution 
when opening attachments, clicking links or responding to this email.



Sreevidya,

On 9/22/21 12:25, Mandava, Sreevidya wrote:

Tomcat version : 8.5.70

Attached my self -signed client cert(ecdsatestclient.crt_txt), self
signed CA (rsatestca_original.crt_txt)output from openssl
(defaultciphersuite.txt) my connector configuration(connector.txt)


Your attachment has been stripped. Please copy/paste your certificate in 
PEM-encoded-DER format (i.e. -BEGIN CERTIFICATE-) into the body of your 
post.


Problem: We have a client that is connecting to tomcat with an ECC
cert signed by a RSA signer.


That would be a very odd configuration indeed.


Client authentication is enabled in tomcat. They are seeing handshake
failures in ClientKeyExchange/Certificate Verify stage.

Do you have a specific error message and/or stack trace?


Why is there difference between the "certificate types" and "signature
algorithms"? Where/how  does tomcat get the values for "certificate
types" and "supported signature algorithms"?

Certificate types are usually "RSA" or "EC" (or maybe "DSA") and sometimes just, 
generically, X.509. Signature algorithms are typically things like "sha256withRSAencryption", etc.

Having the certificate itself would be very helpful in trying to debug this 
issue.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the 
use of the intended recipient and may contain information that is privileged, 
confidential or exempt from disclosure under applicable law. If you are not the 
intended recipient, any disclosure, distribution or other use of this e-mail 
message or attachments is prohibited. If you have received this e-mail message 
in error, please delete and notify the sender immediately. Thank you.



-
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: Supported signature algorithms in Tomcat 8.5

2021-09-22 Thread Christopher Schultz

Sreevidya,

On 9/22/21 12:25, Mandava, Sreevidya wrote:

Tomcat version : 8.5.70

Attached my self -signed client cert(ecdsatestclient.crt_txt), self 
signed CA (rsatestca_original.crt_txt)output from openssl 
(defaultciphersuite.txt) my connector configuration(connector.txt)


Your attachment has been stripped. Please copy/paste your certificate in 
PEM-encoded-DER format (i.e. -BEGIN CERTIFICATE-) into the body 
of your post.


Problem: We have a client that is connecting to tomcat with an ECC cert 
signed by a RSA signer.


That would be a very odd configuration indeed.


Client authentication is enabled in tomcat. They are seeing handshake
failures in ClientKeyExchange/Certificate Verify stage.

Do you have a specific error message and/or stack trace?


Why is there difference between the “certificate types” and
“signature algorithms”? Where/how  does tomcat get the values for
“certificate types” and “supported signature algorithms”?
Certificate types are usually "RSA" or "EC" (or maybe "DSA") and 
sometimes just, generically, X.509. Signature algorithms are typically 
things like "sha256withRSAencryption", etc.


Having the certificate itself would be very helpful in trying to debug 
this issue.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat SSL - Issue

2021-09-22 Thread Christopher Schultz

Niranjan,

On 9/21/21 19:23, Niranjan Babu Bommu wrote:

Another way you get supported is TLS and the cipher suite.

nmap -sV --script ssl-enum-ciphers -p  

nmap -sV --script ssl-enum-ciphers -p  


nmap is great, but it won't tell you what your Java client's 
capabilities are.


-chris


On Tue, Sep 21, 2021 at 5:25 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Priyanka,

On 9/21/21 13:52, Kumawat, Priyanka wrote:

Hello Team ,

Please find the error details as below -

The site can’t provide a secure connection .

xmotam01.phl.com uses an unsupported protocol

ERR_SSL_VERSION or CIPHER MISMATCH

Unsupported protocol – The client and server don;t support a common
protocol version.


Many versions of Java 1.7 do not support TLSv1.2. Try running this tool
under your Java 1.7 environment for some good information:

https://github.com/ChristopherSchultz/ssltest

-chris

-
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 9.0 async read becomes blocking

2021-09-21 Thread Christopher Schultz

Andrew,

On 9/21/21 13:54, Javateck wrote:

Hi,

With NIO connector with Servlet 3.1 support, I’m registering with a 
ReadListener, while it got the first read signal from tomcat container (I tried 
9.0.19 and 9.0.53), the read call is blocked after isReady returns true

   if (ServletInputStream.isReady()) {
ServletInputStream.read(buffer);  // this becomes blocking
   }

I tried with jetty, it’s working fine

When I did the test, I was holding the sending packet from client side

Not sure whether anyone has tried this


InputStream is always blocking.

Are you trying to use async? That's not the way to use async...

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat SSL - Issue

2021-09-21 Thread Christopher Schultz

Priyanka,

On 9/21/21 13:52, Kumawat, Priyanka wrote:

Hello Team ,

Please find the error details as below -

The site can’t provide a secure connection .

xmotam01.phl.com uses an unsupported protocol

ERR_SSL_VERSION or CIPHER MISMATCH

Unsupported protocol – The client and server don;t support a common 
protocol version.


Many versions of Java 1.7 do not support TLSv1.2. Try running this tool 
under your Java 1.7 environment for some good information:


https://github.com/ChristopherSchultz/ssltest

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



ApacheCon 2021 @Home Kicks off today 13:00 UTC

2021-09-21 Thread Christopher Schultz

All,

ApacheCon @Home starts today at 13:00 UTC (15 minutes from now, as I 
write this). Please join us for opening keynotes followed by the Apache 
Tomcat presentation track featuring the following topics:


- Apache Tomcat: New and Upcoming
- HTTP/2, HTTP/3, and TLS Start of the Art in our Servers (httpd, ATS, 
Tomcat)

- Enabling FIPS for Tomcat
- Proxying to Tomcat with httpd
- Debugging complex issues in web applications
- Tomcat: From a Cluster to a Cloud
- Apache Tomcat: Enabling Scripting Languages in JSP

Plus join us at the Apache Tomcat BoF ("Birds-of-a-Feather") after the 
sessions end to meet other community members and committers, ask 
questions, etc.


See you there.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: JASPIC AuthConfigProvider packaged with the web application not found

2021-09-18 Thread Christopher Schultz

Bernd,

On 9/17/21 03:52, Bernd Schatz wrote:

Hi Matthias,


Am 17.09.21 um 09:39 schrieb bernd.sch...@daimler.com:

From: "Keil, Matthias (ORISA Software GmbH)" 
To: users@tomcat.apache.org 
Subject: JASPIC AuthConfigProvider packaged with the web application 
not found


I would like to develop an AuthConfigProvider and would like to deploy 
it together in a web application.


The Tomcat 9 configuration reference for the AuthConfigProvider 
indicates that "The implementation may be packaged with the web 
application or in Tomcat's $ CATALINA_BASE / lib directory."


The variant with the $ CATALINA_BASE / lib directory works as 
expected. My class of the AuthConfigProvider is found and instantiated.
The variant of packing the implementation together with the web 
application does not work. In this case I get a 
java.lang.ClassNotFoundException.

[SNIP]

You can register it by using a ServletContextListener (or via CDI):

AuthConfigFactory factory = AuthConfigFactory.getFactory();
factory.registerConfigProvider(new AuthProvider(), "HttpServlet", null, 
"TEST");


Don't forget to:

private String configRegistrationId;

public void contextInitialized(...) {
  AuthConfigFactory factory = AuthConfigFactory.getFactory();
  configRegistrationId = factory.registerConfigProvider(new 
AuthProvider(), "HttpServlet", null,  "TEST");

}

public void contextDestroyed(...) {
  if(null != configRegistrationId) {

AuthConfigFactory.getFactory().removeRegistration(configRegistrationId);
  }
}

... or you will introduce a memory leak.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



ApacheCon 2021 @Home is Next Week!

2021-09-17 Thread Christopher Schultz

All,

ApacheCon is coming back to your living room / bed room / home office 
next week, Tuesday - Thursday, mostly centered on the US-Eastern time zone.


There is *zero cost* to attend the conference.

https://www.apachecon.com/acah2021/

The Tomcat track is only happening on Tuesday, including a Tomcat BoF[1] 
following the day's scheduled-tracks. We hope you'll join us for any or 
all of the conference.


-chris

[1] "Birds of a Feather", a free-form meeting/discussion about virtually 
any topic


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: #tomcat on Freenode?

2021-09-15 Thread Christopher Schultz

Coty,

On 9/15/21 10:08, Coty Sutherland wrote:

Hi all,

It's been quite a while now and all of the communities that I'm a part of
have moved from Freenode to Libera.Chat at this point. I can't even access
Freenode now without jumping through some hoops to get new credentials, so
I'm definitely not doing that. Some users in #tomcat on libera.chat have
pointed out that we still reference Freenode from our project page even
though none of us are there anymore. Should we just remove the irc page at
this point? Or do we want to update it to point to libera.chat? If there
are no objections, I'll just update the reference.



+1 to updating the reference to point to Libra.Chat.

-chris


On Tue, May 25, 2021 at 9:19 AM Coty Sutherland  wrote:


On Thu, May 20, 2021 at 1:03 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Coty,

On 5/19/21 15:28, Coty Sutherland wrote:

Hi all,

I was just notified about some mess going on with Freenode which has
seemingly resulted in a mass exodus of users from the freenode servers.


I read about this last night and I immediately thought "I wonder if Coty
will say anything about this." :)



lol, of course :P



It's an "interesting" situation, for some values of "interesting."

We (well, Coty) maintains a presence on #freenode because it appears to
help some people. Probably a very small number of people (relatively
speaking). Removing that resource may cause some people to fail to get
help. OTOH, we don't maintain a presence on fb, AIM, or Parler and we
prefer the mailing list for most interactions for a whole host of reasons.



I wasn't exactly proposing that we remove the resource, just that in light
of all the people migrating away from freenode and the likelihood that the
Fedora community will do the same, I won't be available there going forward
(I really only started hanging out on freenode because the Fedora community
communicates there a lot). And since I was basically the only committer
hanging around, I didn't think it was worth keeping a reference on the
project page which makes it look as if the channel was an 'official' place
to get help. I'm equally as OK leaving it, but since I was the only person
paying it any attention I thought it was worth asking how others thought :)



I don't think there are any people who are using #freenode because they
don't trust the ASF infrastructure. I think they just want to use IRC.
(Which, for those who are unfamiliar, is like Slack but without all the
stupid cat photos.) #freenode was great because you didn't have to pay
The Man to run an IRC channel/server for you and you also didn't have to
run it yourself. It was a nice, shared infrastructure. All of that still
exists. It's just got a bad taste to it because something that was free
and grassroots is now owned by a corporation and Corporations Are Bad
m'kay.

If we want to provide support via IRC, there is nothing wrong with
#freenode in spite of recent events, IMHO.

I think the question should be "is a realtime support system appropriate
for our community?" I tend to think not, but I'm not the only one here.



I wouldn't call what is being provided in #tomcat on freenode "realtime
support" haha There's maybe one question a month there on average (at least
when I'm online during the week), and sometimes they even go unanswered
depending on who is available at the time.



If we are going to "quit" #freenode, should we put our efforts into
pointing people to the mailing list(s) instead of pointing them to
another competing platform? I think we should funnel people to the
mailing lists. If the mailing list has too high a bar, then I guess we
can point them to Slack. (Does Slack require an account? Requiring
signup sucks. At least subscribing to a mailing list doesn't mean you
need another entry in your password safe.)

Anyhow, I'd love to hear what others think. But I would suggest that you
consider your motivations before doing anything. Specifically:

1. Why abandon #freenode?

2. Why move to anything other than mailing-list?



I agree, we should drive everyone to mailing lists but not everyone likes
them so having a few options is good for the community IMO. Also, we aren't
really abandoning anything because we don't really maintain it, it's led by
community folk as far as I know; I'm not a moderator. I was just suggesting
that if it's not a resource we're actively maintaining that we maybe
shouldn't point to it from the project page.



-chris

-
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] Tomcat 8.5.71 Released

2021-09-14 Thread Christopher Schultz

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.71.

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.71 is a bugfix and feature release. The notable 
changes compared to 8.5.70 include:


- Add a UserDatabase implementation as a superset of the DataSourceRealm
   functionality.

- Update the internal fork of Apache Commons DBCP to 2.9.0, Apache
   Commons Pool to 2.9.1, Apache Commons FileUpload to 2.0, and
   Apache Commons Codec to 1.16.

- Update the packaged version of the Tomcat Native Library to 1.2.31 to
   pick up Windows binaries built with OpenSSL 1.1.1l.

- Correct parsing of Content-Range headers

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: FW: 403 Errors for REST Web Services after upgrade from 8.5.30 to 8.5.58

2021-09-14 Thread Christopher Schultz

Mike,

On 9/13/21 10:56, Mike Webb wrote:

I manage a web application that uses REST Web Services.  After upgrading from 
8.5.30 to 8.5.58, the web services return 403 messages.

Commenting out the  and  sections below allows 
the web services to run again, but it does remove the security constraints.  How can I get 
it working securely again?



admin
readonly
user

CN=ISSWA-MyWebsiteName-Admin,OU=ISSWA-AppRoles,OU=WebApps,OU=Corporate 
Information Services,OU=cp,OU=Services,DC=mywebsitename,DC=com

CN=ISSWA-MyWebsiteName-Readonly,OU=ISSWA-AppRoles,OU=WebApps,OU=Corporate 
Information Services,OU=cp,OU=Services,DC=mywebsitename,DC=com

CN=ISSWA-MyWebsiteName-User,OU=ISSWA-AppRoles,OU=WebApps,OU=Corporate 
Information Services,OU=cp,OU=Services,DC=mywebsitename,DC=com



CONFIDENTIAL



The server that does not works has
==
Tomcat Version:  Apache Tomcat/8.5.58   
JVM Version: 11.0.12+7-LTS
JVM Vendor: Red Hat, Inc.
OS Name: Linux  
OS Version: 3.10.0-1160.36.2.el7.x86_64
OS Architecture: amd64


The server that not work has

Tomcat version: Apache Tomcat/8.5.30
JVM Version: 11.0.11+9-LTS
JVM Vendor: Red Hat, Inc.
OS Name: Linux
OS Version: 3.10.0-1160.31.1.el7.x86_64
OS Architecture: amd64


Are you able to segregate that non-working machine to run some tests 
against it? Can you increase the logging for the authenticator / realm 
to see what is happening?


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat Virtual Host to prevent Improper-Input-Handling attack

2021-09-13 Thread Christopher Schultz

Pradeep,

On 9/13/21 09:35, Pradeep wrote:

I am using Tomcat 7.0.57, I can't change the Tomcat version now.


Running my previous "forge" file (with GET http://www.microsoft.com/, 
the the forged Host header) against Tomcat 7.0.57:


$ nc localhost 8080 < forge
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=ISO-8859-1
Transfer-Encoding: chunked
Date: Mon, 13 Sep 2021 13:46:25 GMT

2000


[remainder of the "welcome" document from ROOT] context.

Changing the request line to "GET www.microsoft.com/ HTTP/1.1":

$ nc localhost 8080 < forge
HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Mon, 13 Sep 2021 13:49:01 GMT
Connection: close

Changing the request line to "GET / HTTP/1.1":

$ nc localhost 8080 < forge
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=ISO-8859-1
Transfer-Encoding: chunked
Date: Mon, 13 Sep 2021 13:49:27 GMT

2000


[welcome page, again]

I cannot reproduce your circumstances.

Please provide steps-to-reproduce.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat Virtual Host to prevent Improper-Input-Handling attack

2021-09-13 Thread Christopher Schultz

Pradeep,

On 9/13/21 09:35, Pradeep wrote:

Hi Chris,

I am using Tomcat 7.0.57, I can't change the Tomcat version now. I tried
adding Virtual Host with RemotrHostValve to allow list of hosts but still
no luck.





This is because you are trying to block the client by their identity 
(like "localhost" if you are working locally). It has nothing whatsoever 
to do with the Host header, the hostname of the server, or anything 
else. RemoteAddrValve and RemoteHostValve are completely irrelevant for 
what you are trying to do.


Can you give me specific instructions for how to reproduce this "attack">?

-chris


On Mon, 13 Sep 2021, 2:28 pm Christopher Schultz, <
ch...@christopherschultz.net> wrote:


Pradeep,

On 9/10/21 17:38, Pradeep wrote:

My application is HTTPS not HTTP and now one of the application security
platforms  WhitHatSec raised this vulnerability issue.


I tried to reproduce your "attack" on Tomcat 8.5.59, like this:

$ cat forge
GET www.microsoft.com/ HTTP/1.1
Host: www.microsoft.com


$ od -t x1 -a forge
00047  45  54  20  77  77  77  2e  6d  69  63  72  6f  73  6f  66
 G   E   T  sp   w   w   w   .   m   i   c   r   o   s   o   f
02074  2e  63  6f  6d  2f  20  48  54  54  50  2f  31  2e  31  0d
 t   .   c   o   m   /  sp   H   T   T   P   /   1   .   1  cr
0400a  48  6f  73  74  3a  20  77  77  77  2e  6d  69  63  72  6f
nl   H   o   s   t   :  sp   w   w   w   .   m   i   c   r   o
06073  6f  66  74  2e  63  6f  6d  0d  0a  0d  0a
 s   o   f   t   .   c   o   m  cr  nl  cr  nl

$ nc tomcat 8080 < forge
HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 795
Date: Mon, 13 Sep 2021 13:22:51 GMT
Connection: close

HTTP Status 400 – Bad
Requestbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP

Status 400 – Bad RequestType Status
ReportMessage Invalid URIDescription The
server cannot or will not process the request due to something that is
perceived to be a client error (e.g., malformed request syntax, invalid
request message framing, or deceptive request routing).

Changing the "www.microsoft.com" to "http://www.microsoft.com; returns
this:

HTTP/1.1 404
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 751
Date: Mon, 13 Sep 2021 13:25:22 GMT

HTTP Status 404 – Not
Foundbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP

Status 404 – Not FoundType Status
ReportMessage The requested resource [] is not
availableDescription The origin server did not find a
current representation for the target resource or is not willing to
disclose that one exists.Apache
Tomcat/8.5.59

Removing the "www.microsoft.com" from the request-line returns this:

HTTP/1.1 404
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 751
Date: Mon, 13 Sep 2021 13:24:34 GMT

HTTP Status 404 – Not
Foundbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP

Status 404 – Not FoundType Status
ReportMessage The requested resource [] is not
availableDescription The origin server did not find a
current representation for the target resource or is not willing to
disclose that one exists.Apache
Tomcat/8.5.59

Please show me what (exact) steps are required to reproduce this issue.
Also please try your "attack" against Tomcat 8.5.x and/or 9.0.x as well
as your Tomcat 7.0.x version.


I tried the above configuration mentioned but no luck but this
configuration advised in Apache website
http://tomcat.apache.org/tomcat-9.0-doc/config/host.html#Request_Filters

  > to filter Host Header. I understand this is trivial but I have to fix

and I think I should handle it in the application server Tomcat7.

You can't filter-out the Host header. Well, not effectively.


I tried the below configuration but still validation is not working,
it's still redirecting other Host Headers. Please let me know what
else configuration I can try >

  >   
  >   className="org.apache.catalina.valves.RemoteAddrValve"
  > allow=".*\.myapplication1\.com|.*\myapplication2\.com"/>
  > 

You misunderstand the purpose of the RemoteAddrValve[1].

The valve enforces client identity, not the host the client is trying to
access. It also works on IP addresses, not h

Re: Aw: Re: tomcat hangs

2021-09-13 Thread Christopher Schultz

Peter,

On 9/13/21 04:12, Peter Rader wrote:

Chris,


Gesendet: Donnerstag, 09. September 2021 um 22:15 Uhr
Von: "Christopher Schultz" 
An: users@tomcat.apache.org
Betreff: Re: Aw: tomcat hangs
Peter,

On 9/9/21 08:21, Peter Rader wrote:

I might noticed a simmilar issue: I ran the JVM in a linux OS on a VM
(in virtualbox btw). The jdk for some reason request a random number.
The JDK asks the LinuxOS for a new random number (maybe in the hope
to use a hardware-based TRNG). Since this linux in virtualbox is
not-so low-level the random number is generated due to RAM
squarenumbers, because no memory is changed - no new random number
has been generated and we get a OS-based softlock.


WHAT?

-chris


YES, id reported this many years ago 
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4952383

There is a workaround (from comments): set java.security.egd=file:/dev/urandom


That is a very very very old hack which shouldn't be required under any 
modern installation.


My "WHAT?" question was more about the string of words before that, only 
some of which coalesced into a coherent idea.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Server redirected too many times (20)

2021-09-13 Thread Christopher Schultz

Barry,

On 9/12/21 12:59, Barry Kimelman wrote:

I just installed tomcat 9.0.52 on my linux ubuntu 20.04 LTS system.

I was successfully able to run the manager app as a test.

Now I am trying to build an application that I had worked on quite a while
ago in an older version of tomcat.

I have a script which runs a series of ANT commands to build and install my
app which has always worked well.

Now with this version of tomcat when I run   ant remove I get the following
error messages

Buildfile: /home/barry/tomcat/hockey3/build.xml
Trying to override old definition of datatype resources

remove:

BUILD FAILED
/home/barry/tomcat/hockey3/build.xml:504: java.net.ProtocolException:
Server redirected too many  times (20)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1932)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1520)
at
org.apache.catalina.ant.AbstractCatalinaTask.execute(AbstractCatalinaTask.java:224)
at
org.apache.catalina.ant.AbstractCatalinaTask.execute(AbstractCatalinaTask.java:156)
at org.apache.catalina.ant.UndeployTask.execute(UndeployTask.java:41)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1391)
at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1254)
at org.apache.tools.ant.Main.runBuild(Main.java:830)
at org.apache.tools.ant.Main.startAnt(Main.java:223)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:284)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)

Total time: 0 seconds

Here is the relavant  portion of my build.xml file


   48 

   79  
   80  

  127  
  128  
  129  
  130  
  131  
  132  
  133  
  134  http://localhost:8080/manager/text"/>
  135  
  136  

  487 
  488

  497
  498  
  500
  501
  505
  506  

I am puzzled.   What have IO done wrong ?


Try running "ant -v [target]" and see if you get more output.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat Virtual Host to prevent Improper-Input-Handling attack

2021-09-13 Thread Christopher Schultz

Pradeep,

On 9/10/21 17:38, Pradeep wrote:

My application is HTTPS not HTTP and now one of the application security
platforms  WhitHatSec raised this vulnerability issue.


I tried to reproduce your "attack" on Tomcat 8.5.59, like this:

$ cat forge
GET www.microsoft.com/ HTTP/1.1
Host: www.microsoft.com


$ od -t x1 -a forge
00047  45  54  20  77  77  77  2e  6d  69  63  72  6f  73  6f  66
   G   E   T  sp   w   w   w   .   m   i   c   r   o   s   o   f
02074  2e  63  6f  6d  2f  20  48  54  54  50  2f  31  2e  31  0d
   t   .   c   o   m   /  sp   H   T   T   P   /   1   .   1  cr
0400a  48  6f  73  74  3a  20  77  77  77  2e  6d  69  63  72  6f
  nl   H   o   s   t   :  sp   w   w   w   .   m   i   c   r   o
06073  6f  66  74  2e  63  6f  6d  0d  0a  0d  0a
   s   o   f   t   .   c   o   m  cr  nl  cr  nl

$ nc tomcat 8080 < forge
HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 795
Date: Mon, 13 Sep 2021 13:22:51 GMT
Connection: close

HTTP Status 400 – Bad 
Requestbody 
</tt><tt>{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b 
</tt><tt>{color:white;background-color:#525D76;} h1 {font-size:22px;} h2 
</tt><tt>{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a 
</tt><tt>{color:black;} .line 
</tt><tt>{height:1px;background-color:#525D76;border:none;}HTTP 
Status 400 – Bad RequestType Status 
ReportMessage Invalid URIDescription The 
server cannot or will not process the request due to something that is 
perceived to be a client error (e.g., malformed request syntax, invalid 
request message framing, or deceptive request routing).class="line" />


Changing the "www.microsoft.com" to "http://www.microsoft.com; returns this:

HTTP/1.1 404
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 751
Date: Mon, 13 Sep 2021 13:25:22 GMT

HTTP Status 404 – Not 
Foundbody 
</tt><tt>{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b 
</tt><tt>{color:white;background-color:#525D76;} h1 {font-size:22px;} h2 
</tt><tt>{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a 
</tt><tt>{color:black;} .line 
</tt><tt>{height:1px;background-color:#525D76;border:none;}HTTP 
Status 404 – Not FoundType Status 
ReportMessage The requested resource [] is not 
availableDescription The origin server did not find a 
current representation for the target resource or is not willing to 
disclose that one exists.Apache 
Tomcat/8.5.59


Removing the "www.microsoft.com" from the request-line returns this:

HTTP/1.1 404
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 751
Date: Mon, 13 Sep 2021 13:24:34 GMT

HTTP Status 404 – Not 
Foundbody 
</tt><tt>{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b 
</tt><tt>{color:white;background-color:#525D76;} h1 {font-size:22px;} h2 
</tt><tt>{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a 
</tt><tt>{color:black;} .line 
</tt><tt>{height:1px;background-color:#525D76;border:none;}HTTP 
Status 404 – Not FoundType Status 
ReportMessage The requested resource [] is not 
availableDescription The origin server did not find a 
current representation for the target resource or is not willing to 
disclose that one exists.Apache 
Tomcat/8.5.59


Please show me what (exact) steps are required to reproduce this issue. 
Also please try your "attack" against Tomcat 8.5.x and/or 9.0.x as well 
as your Tomcat 7.0.x version.


I tried the above configuration mentioned but no luck but this 
configuration advised in Apache website 
http://tomcat.apache.org/tomcat-9.0-doc/config/host.html#Request_Filters

> to filter Host Header. I understand this is trivial but I have to fix

and I think I should handle it in the application server Tomcat7.

You can't filter-out the Host header. Well, not effectively.


I tried the below configuration but still validation is not working,
it's still redirecting other Host Headers. Please let me know what
else configuration I can try >

>   
>   className="org.apache.catalina.valves.RemoteAddrValve"
> allow=".*\.myapplication1\.com|.*\myapplication2\.com"/>
> 

You misunderstand the purpose of the RemoteAddrValve[1].

The valve enforces client identity, not the host the client is trying to 
access. It also works on IP addresses, not hostnames. I'm surprised you 
were able to access anything at all.


-chris

[1] 
http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Remote_Address_Valve



On Fri, Sep 10, 2021 at 7:36 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Pradeep,

On 9/10/21 06:19, Pradeep wrote:

Hi Team,

I need your help to fix HTTP Host header attacks.
I

Re: Tomcat Virtual Host to prevent Improper-Input-Handling attack

2021-09-10 Thread Christopher Schultz

Pradeep,

On 9/10/21 06:19, Pradeep wrote:

Hi Team,

I need your help to fix HTTP Host header attacks.
I'm currently in the process of trying to fix a site vulnerability,
basically it is one type of the "Improper Input Handling" attack.

Let's say my website is www.mywebsite.com and there is hacker's website
www.hacker.com
Whenever there is a request send to www.mywebsite.com with modified "Host"
header point to www.hacker.com, my site will create a redirect to
www.mywebsite.com along with whatever the url it was. e.g.


*Normal:*
Host: www.mywebsite.com
GET  www.mywebsite.com/get/some/resources/
Reponse 200 ok


*Hack:*Host: www.hacker.com (#been manually modified)
GET  www.mywebsite.com/get/some/resources/
Response 302
Send another Redirect to www.hacker.com/get/some/resources

I have found this configuration below for tomcat (my application using
Tomcat7) is this works for case? Also I have some existing Host name in
server.xml not sure how to incorporate both Host configuration, please help
me on this.

*Solution I found :*


   

*My tomcat existing Host configuration:*



I'm not sure why the above configuration would change anything. Can you 
explain?


Please note that the "attacker" in this situation can only attack 
himself. Injecting/modifying a header into an HTTP request can only be 
done if the attacker is in a MitM position, which should not be possible 
when using HTTPS. If using HTTP, then you are on your own and this 
attack is trivial.


Assuming there is no MitM, it is challenging to cause another client to 
use a header of the attacker's choosing.


Unless this is simply an academic question.

I always use Tomcat configured with a "default" , but I suspect 
there may be a way to force Tomcat to treat a request as invalid if the 
Host header doesn't match the name (or alias) of any  configured.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Aw: tomcat hangs

2021-09-09 Thread Christopher Schultz

Peter,

On 9/9/21 08:21, Peter Rader wrote:

I might noticed a simmilar issue: I ran the JVM in a linux OS on a VM
(in virtualbox btw). The jdk for some reason request a random number.
The JDK asks the LinuxOS for a new random number (maybe in the hope
to use a hardware-based TRNG). Since this linux in virtualbox is
not-so low-level the random number is generated due to RAM
squarenumbers, because no memory is changed - no new random number
has been generated and we get a OS-based softlock.


WHAT?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Http TRACE method headers in response body

2021-09-09 Thread Christopher Schultz

Mark,

On 9/9/21 03:05, Mark Thomas wrote:

On 08/09/2021 20:50, Christopher Schultz wrote:

Mark,

On 9/8/21 11:28, Mark Thomas wrote:

On 08/09/2021 16:15, Gilles Robert wrote:

My issue is that even though TRACE is disabled, we see the "malicious"
header in the response.


You need to talk to the Spring folks then. Default Tomcat behaviour 
is to return a 405 with an error message in the response. I've just 
doubled checked this with telnet and 9.0.x.



As an aside, the idea that any TRACE response is a security issue 
with the server, whether it contains a "malicious" header or not is 
nonsense. The only thing a user agent anywhere should be doing with a 
TRACE response is displaying it as plain text. If a user agent does 
something else with the response, and especially if it does something 
reckless like treating it is HTML, then than is a security issue with 
the user agent, not the server.




Super duper vuln:

$ curl -X TRACE --header '' myurl | bash

RCE every time, bro.


:)

You would have got bonus points if the first character was '#' rather 
than '$'.


sudo make me a sandwich[1] ?

-chris

[1] https://xkcd.com/149/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Http TRACE method headers in response body

2021-09-08 Thread Christopher Schultz

Mark,

On 9/8/21 11:28, Mark Thomas wrote:

On 08/09/2021 16:15, Gilles Robert wrote:

My issue is that even though TRACE is disabled, we see the "malicious"
header in the response.


You need to talk to the Spring folks then. Default Tomcat behaviour is 
to return a 405 with an error message in the response. I've just doubled 
checked this with telnet and 9.0.x.



As an aside, the idea that any TRACE response is a security issue with 
the server, whether it contains a "malicious" header or not is nonsense. 
The only thing a user agent anywhere should be doing with a TRACE 
response is displaying it as plain text. If a user agent does something 
else with the response, and especially if it does something reckless 
like treating it is HTML, then than is a security issue with the user 
agent, not the server.




Super duper vuln:

$ curl -X TRACE --header '' myurl | bash

RCE every time, bro.

-chris


On Wed, 8 Sept 2021 at 17:01, Mark Thomas  wrote:


On 08/09/2021 14:14, Gilles Robert wrote:

Hi,

Using Spring boot (2.5.4) with Tomcat (9.0.52), the HTTP TRACE method
is disabled by default and returns a 405 method not allowed, which is
what I expect security-wise. My issue is that if one gives a malicious
header:

header: malicious: alert('malicious call');

it's given back in the response:

TRACE /xyz/error HTTP/1.1
malicious: alert('malicious call');
user-agent: PostmanRuntime/7.22.0
accept: */*
host: localhost:8080
accept-encoding: gzip, deflate, br
content-length: 0
connection: keep-alive

This is conform to the RFC 2616 which states:

"If the request is valid, the response SHOULD contain the entire
request message in the entity-body, with a Content-Type of
"message/http"."


Do you mean that you are seeing the TRACE response even when TRACE is
disabled?

Or is the issue that if TRACE is enabled, then you see the "malicious"
header in the response?

Mark




My penetration test team is complaining about it.

How can I remove any HTML entities from the TRACE response, without
having to enable it, cleaning the tags and returning the 405 myself?

Thanks!

-
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



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: BasicDataSource restart()

2021-09-07 Thread Christopher Schultz

Jerry,

On 9/7/21 15:49, Jerry Malcolm wrote:


On 9/7/2021 2:35 PM, Christopher Schultz wrote:

Jerry, Rémy,

On 9/3/21 07:15, Rémy Maucherat wrote:
On Fri, Sep 3, 2021 at 2:46 AM Jerry Malcolm  
wrote:


I have a requirement to start a new log database on the first of every
month.  I still need to have access to older monthly log databases.   I
do not want to create a bunch of hardcoded manually configured
individual datasources, one for each month.  I have a dynamic 
datasource

solution that is completely implemented and working except for one
little thing.

I access the BasicDataSource implementation class for the 
datasource.  I

have an algorithm that substitutes _MM at the appropriate spot in
the configured URL and then updates the url in the datasource.   All of
this works great.  I can live with the fact that the datasource can 
only

point to one database at a time.  My concern is that once I transition
to another database, there are existing connections in the pool that 
are

already attached to the old database.  I need to clear those out and
start over.  But I don't have the luxury of bouncing tomcat to clean 
it up.


The apache commons BasicDataSource has a restart() method. But
unfortunately that method is omitted from the Tomcat version. There 
is a

close() method on the BasicDataSource.  But I don't see anything that
will re-open it after closing.  I thought about changing maxActive 
to 0,

and waiting for it to drain, then setting it back to the original
value.  None of these sound like an ideal solution.  Without a 
restart()

method, is there any other way to force all existing connections to
close and start clean?


The code is kept in sync with DBCP (with a bit of lag maybe), so these
lifecycle methods were also added to Tomcat one year ago (9.0.38+ and
8.5.58+).


We are using this at $work to bounce our database connection pools 
after TLS client certificate changes. This is the code we are using to 
reload the pool:


  try
  {
  Context ctx = new InitialContext();

  DataSource ds = (DataSource)ctx.lookup(getJNDIPath());

  if(null == ds)
  throw new ServiceException("Cannot obtain DataSource");

  if(isInstanceOf(ds, "org.apache.tomcat.dbcp.dbcp2.BasicDataSource")
 || isInstanceOf(ds, 
"org.apache.commons.dbcp2.BasicDataSource")) {


  return call(ds, "restart");
  }
  } catch (Exception e) {
org.apache.log4j.Logger.getLogger(this.getClass()).error("Failed to 
reload DataSource " + getJNDIPath());

  }

The call() method simply encapsulates all of the work to make a 
reflective method call to BasicDataSource.restart().


As Rémy points out, it requires a Tomcat version 9.0.38+ or 8.5.58+.

Hope that helps,
-chris


Chris,

I'll definitely try this.  But I'm curious about the restart method.  Is 
it some sort of a hidden method that's only available to reflection? 
Seems it would be a lot more straightforward to just make the restart 
method public like it is in the apache version of BasicDataSource.  I'm 
not complaining.  If this works, then fine.  Just curious.


It's not magic; that method is in there[1][2].

The only reason we call it reflectively is because we don't want to have 
compile-time dependencies on the Tomcat internal classes.


-chris

[1] 
https://commons.apache.org/proper/commons-dbcp/apidocs/org/apache/commons/dbcp2/BasicDataSource.html#restart--
[2] 
https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/tomcat/dbcp/dbcp2/BasicDataSource.html#restart()


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: BasicDataSource restart()

2021-09-07 Thread Christopher Schultz

Jerry, Rémy,

On 9/3/21 07:15, Rémy Maucherat wrote:

On Fri, Sep 3, 2021 at 2:46 AM Jerry Malcolm  wrote:


I have a requirement to start a new log database on the first of every
month.  I still need to have access to older monthly log databases.   I
do not want to create a bunch of hardcoded manually configured
individual datasources, one for each month.  I have a dynamic datasource
solution that is completely implemented and working except for one
little thing.

I access the BasicDataSource implementation class for the datasource.  I
have an algorithm that substitutes _MM at the appropriate spot in
the configured URL and then updates the url in the datasource.   All of
this works great.  I can live with the fact that the datasource can only
point to one database at a time.  My concern is that once I transition
to another database, there are existing connections in the pool that are
already attached to the old database.  I need to clear those out and
start over.  But I don't have the luxury of bouncing tomcat to clean it up.

The apache commons BasicDataSource has a restart() method.  But
unfortunately that method is omitted from the Tomcat version. There is a
close() method on the BasicDataSource.  But I don't see anything that
will re-open it after closing.  I thought about changing maxActive to 0,
and waiting for it to drain, then setting it back to the original
value.  None of these sound like an ideal solution.  Without a restart()
method, is there any other way to force all existing connections to
close and start clean?


The code is kept in sync with DBCP (with a bit of lag maybe), so these
lifecycle methods were also added to Tomcat one year ago (9.0.38+ and
8.5.58+).


We are using this at $work to bounce our database connection pools after 
TLS client certificate changes. This is the code we are using to reload 
the pool:


  try
  {
  Context ctx = new InitialContext();

  DataSource ds = (DataSource)ctx.lookup(getJNDIPath());

  if(null == ds)
  throw new ServiceException("Cannot obtain DataSource");

  if(isInstanceOf(ds, "org.apache.tomcat.dbcp.dbcp2.BasicDataSource")
 || isInstanceOf(ds, "org.apache.commons.dbcp2.BasicDataSource")) {

  return call(ds, "restart");
  }
  } catch (Exception e) {
  org.apache.log4j.Logger.getLogger(this.getClass()).error("Failed 
to reload DataSource " + getJNDIPath());

  }

The call() method simply encapsulates all of the work to make a 
reflective method call to BasicDataSource.restart().


As Rémy points out, it requires a Tomcat version 9.0.38+ or 8.5.58+.

Hope that helps,
-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Debug apache-tomcat-8.5.59 open sockets on Linux 8

2021-08-31 Thread Christopher Schultz

Yeggy,

On 8/31/21 11:59, Yeggy Javadi wrote:

I am trying to troubleshoot a 'too many open files' issue. In our web
application there are connections to Postgres database and I see the
number of open sockets keep increasing.
Try using 'lsof' on the process to see what those open files are 
pointing to. Are you sure you are running out of files with many 
database connections, or is it just a suspicion?


You can probably also ask the database how many connections are open.

-chris


-Original Message-
From: Christopher Schultz 
Sent: Tuesday, August 31, 2021 11:50 AM
To: users@tomcat.apache.org
Subject: Re: Debug apache-tomcat-8.5.59 open sockets on Linux 8

Yeggy,

On 8/31/21 11:22, Yeggy Javadi wrote:

Please indicate if there is any debug option and log that can trace
sockets open by tomcat to identify when and by which application
function a socket is open.

Do you mean a web application?

Tomcat manages incoming HTTP/2/Websocket/APR connections on behalf of the web 
applications deployed into it, so the connections aren't "owned"
by a particular web application.

Outgoing connections are typically the responsibility of the application 
itself, unless you are talking about specific connections Tomcat may provide 
(e.g. SMTP or JDBC).

What problem are you trying to solve?

-chris

-
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: Debug apache-tomcat-8.5.59 open sockets on Linux 8

2021-08-31 Thread Christopher Schultz

Yeggy,

On 8/31/21 11:22, Yeggy Javadi wrote:

Please indicate if there is any debug option and log that can trace
sockets open by tomcat to identify when and by which application
function a socket is open.

Do you mean a web application?

Tomcat manages incoming HTTP/2/Websocket/APR connections on behalf of 
the web applications deployed into it, so the connections aren't "owned" 
by a particular web application.


Outgoing connections are typically the responsibility of the application 
itself, unless you are talking about specific connections Tomcat may 
provide (e.g. SMTP or JDBC).


What problem are you trying to solve?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: HttpNIO error

2021-08-31 Thread Christopher Schultz

Rinilnath,

On 8/31/21 09:54, rinilnath r wrote:

Hi Chris,

Java : 1.8.0_45
OS : Windows 7

  

Also, can you please post the full stack trace of the 
UnsupportedOperationException?


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: HttpNIO error

2021-08-31 Thread Christopher Schultz

Rinilnath,

On 8/31/21 09:54, rinilnath r wrote:

On 8/31/21 09:23, rinilnath r wrote:

I am using tomcat Http11nio2protocol. I configured it in server XML.

When I start the server it failed to start

UnsupportedOperationException. SO_LINGER not supported

Any help please?


Please post:

1. Your Java version
2. Your OS and version
3. Your  configuration, minus any secrets you may have

>
> [Tomcat 9.0.5]
> Java : 1.8.0_45
> OS : Windows 7
>
>protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> connectionTimeout="6" maxConnections "1" redirect Port="8443"
> enableLookups "false" acceptCount="100" maxPostSize "10485760"
> maxHttpHeaderSize="8192" compression="on" disableUploadrimeout="true"
> compressionMinSize="2048" acceptor ThreadCount="2" compressableMimeType=
> "text/html,text/plain, text/css, application/javascript, 
application/json,
> application/x-font-ttf, application/x-font-otf, imag e/svg+xml 
image/jpeg,

> image/png,image/gif, audio/mpeg, video/mp4" URIEncoding="utf-8"
> processorCache="2" tepNoDelay= "true" connectioniLinger="5" server
> ="Server Version 11.0"/>

There are some typos in that configuration (e.g. "tepNoDelay", 
"connectioniLinger", missing = signs, extra spaces, etc.). Did you 
copy/paste, or did you re-type it?


-chris


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: HttpNIO error

2021-08-31 Thread Christopher Schultz

Rinilnath,

On 8/31/21 09:23, rinilnath r wrote:

I am using tomcat Http11nio2protocol. I configured it in server XML.

When I start the server it failed to start

UnsupportedOperationException. SO_LINGER not supported

Any help please?


Please post:

1. Your Java version
2. Your OS and version
3. Your  configuration, minus any secrets you may have

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Timestamp Error

2021-08-30 Thread Christopher Schultz

Terrence and Jerry,

On 8/27/21 21:33, Terence M. Bandoian wrote:

On 8/27/2021 2:31 PM, Jerry Malcolm wrote:


On 8/27/2021 1:30 PM, Mark Eggers wrote:

On 8/27/2021 11:16 AM, Jerry Malcolm wrote:


On 8/27/2021 11:55 AM, Christopher Schultz wrote:

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL 
error on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data 
truncation: Incorrect datetime value: '1969-12-31 18:00:00.0' for 
column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into 
phpMyAdmin, and it worked.  When I change the date to '2021-08-27 
01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016. But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I 
have to avoid dates that fail, I can probably do that.  But right 
now,
I don't know what dates are going to work and what dates are 
going to fail.


Am I missing something obvious?  I've never had a SQL statement 
that failed consistently on TC but worked when pasted into 
phpMyAdmin.


Suggestions?

Thanks.

Jerry


There is a setting in the driver called something like "null means 
zero datetime" which may confuse the heck out of TIMESTAMP columns, 
which expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that 
your system is running in Us-Mountain Time, 6 hours behind UTC in 
the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, 
and that your driver is using MDT as your time zone, trying to 
convert NULL -> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT 
-> boom, since the minimum allowed TIMESTAMP value is 1970-01-01 
00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't 
good for much...


-chris

Chris,  thanks for the info.  Why timestamp?  Unfortunately, some of 
this code was written 20+ years ago when I was a lot less 
knowledgeable... But too difficult to change now.


I'm not inserting nulls.  Always a quoted date/time string.

You are correct about the timezone.  That's on my dev laptop, and I 
never got around to setting the timezone stuff correctly on my my 
dev machine.  However, my production server (Linux) does have the 
timezones all set correctly.  My insert statement has a value of 
"new Timestamp(0).toString()".  On the production server, this 
becomes '1970-01-01 00:00:00.0' and it still fails on production.


Is the jdbc driver enforcing the minimum timestamp value? mySQL 
accepts 1969-12-31 18:00:00.0 in the insert statement. mySQL may be 
adjusting the time +6 on my laptop back up the epoch value before 
storing it.  But the situation still remains that the same insert 
statement works on phpMyAdmin and fails on TC.


The timezone thing is just adding unnecessary complexity to the 
problem.  The production server fails on TC with '1970-01-01 
00:00:00.0' in the insert statement, but works with that value when 
inserted into mySQL pasting the insert statement into phpMyAdmin.


The exception is com.mysql.cj.jdbc.exceptions.MysqlDataTruncation. 
Is the driver detecting this and generating the exception?  Or does 
the insert statement get all the way to mySQL and mySQL fails back 
to the driver followed by the driver throwing the exception?


Jerry


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html

See the constructor: public Timestamp(long time)

. . . just my two cents
/mde/

|Timestamp 
<https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html#Timestamp-long->(long time)| 


Constructs a |Timestamp| object using a milliseconds time value.
|time| - milliseconds since January 1, 1970, 00:00:00 GMT. A negative 
number is the number of milliseconds before January 1, 1970, 00:00:00 
GMT.


This says that a timestamp can be before the epoch, no minimum time, 
which agrees with what I'm seeing via phpMyAdmin.  Which means that 
what I'm providing in the sql insert statement should be accepted 
regardless of timezone factors. Seems to me there's a bug in the TC 
driver (??)  And the error message I'm getting says "data truncation", 
which at best is incorrect wording.  Not sure how any truncation could 
occur on a date str

Re: Apache Tomcat 9 | Tomcat starting issue

2021-08-30 Thread Christopher Schultz

Piyush,

On 8/24/21 23:47, Piyush Sharma wrote:

On Mon, Aug 23, 2021 at 8:29 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Piyush,

On 8/22/21 03:54, Piyush Sharma wrote:

On Fri, Aug 20, 2021 at 10:40 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Piyush,

On 8/20/21 06:36, Piyush Sharma wrote:


Hello,

I am using Apache Tomcat 9.0.46 version on docker container.

There is a problem, where the base path was wrongly set by automation
script due to which it starts for few seconds, listen port 8080 and

then

stop, due to that container exit after sometime.



Now how can we debug such issue, which shows any error / problem in

tomcat

configuration.

I tried with "jpda start" or "debug" options, but that didn't help me.

Is

there any option to debug tomcat related issues or problems.

"catalina.sh configtest" will show any error in xml or properties but

will

not help to debug tomcat startup problem.

*Note:* I am just deploying with the helloworld war file. nothing much

in

code as of now.


Maybe just fix your automation script to use the right path?

It's hard to understand what the problem is given the information you
have presented.

-chris



Thanks Chris

I have removed automation and harded everything and created a new docker
image.
Now when I try to start the container, it starts for a few seconds and
stops (port 8080 listens for a while). Nothing in logs.

$ catalina.sh run  (tried with "jpda start" or "debug" options as well)
$ ps aux |grep java --> show the process for few seconds
$ netstat -ntpl |grep 8080 --> shows the port for few seconds

I am wondering if I can debug such issues, when it starts for a few

seconds

and then stops. Is there any memory , config file or any other issues?

Any debug option whether tomcat


What do the logs say?

-chris




Hello Chris,

After starting the container in debug mode, I noticed Exit Code 137 which
seems to be OOM (out of memory) issue. Due to which container exit /
terminate.

Is there any other reason for Exit Code 137 ? as I am just starting hello
world application and given 2 GB RAM.


What do the logs say?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Timestamp Error

2021-08-27 Thread Christopher Schultz

Jerry,

On 8/27/21 14:16, Jerry Malcolm wrote:


On 8/27/2021 11:55 AM, Christopher Schultz wrote:

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL 
error on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: 
Incorrect datetime value: '1969-12-31 18:00:00.0' for column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into phpMyAdmin, 
and it worked.  When I change the date to '2021-08-27 01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016.  But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I 
have to avoid dates that fail, I can probably do that.  But right now,
I don't know what dates are going to work and what dates are going 
to fail.


Am I missing something obvious?  I've never had a SQL statement that 
failed consistently on TC but worked when pasted into phpMyAdmin.


Suggestions?

Thanks.

Jerry


There is a setting in the driver called something like "null means 
zero datetime" which may confuse the heck out of TIMESTAMP columns, 
which expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that your 
system is running in Us-Mountain Time, 6 hours behind UTC in the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, and 
that your driver is using MDT as your time zone, trying to convert 
NULL -> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT -> boom, 
since the minimum allowed TIMESTAMP value is 1970-01-01 00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't good 
for much...


-chris

Chris,  thanks for the info.  Why timestamp?  Unfortunately, some of 
this code was written 20+ years ago when I was a lot less 
knowledgeable... But too difficult to change now.


I'm not inserting nulls.  Always a quoted date/time string.

You are correct about the timezone.  That's on my dev laptop, and I 
never got around to setting the timezone stuff correctly on my my dev 
machine.  However, my production server (Linux) does have the timezones 
all set correctly.  My insert statement has a value of "new 
Timestamp(0).toString()".  On the production server, this becomes 
'1970-01-01 00:00:00.0' and it still fails on production.


WAIT. DO NOT DO THIS.

If you want to set a date/time field in the database, use:

ps = conn.prepareStatement("UPDATE ... SET field=? WHERE ...");
ps.setTimestamp(new Timestamp(0));
ps.executeQuery();

Don't convert to String. It's awful. If you use Timestamp directly, the 
driver will figure out all the time zone issues and this shouldn't bite you.


I'm running MariaDB and here's what it has to say about TIMESTAMP fields:

MariaDB [diagnosis]> help timestamp;
Name: 'TIMESTAMP'
Description:
TIMESTAMP

A timestamp. The range is '1970-01-01 00:00:01' UTC to '2038-01-19
03:14:07' UTC. TIMESTAMP values are stored as the number of seconds
since the epoch ('1970-01-01 00:00:00' UTC). A TIMESTAMP cannot
represent the value '1970-01-01 00:00:00' because that is equivalent to
0 seconds from the epoch and the value 0 is reserved for representing
'-00-00 00:00:00', the "zero" TIMESTAMP value.

[...]

So you can't even properly store "0" in your database.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Timestamp Error

2021-08-27 Thread Christopher Schultz

Jerry,

On 8/27/21 14:16, Jerry Malcolm wrote:


On 8/27/2021 11:55 AM, Christopher Schultz wrote:

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL 
error on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: 
Incorrect datetime value: '1969-12-31 18:00:00.0' for column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into phpMyAdmin, 
and it worked.  When I change the date to '2021-08-27 01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016.  But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I 
have to avoid dates that fail, I can probably do that.  But right now,
I don't know what dates are going to work and what dates are going 
to fail.


Am I missing something obvious?  I've never had a SQL statement that 
failed consistently on TC but worked when pasted into phpMyAdmin.


Suggestions?

Thanks.

Jerry


There is a setting in the driver called something like "null means 
zero datetime" which may confuse the heck out of TIMESTAMP columns, 
which expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that your 
system is running in Us-Mountain Time, 6 hours behind UTC in the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, and 
that your driver is using MDT as your time zone, trying to convert 
NULL -> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT -> boom, 
since the minimum allowed TIMESTAMP value is 1970-01-01 00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't good 
for much...


-chris

Chris,  thanks for the info.  Why timestamp?  Unfortunately, some of 
this code was written 20+ years ago when I was a lot less 
knowledgeable... But too difficult to change now.


I'm not inserting nulls.  Always a quoted date/time string.

You are correct about the timezone.  That's on my dev laptop, and I 
never got around to setting the timezone stuff correctly on my my dev 
machine.  However, my production server (Linux) does have the timezones 
all set correctly.  My insert statement has a value of "new 
Timestamp(0).toString()".  On the production server, this becomes 
'1970-01-01 00:00:00.0' and it still fails on production.


Is the jdbc driver enforcing the minimum timestamp value?  mySQL accepts 
1969-12-31 18:00:00.0 in the insert statement.  mySQL may be adjusting 
the time +6 on my laptop back up the epoch value before storing it.  But 
the situation still remains that the same insert statement works on 
phpMyAdmin and fails on TC.


The timezone thing is just adding unnecessary complexity to the 
problem.  The production server fails on TC with '1970-01-01 00:00:00.0' 
in the insert statement, but works with that value when inserted into 
mySQL pasting the insert statement into phpMyAdmin.


The exception is com.mysql.cj.jdbc.exceptions.MysqlDataTruncation.  Is 
the driver detecting this and generating the exception?  Or does the 
insert statement get all the way to mySQL and mySQL fails back to the 
driver followed by the driver throwing the exception?


Connector/J checks the time zone of the server relative to the time zone 
of the java.sql.Timestamp (really java.util.Date) object and adjusts 
accordingly. So if you are using "new Timestamp(0)" in your code, that 
may be the difference. I find it odd that MySQL accepts the literal 1969 
date, though. It's possible you are right and the date is being 
fast-forwarded to UTC so it actually becomes 1970-01-01 00:00:00 by the 
tie the server tries to store it.


If you are storing new Timestamp(0), you are most likely better off 
storing NULL since the beginning of the Epoch is probably not a 
meaningful value for you to store. Then again, if you have 100M rows, 
adding NULLABLE to your table definition may not be on your short-list 
of things to do.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Improve logging in org.apache.catalina.filters.RestCsrfPreventionFilter ?

2021-08-27 Thread Christopher Schultz

Polina,

On 8/26/21 10:48, Polina Georgieva wrote:

Currently the RestCsrfPreventionFilter is responding with 403 response when
the csrf token sent in the request is different from the one stored in the
session.

However except the 403 response code visible in the http access log file,
there’s no indication what happened and why is the error response.

So I think introducing some logs in this filter would be beneficial at
least from two points of view:

1. Troubleshooting

It would be easier to troubleshoot problems with clients that did not
integrate with the csrf prevention mechanism properly or could give more
clues for other situations - for example cases of session invalidation
(done by other filter for example) before the request reaches the filter.
Currently such requests are also responded with 403 though the client seems
to have sent valid session cookie and  csrf token. That’s why I believe it
would be of great help to add log(s) stating:

- if the requested session is found
- if there’s token stored in it
- if there’s token and session cookie sent in the request

without revealing their actual values or other security sensitive data.

And this information could be logged only in cases of 403 responses, i.e.
would appear only when needed.

1. Improve identifying/tracking security related incidents

According to OWASP guidelines it’s recommended to have probable malicious
attacks indicated in the logs to better identify security incidents. For
more details please refer to [1].



If you agree with these ideas, I’ll be happy to propose a patch?


This sounds like a great idea. The RestCsrfPreventionListener and its 
superclass CsrfPreventionListenerBase both have access to a log object 
via the getLogger() method. It would be trivial to:


1. Add logging for whatever situation you'd like to log
2. Configure a logger to direct the output of the CSRF failures wherever 
you'd like


So I think you don't need to worry too much about the logging 
*mechanism* but instead simply add calls to the existing logger.


I was surprised to see *zero* logging in these classes, and adding such 
logging would certainly be a welcome improvement.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Query regarding maxConnections attribute

2021-08-27 Thread Christopher Schultz

Srijith,

On 8/27/21 06:50, Srijith Kochunni wrote:

We have a project requirement that we need to scale up to accept very
high number of connections. I understand that setting maxConnections
to -1 will disable the counting of the connections. I just wanted to
know whether there are any performance implications when bumping up
the maxConnections from the default value of 8192 to a very high
number like 65K+.


I would think that at 65k connections, you might end up with other parts
of your system that can't come with such high volumes.

Do you expect 65k *simultaneous* requests? Are these HTTP or HTTP/2
connections, or something like WebSocket where you may have long-lived
connections but maybe not much data crossing those connections?


Will this cause any adverse impact on the functioning of Tomcat.?
We're currently on version 9.0.37


Tomcat will be fine.

It's not clear whether your OS or other resources (memory, data-store,
etc.) will be able to handle it. Also remember that your TCP/IP stack 
may limit the total number of connections on a single socket, and your 
OS (usually) limits the number of open file descriptors.


If you are looking at that kind of load, it makes me think you may want 
to look at scaling horizontally.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Timestamp Error

2021-08-27 Thread Christopher Schultz

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL error 
on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: 
Incorrect datetime value: '1969-12-31 18:00:00.0' for column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into phpMyAdmin, and 
it worked.  When I change the date to '2021-08-27 01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016.  But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I have 
to avoid dates that fail, I can probably do that.  But right now,
I don't know what dates are going to work and what dates are going to 
fail.


Am I missing something obvious?  I've never had a SQL statement that 
failed consistently on TC but worked when pasted into phpMyAdmin.


Suggestions?

Thanks.

Jerry




https://dev.mysql.com/doc/refman/5.7/en/datetime.html

When you paste from the logs, you're not pasting what the original 
INSERT command is doing. Therefore, it will work, since the error 
message is giving the minimum date back that is supported by MySQL.


There is a setting in the driver called something like "null means zero 
datetime" which may confuse the heck out of TIMESTAMP columns, which 
expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that your 
system is running in Us-Mountain Time, 6 hours behind UTC in the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, and 
that your driver is using MDT as your time zone, trying to convert NULL 
-> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT -> boom, since the 
minimum allowed TIMESTAMP value is 1970-01-01 00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't good 
for much...


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: 200 response and redirect for ".../test.jsp"

2021-08-26 Thread Christopher Schultz

Mark, James,

On 8/24/21 20:40, Mark Eggers wrote:

Folks,

On 8/24/2021 3:55 PM, Christopher Schultz wrote:

James,

On 8/24/21 17:20, James H. H. Lampert wrote:
I could have sworn I asked about this over a year ago, but I can't 
find any record of having done so.


We've got a low-priority complaint about a security scan looking for 
"test.jsp" on one of our installations, expecting a 404 response, and 
instead getting a 200 response and a redirect to our own error page.


Just a sanity check: this *is* a problem with our ROOT context, not 
with Tomcat itself, right? And it has to be solved within our ROOT 
context, right?


My guess is that the vuln scanner assumes that "GET test.jsp" 
returning a 200 response means "it's got something bad in there". They 
are probably thinking about a *specific* test.jsp file, but you just 
happen to have one, probably as part of your application.


If you haven't deployed any of Tomcat's "example", "docs", or ROOT 
applications (meaning, the ROOT webapp that hosts Tomcat's 
documentation and stuff), then yes, this complaint is being aimed at 
your application.


You should probably be able to find test.jsp on your disk, or in your 
WAR file if for some reason you aren't exploding WAR files on deployment.


Go read the source for that file and maybe it will give you some 
insight as to where it came from.


-chris


If I understand correctly, the security scanning looks for something 
like this:


/appname/../test.jsp


The subject line has ... and not .., so I suspect that means "ellipsis" 
and not "dot dot slash" like a path segment that looks like it's looking 
for a path-traversal vuln.


How that triggers a 200, then generates an application error page I'm 
not certain.


In your application, do you have an  specified for 404 errors?


+1

In your ROOT application (if different from your regular application) do 
you have an  specified?


+1

What my $work environment has are application-specific error pages per 
application, and a generic error page for the ROOT application, which is 
just a placeholder.


Going to /appname/../test.jsp in my $work environment ends up at ROOT, 
which generates a 404 and the generic error page since there is no 
test.jsp page.


My $work environment has front end Apache HTTPD servers connected to 
multiple Tomcats via mod_jk. This may influence the results.


+1

Security scans by various clients of $work have not complained about the 
above setup.


Security scanners don't make money by telling you are already secure. 
There's gotta be *something* they can find and complain about.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: UserDatabaseRealm and DIGEST

2021-08-26 Thread Christopher Schultz

Jon,

On 8/24/21 19:51, jonmcalexan...@wellsfargo.com.INVALID wrote:

Chris,


-Original Message-
From: Christopher Schultz 
Sent: Tuesday, August 24, 2021 5:52 PM
To: users@tomcat.apache.org
Subject: Re: UserDatabaseRealm and DIGEST

Jon,

On 8/24/21 12:53, jonmcalexan...@wellsfargo.com.INVALID wrote:

-Original Message-
From: Mark Thomas 
Sent: Tuesday, August 24, 2021 11:41 AM
To: users@tomcat.apache.org
Subject: Re: UserDatabaseRealm and DIGEST

On 24/08/2021 17:28, jonmcalexan...@wellsfargo.com.INVALID wrote:

Ok, so I've been reading thru the documentation on DIGEST but not

entirely sure I have it right. What is the best practice for DIGEST
and what algorithms are allowed, such as is sha-256 allowed?

First, a question of clarification.

Do you mean HTTP DIGEST authentication or do you mean storing
password hashes rather than the actual passwords in the

UserDatabaseRealm?


Mark >

I mean the Password Hashes rather than the actual password for the

UserDatabaseRealm.

You can use any algorithm that Java's MessageDigest supports.

I would recommend against using "Digest" credential storage and instead use
something more secure such as PBKDF2, which Tomcat also supports.

You might find this informative:
https://urldefense.com/v3/__https://tomcat.apache.org/presentations.htm
l*latest-credential-
security__;Iw!!F9svGWnIaVPGSwU!7c3eGMZdJEU_EmV4XmOqEiivhaDIfji3A
sGbXN4DAVlFM-pSfYgsX93DDHm6520mF1wBLNc$

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


In this case I am wanting to know the proper way to use DIGEST as we have some 
folks with vendor applications that Use Tomcat that insist on using the 
UserDatabaseRealm. I agree that using LDAP or something other is the better way 
to go. We typically do NOT allow the use of the UserDatabaseRealm unless the 
passwords are hashed with DIGEST. I just want to make sure that when we check 
for compliance, we are approving the various means.


You can use any of those credential handlers with the UserDatabaseRealm. 
For example PBKDF2 is perfectly usable. You just need to get user 
passwords, run them through PBKDF2, and copy/paste them into 
tomcat-users.xml (or wherever you have them).


There is a "digest.sh" script that comes with your Tomcat distribution. 
Run it and you'll see the options. You can ask that to generate a 
stored-credential for any plaintext password you want to use, and it 
should work with a similarly-configured UserDatabaseRealm (and child 
CredentialHandler).


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: 200 response and redirect for ".../test.jsp"

2021-08-24 Thread Christopher Schultz

James,

On 8/24/21 17:20, James H. H. Lampert wrote:
I could have sworn I asked about this over a year ago, but I can't find 
any record of having done so.


We've got a low-priority complaint about a security scan looking for 
"test.jsp" on one of our installations, expecting a 404 response, and 
instead getting a 200 response and a redirect to our own error page.


Just a sanity check: this *is* a problem with our ROOT context, not with 
Tomcat itself, right? And it has to be solved within our ROOT context, 
right?


My guess is that the vuln scanner assumes that "GET test.jsp" returning 
a 200 response means "it's got something bad in there". They are 
probably thinking about a *specific* test.jsp file, but you just happen 
to have one, probably as part of your application.


If you haven't deployed any of Tomcat's "example", "docs", or ROOT 
applications (meaning, the ROOT webapp that hosts Tomcat's documentation 
and stuff), then yes, this complaint is being aimed at your application.


You should probably be able to find test.jsp on your disk, or in your 
WAR file if for some reason you aren't exploding WAR files on deployment.


Go read the source for that file and maybe it will give you some insight 
as to where it came from.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: UserDatabaseRealm and DIGEST

2021-08-24 Thread Christopher Schultz

Jon,

On 8/24/21 12:53, jonmcalexan...@wellsfargo.com.INVALID wrote:

-Original Message-
From: Mark Thomas 
Sent: Tuesday, August 24, 2021 11:41 AM
To: users@tomcat.apache.org
Subject: Re: UserDatabaseRealm and DIGEST

On 24/08/2021 17:28, jonmcalexan...@wellsfargo.com.INVALID wrote:

Ok, so I've been reading thru the documentation on DIGEST but not

entirely sure I have it right. What is the best practice for DIGEST and what
algorithms are allowed, such as is sha-256 allowed?

First, a question of clarification.

Do you mean HTTP DIGEST authentication or do you mean storing password
hashes rather than the actual passwords in the UserDatabaseRealm?

Mark >

I mean the Password Hashes rather than the actual password for the 
UserDatabaseRealm.


You can use any algorithm that Java's MessageDigest supports.

I would recommend against using "Digest" credential storage and instead 
use something more secure such as PBKDF2, which Tomcat also supports.


You might find this informative:
https://tomcat.apache.org/presentations.html#latest-credential-security

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: clearReferencesThreads issues warning about 2 threads, spawned by JDK in printing components

2021-08-23 Thread Christopher Schultz

Mark,

On 8/23/21 04:05, Mark Thomas wrote:

On 23/08/2021 08:10, Thomas Hoffmann (Speed4Trade GmbH) wrote:




Is there anything, the application can prevent this?


Yes. Call Thread.setContextClassLoader(ClassLoader) before calling the 
code that creates those threads, passing the common class loader. 
Afterwards, reset the TCCL back to the web application class loader.



Should Tomcat maybe skip the warning if the thread is demonized?


No. The threads have the web app class loader as their TCCL so you have 
a potential memory leak. The warning is correct.


Or maybe these threads should be ignored when checking for orphaned 
threads?


No, for the same reason.


It was tested with Tomcat 9.0.52, Windows 10, Coretto-JDK 11.0.12_7.


You might want to consider raising a bug against the JDK. It could be 
argued that those threads should be created with a specific class loader 
to avoid memory leaks in container environments.


+1

I looked at the JREMemoryLeakPreventionListener and it looks like it 
only initializes static stuff in the class using Class.forName(className().


I wonder if it would be helpful to also try to call a zero-arg 
constructor for the class if one exists. In this case, it would allow 
Tomcat (using this listener) to initialize this class (via 
instantiation) so the application doesn't have to mess-around with the TCCL.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Apache Tomcat 9 | Tomcat starting issue

2021-08-23 Thread Christopher Schultz

Piyush,

On 8/22/21 03:54, Piyush Sharma wrote:

On Fri, Aug 20, 2021 at 10:40 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Piyush,

On 8/20/21 06:36, Piyush Sharma wrote:


Hello,

I am using Apache Tomcat 9.0.46 version on docker container.

There is a problem, where the base path was wrongly set by automation
script due to which it starts for few seconds, listen port 8080 and then
stop, due to that container exit after sometime.



Now how can we debug such issue, which shows any error / problem in

tomcat

configuration.

I tried with "jpda start" or "debug" options, but that didn't help me.

Is

there any option to debug tomcat related issues or problems.

"catalina.sh configtest" will show any error in xml or properties but

will

not help to debug tomcat startup problem.

*Note:* I am just deploying with the helloworld war file. nothing much

in

code as of now.


Maybe just fix your automation script to use the right path?

It's hard to understand what the problem is given the information you
have presented.

-chris



Thanks Chris

I have removed automation and harded everything and created a new docker
image.
Now when I try to start the container, it starts for a few seconds and
stops (port 8080 listens for a while). Nothing in logs.

$ catalina.sh run  (tried with "jpda start" or "debug" options as well)
$ ps aux |grep java --> show the process for few seconds
$ netstat -ntpl |grep 8080 --> shows the port for few seconds

I am wondering if I can debug such issues, when it starts for a few seconds
and then stops. Is there any memory , config file or any other issues?

Any debug option whether tomcat


What do the logs say?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Apache Tomcat 9 | Tomcat starting issue

2021-08-20 Thread Christopher Schultz

Piyush,

On 8/20/21 06:36, Piyush Sharma wrote:


Hello,

I am using Apache Tomcat 9.0.46 version on docker container.

There is a problem, where the base path was wrongly set by automation
script due to which it starts for few seconds, listen port 8080 and then
stop, due to that container exit after sometime.



Now how can we debug such issue, which shows any error / problem in tomcat

configuration.

I tried with "jpda start" or "debug" options, but that didn't help me. Is
there any option to debug tomcat related issues or problems.

"catalina.sh configtest" will show any error in xml or properties but will
not help to debug tomcat startup problem.

*Note:* I am just deploying with the helloworld war file. nothing much in
code as of now.


Maybe just fix your automation script to use the right path?

It's hard to understand what the problem is given the information you 
have presented.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: how to tune cacheMaxSize

2021-08-20 Thread Christopher Schultz

Michael,

On 8/19/21 21:34, Michael Richardson wrote:


Aha.  Well, I left it running after the last email and went on to more
important things.  Then the window just jumped:

The previous log line:
20-Aug-2021 01:02:42.315 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL 
successfully initialized [OpenSSL 1.1.1  11 Sep 2018]

Then it acted on the ^\ I had sent.  And then it printed:
Could it have spent that time initializing OpenSSL?


It's possible, but not super-likely:


20-Aug-2021 01:02:42.083 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.io.tmpdir=/opt/apache-tomcat-9.0.52/temp
20-Aug-2021 01:02:42.210 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent An older version 
[1.2.21] of the Apache Tomcat Native library is installed, while Tomcat 
recommends a minimum version of [1.2.30]
20-Aug-2021 01:02:42.213 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache 
Tomcat Native library [1.2.21] using APR version [1.6.3].
20-Aug-2021 01:02:42.215 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: 
IPv6 [true], sendfile [true], accept filters [false], random [true], UDS 
[false].
20-Aug-2021 01:02:42.217 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL 
configuration: useAprConnector [false], useOpenSSL [true]
20-Aug-2021 01:02:42.315 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL 
successfully initialized [OpenSSL 1.1.1  11 Sep 2018]


All of the above logs are printed within s fraction of a second of each 
other. OpenSSL initialization is taking essentially zero time.



20-Aug-2021 01:29:58.867 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing 
ProtocolHandler ["http-nio-8080"]
20-Aug-2021 01:29:59.917 INFO [main] org.apache.catalina.startup.Catalina.load 
Server initialization in [1643381] milliseconds


That's quite a long time (1643381ms), and the timestamps match-up.

So you tried to get a thread-dump during this 27-minute period and the 
process simply wouldn't respond?


It is during this 27-minute period that the CPU is pegged?

Do you see anything in the kernel logs? Like dmesg.log or kernel.log or 
whatever Ubuntu logs to?



20-Aug-2021 01:30:01.832 INFO [main] 
org.apache.catalina.core.StandardService.startInternal Starting service 
[Catalina]
20-Aug-2021 01:30:01.837 INFO [main] 
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: 
[Apache Tomcat/9.0.52]
20-Aug-2021 01:30:01.997 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDirectory Deploying web 
application directory [/opt/apache-tomcat-9.0.52/webapps/manager]
20-Aug-2021 01:30:06.559 WARNING [main] 
org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of 
SecureRandom instance for session ID generation using [SHA1PRNG] took [248] 
milliseconds.
20-Aug-2021 01:30:07.109 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web 
application directory [/opt/apache-tomcat-9.0.52/webapps/manager] has finished 
in [5,111] ms
20-Aug-2021 01:30:07.117 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDirectory Deploying web 
application directory [/opt/apache-tomcat-9.0.52/webapps/examples]
20-Aug-2021 01:30:12.192 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web 
application directory [/opt/apache-tomcat-9.0.52/webapps/examples] has finished 
in [5,074] ms
20-Aug-2021 01:30:12.195 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDirectory Deploying web 
application directory [/opt/apache-tomcat-9.0.52/webapps/docs]
20-Aug-2021 01:30:12.449 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web 
application directory [/opt/apache-tomcat-9.0.52/webapps/docs] has finished in 
[253] ms
20-Aug-2021 01:30:12.451 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDirectory Deploying web 
application directory [/opt/apache-tomcat-9.0.52/webapps/ROOT]
20-Aug-2021 01:30:12.697 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web 
application directory [/opt/apache-tomcat-9.0.52/webapps/ROOT] has finished in 
[245] ms
20-Aug-2021 01:30:12.700 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDirectory Deploying web 
application directory [/opt/apache-tomcat-9.0.52/webapps/host-manager]
20-Aug-2021 01:30:12.990 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web 
application directory [/opt/apache-tomcat-9.0.52/webapps/host-manager] has 
finished in [290] ms
20-Aug-2021 01:30:13.095 INFO [main] org.apache.coyote.AbstractProtocol.start Starting 
ProtocolHandler ["http-nio-8080"]
20-Aug-2021 01:30:13.254 INFO [main] org.apache.catalina.startup.Catalina.start 
Server startup in [1] milliseconds


Well, the application deployment(s) are 

Re: how to tune cacheMaxSize

2021-08-20 Thread Christopher Schultz

Michael,

On 8/19/21 20:35, Michael Richardson wrote:


try #1.  Now rebooting VM.

Christopher Schultz  wrote:
 > 1. Stop Tomcat, clear all logs, delete your oscar.war file and the 
exploded
 > directory in CATALINA_BASE/webapps/oscar (or wherever your appBase points
 > to).
 > 2. Copy your oscar.war file into appBase, making sure that operation
 > completes
 > 3. Start Tomcat, but like this instead of what you usually do:

 > $ sudo -iu tomcatuser
 > $ $CATALINA_BASE/bin/catalina.sh run

I have not done #2.  I figure it should start up correctly, right?
My $CATALINA_BASE/webapps contains:

oscar-serv03-[/opt/apache-tomcat-9.0.52/webapps] root 7 #ls -lta
total 28
drwxr-x---  6 tomcat root 4096 Aug 16 20:28 manager/
drwxr-x---  6 tomcat root 4096 Aug 16 20:28 host-manager/
drwxr-x---  7 tomcat root 4096 Aug 16 20:28 examples/
drwxr-x--- 15 tomcat root 4096 Aug 16 20:28 docs/
drwxr-x---  3 tomcat root 4096 Aug 16 20:28 ROOT/
drwxr-xr-x  9 tomcat root 4096 Aug 16 20:28 ../
drwxr-x---  7 tomcat root 4096 Jul 31 04:12 ./

tomcat@oscar-serv03:/opt/apache-tomcat-9.0.52$ $CATALINA_HOME/bin/catalina.sh 
run
Using CATALINA_BASE:   /opt/apache-tomcat-9.0.52
Using CATALINA_HOME:   /opt/apache-tomcat-9.0.52
Using CATALINA_TMPDIR: /opt/apache-tomcat-9.0.52/temp
Using JRE_HOME:/usr/lib/jvm/java-11-openjdk-amd64
Using CLASSPATH:   
/opt/apache-tomcat-9.0.52/bin/bootstrap.jar:/opt/apache-tomcat-9.0.52/bin/tomcat-juli.jar
Using CATALINA_OPTS:
NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED 
--add-opens=java.base/java.io=ALL-UNNAMED 
--add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.ba
se/java.util.concurrent=ALL-UNNAMED 
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
^Z
[1]+  Stopped $CATALINA_HOME/bin/catalina.sh run


How long did you wait before hitting CTRL-Z there?


tomcat@oscar-serv03:/opt/apache-tomcat-9.0.52$ bg
[1]+ $CATALINA_HOME/bin/catalina.sh run &


Well, now things are complicated because you backgrounded the process.


futzing with right options to ps to show threads:

tomcat   30113 30053 30113  0   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30117 98   17 00:28 pts/300:01:15 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30118  0   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30119  0   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30120  0   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30121  0   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30122  0   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30123  7   17 00:28 pts/300:00:05 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30124  0   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30125  0   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30126  0   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30127  0   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30128  0   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30129  1   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30130  0   17 00:28 pts/300:00:00 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat-9.0.52/conf/logging.properties
tomcat   30113 30053 30131  0   17 00:28 pts/300

Re: how to tune cacheMaxSize

2021-08-20 Thread Christopher Schultz

Michael,

On 8/19/21 21:37, Michael Richardson wrote:

Let's deploy the oscar.war, what's the worst that can happen?

20-Aug-2021 01:36:10.129 WARNING [Catalina-utility-1] 
org.apache.catalina.webresources.Cache.getResource Unable to add the resource 
at [/WEB-INF/classes/oscar/ocan/testdata/ocan_v1.0.1.xml] to the cache for web 
application [/oscar] because there was insufficient free space available after 
evicting expired cache entries - consider increasing the maximum size of the 
cache
... repeated many times.

This was among the original message that lead to this original subject line.


Hmm. Given that file name, it looks like the OSCAR WAR file ships with 
testing data inside of it. Tomcat tries to cache items which is why you 
are getting this warning.


For now, I think you can safely ignore these warnings. They will only 
(negatively) affect the performance of your Tomcat/OSCAR deployment, but 
they shouldn't break anything.


The maximum cache size is set by default to 10MiB. If you have more RAM, 
feel free to increase that number as high as you feel is appropriate.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Help Needed

2021-08-18 Thread Christopher Schultz

Mohan,

On 8/8/21 08:45, Mohan T wrote:

There is no specific upgrade to the environment.


Did you see the reply to your message I sent on August 6th?

We are introducing new components and the permission is being set for 
them in catalina.policy file.


Are your JAR files signed? The error says they are not signed. (And 
presumably you are requiring them to be signed.)



Attaching the Catalina.policy file for reference.


Your attachment has been stripped. Find another way to communicate the
policy. Copy/paste in the message ought to work.


openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-b12)
OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode)


FYI This is also quite old.

-chris


*From:*Mohan T
*Sent:* 07 August 2021 08:00
*To:* 'Tomcat Users List' 
*Subject:* RE: Help Needed

Dear All,

Any inputs on this. We are not getting a break in this.

Kindly help us in taking things forward.

Thanks

Mohan

*From:*Mohan T
*Sent:* 06 August 2021 09:21
*To:* Tomcat Users List >

*Subject:* Help Needed

Dear All,

*/_We are using Tomcat 8.5 on Suse LINUX. _/*

We enabled JAvA security in  tomcat and invoking the Catalina.sh. We are 
facing some permission issues in the environment.


We could see the below error messages.

access: access allowed ("java.util.logging.LoggingPermission" "control")

java.lang.Exception: Stack trace

     at java.lang.Thread.dumpStack(Thread.java:1336)

     at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:419)


     at 
java.security.AccessController.checkPermission(AccessController.java:884)


     at 
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)


     at 
java.util.logging.LogManager.checkPermission(LogManager.java:1586)


     at java.util.logging.Logger.checkPermission(Logger.java:422)

     at java.util.logging.Logger.removeHandler(Logger.java:1764)

     at 
org.apache.juli.ClassLoaderLogManager.resetLoggers(ClassLoaderLogManager.java:393)


     at 
org.apache.juli.ClassLoaderLogManager.shutdown(ClassLoaderLogManager.java:377)


     at 
org.apache.juli.ClassLoaderLogManager$Cleaner.run(ClassLoaderLogManager.java:81)


policy: getPermissions:

     PD CodeSource: 
(file:/home/ilas/tomcat8.5_tech/apache-tomcat-8.5.35/bin/tomcat-juli.jar 
)


     PD ClassLoader: sun.misc.Launcher$AppClassLoader@3d4eac69 



     PD Principals: 

policy: evaluate codesources:

     Policy CodeSource: (file:/usr/java/jdk1.8.0_162/jre/lib/- signer certificates>)


     Active CodeSource: 
(file:/home/ilas/tomcat8.5_tech/apache-tomcat-8.5.35/bin/tomcat-juli.jar 
)


Thanks

Mohan

DISCLAIMER: This communication contains information which is 
confidential and the copyright of Ramco Systems Ltd, its subsidiaries or 
a third party (“Ramco”). This email may also contain legally privileged 
information. Confidentiality and legal privilege attached to this 
communication are not waived or lost by reason of mistaken delivery to 
you.This email is intended to be read or used by the addressee only. If 
you are not the intended recipient, any use, distribution, disclosure or 
copying of this email is strictly prohibited without the express written 
approval of Ramco. Please delete and destroy all copies and email Ramco 
at le...@ramco.com immediately. Any views expressed in this 
communication are those of the individual sender, except where the 
sender specifically states them to be the views of Ramco. Except as 
required by law, Ramco does not represent, warrant and/or guarantee that 
the integrity of this communication has been maintained nor that the 
communication is free of errors, virus, interception or interference. If 
you do not wish to receive such communications, please forward this 
communication to market...@ramco.com and express your wish not to 
receive such communications henceforth.



-
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: how to tune cacheMaxSize

2021-08-18 Thread Christopher Schultz

Michael,

On 8/17/21 12:31, Michael Richardson wrote:


Christopher Schultz  wrote:
 > Not at all. EC2 is entirely reasonable for such purposes. Amazon will
 > even grant you a signed BAA if you ask for one.

Canada is not the US, and OHIP has rules differently than others.


True, but several Quebecois Universities doesn't seem to have a problem 
with Amazon Montreal. :)



And the clinic would like to survive having our third-world telco go down.


LOL. At first, I was thinking "Amazon US" was the "third-world telco", 
then it occurred to me that you meant your own connection :)



 >> No, I'm not building myself.  There is an oscar.deb, which btw,
 >> results in the same 100%.

 > Okay, good. Does OSCAR distribute the .deb file? I'm ... weirdly
 > surprised by that.

OSCAR has a .deb that tries to be all singing, all dancing.
It's not the only solution.


Well, privately-distributed .deb files are really just a "help" to 
system admins, as long as the admin agrees with everything the packager 
has done. It sounds like the .deb package is really built for dev-test 
and not for production. Shame. You should ask them to offer both.



 >> It also does other stuff like configure mariadb locally (which I don't
 >> want).

 > Interesting. You want control over your own database, or you don't want
 > the db to be local (e.g. you want a remote db)?

Exactly.

 >> This is the only time I've seen this error, I've also used the manager
 >> web application before.

 > Hmm. Same error there? Or same 100% CPU circumstances there?

Same 100% CPU.

 >> I tried that.  It says something about there being no socket open.  My
 >> impression is that "jstack" was an Oracle Java only tool.

 > Nope, it's in all of the OpenJDK builds. You might need a "JDK" instead
 > of a"JRE".

okay, I'll try again and post the result.

 > When you issue "kill -3", the thread dump should appear on stdout,
 > which should be captured in logs/catalina.[date].log. If that's not
 > happening, then I'm a bit confused...

It's not happening.


/me is confused.


 > Okay, try this:

 > 1. Stop Tomcat, clear all logs, delete your oscar.war file and the
 > exploded directory in CATALINA_BASE/webapps/oscar (or wherever your
 > appBase points to).  2. Copy your oscar.war file into appBase, making
 > sure that operation completes 3. Start Tomcat, but like this instead of
 > what you usually do:

 >$ sudo -iu tomcatuser $ $CATALINA_BASE/bin/catalina.sh run

 > That "run" is important: it will run Tomcat in the current console
 > instead of in the background as a service. You'll get stdout directly
 > on your console, no log files to worry about.

okay.


The suspense is killing me.

BTW I'd be happy to continue helping-out via this mailing list for free, 
at least until I get busy or lose interest. I'm also happy to consult 
off-list for NOT free if you need that kind of attention. I have some 
experience with production health care systems running on Tomcat + 
MySQL/MariaDB.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: how to tune cacheMaxSize

2021-08-17 Thread Christopher Schultz

Michael,

On 8/16/21 16:14, Michael Richardson wrote:


Christopher Schultz  wrote:
 > Okay, all that looks fine to me, except the "9.0.16" part. That version
 > is *very/8 old. I see you are running Ubuntu: are you running the
 > latest release? That 9.0.16 number if rinning a bell about an older
 > release which was capped at 9.0.16. YOu might want to consider
 > upgrading everything once you figure all of this out. No need to muddy
 > the waters quite, yet, though.

Ubuntu 18.04.  I shall look for a ppa with newer tomcat.
It's a VM, I could go to Core 20.


Okay. We can get to that, later, but it's probably a good idea since 
it's probably nearing EOL. (I didn't bother checking.)



 > A few more things:

 > 1. It takes 12 seconds to initialize the server? That seems
 > ... slow. Is this on Amazon? What instance type? The memory size
 > 3.75GiB is ringing a bell, too.

I could go to 8G for the VM if you think that's relevant.
My reading is that I'm not even using 1G of ram at this point.


Nah, it's not important. But if it were an EC2 VM it's entirely possible 
that you are simply asking too much of it and the slowness/100% CPU is 
just "it's trying to do too much work."



No, it's not in Amazon.  It's a Dell Xeon workstation in the basement of my
wife's clinic.  Patient record confidentiality would probably contraindicate 
EC2 :-)


Not at all. EC2 is entirely reasonable for such purposes. Amazon will 
even grant you a signed BAA if you ask for one.



 > 2. You shouldn't have the "docs"
 > project depployed on a production system.

I installed it there to grep/read them, then decided that I'd install
that on my desktop.
Okay, no problem. As long as you know what you are doing. Often, seeing 
the "docs" application deployed means (somewhat ironically) "someone 
didn't read the documentation for going to production."



 > 3. I don't see any message
 > "Deploying deployment descriptor blah/blah/oscar/blah"

Yes, exactly.


Hmm.


Christopher Schultz  wrote:
 >> 14-Aug-2021 17:16:45.464 SEVERE [Catalina-utility-1]
 >> org.apache.catalina.startup.HostConfig.deployWAR Error deploying web
 >> application archive [/var/lib/tomcat9/webapps/oscar.war]
 >> java.lang.IllegalStateException: Error starting child at
 >> 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:716)
 >> ...
 >>

 > That certainly looks bad. Are you building OSCAR yourself, or is it
 > pre-built? I'm assuming that all local customizations are done using
 > separate config files or in the database, right? Can you get a fresh
 > copy of the oscar.war file?

No, I'm not building myself.
There is an oscar.deb, which btw, results in the same 100%.


Okay, good. Does OSCAR distribute the .deb file? I'm ... weirdly 
surprised by that.



It also does other stuff like configure mariadb locally (which I don't want).


Interesting. You want control over your own database, or you don't want 
the db to be local (e.g. you want a remote db)?



But, I've used the oscar.war from that deb, and also the oscar.war which
is on the bare-metal version that is running.


Okay.


 >> 14-Aug-2021 17:16:45.506 INFO [Catalina-utility-1]
 >> org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
 >> application archive [/var/lib/tomcat9/webapps/oscar.war] has finished
 >> in [1,684] ms

 > That's nice and fast.

No, it's in error.


:) I was mostly joking.


 >> 14-Aug-2021 17:16:55.661 INFO [Catalina-utility-2]
 >> org.apache.catalina.startup.HostConfig.undeploy Undeploying context
 >> [/oscar] 14-Aug-2021 17:16:58.286 INFO [Catalina-utility-2]
 >> org.apache.catalina.startup.HostConfig.deployWAR Deploying web
 >> application archive [/var/lib/tomcat9/webapps/oscar.war]

 > Strange that it's deploying, then undeploying, then deploying again. Is
 > it possible that there are weird file timestamps? Maybe something in
 > the future?

I think that the cp of the 220M oscar.war hasn't completed when it starts
that first deploy.  That's why the ZIP error.

 >> My guess is that the cp oscar.war /var/lib/tomcat9/webapps hadn't
 >> actually finished yet when it tried to deploy it.

 > That can definitely break things. If you are going to drop a WAR file
 > on Tomcat, make sure that either Tomcat isn't running, or you are using
 > the Manager web application to upload-and-deploy the WAR file which
 > protects you from deploying mid-copy.

This is the only time I've seen this error, I've also used the manager web
application before.


Hmm. Same error there? Or same 100% CPU circumstances there?


 >> So the po

Re: Getting some peculiar TLS results in Tomcat 7

2021-08-16 Thread Christopher Schultz

Mark,

On 8/13/21 21:13, Mark Eggers wrote:

On 8/13/2021 5:27 PM, James H. H. Lampert wrote:

While we've been systematically updating our customer boxes, a few of
our customer boxes are still on Tomcat 7.

I've got the following Connector tag set up in server.xml:


compressableMimeType="text/html,text/xml,text/plain,text/css,
 text/javascript,text/json,application/x-javascript, 
application/javascript,application/json" />
And yet SSLLabs tells me the box in question is still accepting TLS 
1.0 and TLS 1.1.


Can anybody shed any light on this? (And yes, I know, "alias" should 
be "keyAlias," but it's the only chain in the keystore, so it 
shouldn't make any difference.)


https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

Search for sslEnabledProtocols


+1

In later versions of Tomcat, there is only one "protocols" configuration 
property, and it does "What you expect". The reason for the two separate 
configuration settings "sslProtocols" and "sslEnabledProtocols" (oh and 
also "SSLProtocol" for APR) is historical.


Down in the JSEE API, you need to request an SSLContext object from a 
factory method, and you need to tell that factory what "protocol" you 
want. There are a whole host of things you can pass to that factory 
method like "TLSv1" and stuff like that, but the documentation says "the 
returned object will support that protocol; other protocols may be 
supported as well." And guess what? The object you get always supports 
all the protocols!


So you need to tell Java what "protocol" you want, but then you may have 
to customize the "enabled protocols" if you want to specifically 
*disable* a certain protocol version. It's only after 2000 or so that 
anybody has been interested in *disabling* anything. Before that, it was 
all about being as accepting as possible. These days, 
security-mindedness has taken-over and it's appropriate to restrict 
things, disable old protocols, etc. And yet the configuration still exists.


In 8.5, we replaced everything with "protocols" which will give you the 
exact settings you expect. But for 7.0.x, you still need to set 
"sslEnabledProtocols". You should probably never bother setting 
"sslProtocol".


I note that you are using "sslProtocol" (which is slightly misspelled 
SSLProtocol; I'm not sure if that's a problem) but you are also 
explicitly specifying protocol="org.apache.coyote.http11.Http11Protocol" 
(which is a confusingly-named configuration setting which picks the 
class used to actually handle the byte-level conversation with the 
client). SSLProtocol is documented to only be used with the APR 
connector, and you are specifically requesting the "blocking Java-based" 
connector. So I would guess that SSLProtocol is being completely 
ignored. Do you log files say anything about not finding a matching 
setting for that configuration property? I would guess "yes, it's in the 
logs and we never noticed it."


I think you want your Tomcat 7.x configuration to look like this:

protocol="org.apache.coyote.http11.Http11Protocol" 
sslEnabledProtocols="TLSv1.2"


... and have no other protocol-related configuration settings.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: trying to deploy oscar (was Re: how to tune cacheMaxSize )

2021-08-16 Thread Christopher Schultz

Michael,

On 8/14/21 16:05, Michael Richardson wrote:


<#secure method=pgpmime mode=sign>

Extracts of log, full log at URL below. 18k.

14-Aug-2021 17:16:43.821 INFO [Catalina-utility-1] 
org.apache.catalina.startup.HostConfig.deployWAR Deploying web application 
archive [/var/lib/tomcat9/webapps/oscar.war]
14-Aug-2021 17:16:44.005 SEVERE [Catalina-utility-1] 
org.apache.catalina.startup.ContextConfig.beforeStart Exception fixing docBase 
for context [/oscar]
  java.util.zip.ZipException: zip END header not found
  ...

14-Aug-2021 17:16:45.464 SEVERE [Catalina-utility-1] 
org.apache.catalina.startup.HostConfig.deployWAR Error deploying web 
application archive [/var/lib/tomcat9/webapps/oscar.war]
  java.lang.IllegalStateException: Error starting child
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:716)
 ...



That certainly looks bad. Are you building OSCAR yourself, or is it 
pre-built? I'm assuming that all local customizations are done using 
separate config files or in the database, right? Can you get a fresh 
copy of the oscar.war file?



14-Aug-2021 17:16:45.506 INFO [Catalina-utility-1] 
org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application 
archive [/var/lib/tomcat9/webapps/oscar.war] has finished in [1,684] ms


That's nice and fast.


14-Aug-2021 17:16:55.661 INFO [Catalina-utility-2] 
org.apache.catalina.startup.HostConfig.undeploy Undeploying context [/oscar]
14-Aug-2021 17:16:58.286 INFO [Catalina-utility-2] 
org.apache.catalina.startup.HostConfig.deployWAR Deploying web application 
archive [/var/lib/tomcat9/webapps/oscar.war]


Strange that it's deploying, then undeploying, then deploying again. Is 
it possible that there are weird file timestamps? Maybe something in the 
future?



My guess is that the cp oscar.war /var/lib/tomcat9/webapps hadn't actually
finished yet when it tried to deploy it.


That can definitely break things. If you are going to drop a WAR file on 
Tomcat, make sure that either Tomcat isn't running, or you are using the 
Manager web application to upload-and-deploy the WAR file which protects 
you from deploying mid-copy.



So the first 1.684ms attempt fails,
and then it tried again. (Times are UTC)

oscar-serv03-[~] root 30 #netstat -tan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State
tcp0  0 127.0.0.53:53   0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:3306  0.0.0.0:*   LISTEN
tcp0  0 192.168.2.13:22 192.168.2.3:56896   ESTABLISHED
tcp0  0 192.168.2.13:22 192.168.2.3:56898   ESTABLISHED
tcp6   0  0 :::22   :::*LISTEN
tcp6   0  0 :::8080 :::*LISTEN

So the port is open, so I attempt to visit the /manage  URL

oscar-serv03-[~] root 31 #netstat -tan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State
tcp0  0 127.0.0.53:53   0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:3306  0.0.0.0:*   LISTEN
tcp0  0 192.168.2.13:22 192.168.2.3:56896   ESTABLISHED
tcp0  0 192.168.2.13:22 192.168.2.3:56898   ESTABLISHED
tcp6   0  0 :::22   :::*LISTEN
tcp6   0  0 :::8080 :::*LISTEN
tcp6 559  0 192.168.2.9:8080192.168.2.3:37486   ESTABLISHED

And it just stalls.


Is there anything between Tomcat and your web browser? Like a reverse 
proxy, firewall, etc.? What URL are you trying to hit?



I went to eat lunch and watch TV, so waited a few hours, and it's the same
afterwards.  Note that it never told me that it had finished deploying this
war.

I've tried kill-3 repeatedly, on the main PID of the process, and gotten no 
output.


Anything in the other log files?

Instead of kill -3, what if you use the "jstack" utility and provide the 
PID of the running process? (You'll want to provide the PID of the 
parent JVM process, not a specific thread.)


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: how to tune cacheMaxSize

2021-08-16 Thread Christopher Schultz

Michael,

On 8/14/21 11:56, Michael Richardson wrote:
>
> Thank you for the reply.
>
> Christopher Schultz  wrote:
>  > On 8/12/21 11:05, Michael Richardson wrote:
>  >> I am trying to deploy OSCAR-EMR
>
Wow, that still exists? I remember more than a decade ago being 
asked to integrate a product at $work with that thing as a demo.
We never did, because the market seemed not to really exist. I see 
you are in Canada. I know OSCAR same from McMaster University. Does

it have a good ecosystem and install base in CA? >
Yes, it's still quite popular among many Ontario (and I'm told BC) 
doctors, because it has good integration with the provincial billing

system. Doctor like it because the price appears right, and doctors
don't get rich by spending money. >
There are a number of support companies that install it, but my 
experience (via my wife) is that their do a rather poor job of 
installation. No understanding of database encryption, replication, 
or even how to enable https.


That's ... really bad.

There seems to be developer still working on it, according to the 
bitbucket git commit lot.  But, the public community around it seems

to have died, as far as I can tell.
That's a shame. As I have discovered through years of working with ASF 
and other projects, the community is far more important than the actual 
product itself. A good community can fix a bad product, but the reverse 
is not true. I am a member of other communities where the project 
ignores the community, which is also Not Good. Not naming any names. :)


On 8/14/21 12:53, Michael Richardson wrote:

This time, after apt-get purge tomcat9 and re-install, I seem to be in 100%
CPU before I've deployed oscar or even updated the tomcat-users.xml to
enable the manager login.

HTOP view attached at bottom.
(4 virtual CPUs, 4G of ram. KVM VM running ubuntu 18.04, on a server running
ubuntu core 20)

oscar-serv03-[~] root 276 #netstat -tan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State
tcp0  0 127.0.0.53:53   0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:3306  0.0.0.0:*   LISTEN
tcp0  0 192.168.2.13:22 192.168.2.3:56874   ESTABLISHED
tcp0  0 192.168.2.13:22 192.168.2.3:56556   ESTABLISHED
tcp6   2  0 :::8080 :::*LISTEN
tcp6   0  0 :::22   :::*LISTEN
tcp6 747  0 192.168.2.9:8080192.168.2.3:37450   CLOSE_WAIT
tcp6 489  0 192.168.2.9:8080192.168.2.3:37452   ESTABLISHED

I find it weird that I have no catalina.out file:

oscar-serv03-[~] root 274 #ls -l /var/log/tomcat9
total 8
-rw-r- 1 tomcat tomcat 5233 Aug 14 16:38 catalina.2021-08-14.log
-rw-r- 1 tomcat tomcat0 Aug 14 16:37 localhost.2021-08-14.log
-rw-r- 1 tomcat tomcat0 Aug 14 16:38 localhost_access_log.2021-08-14.txt


You must be running usingh jsvc, which creates the catalina.[date].log 
file instead. No worries, there.



I include cataline.2021-08-14.log here.
Also now at: https://www.sandelman.ca/tmp/terapia9/catalina.2021-08-14.log

ubuntu says that I have a new kernel and I should reboot, so I'll do another
purge, reboot, and then reinstall again.

14-Aug-2021 16:38:02.279 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server version name:   
Apache Tomcat/9.0.16 (Ubuntu)
14-Aug-2021 16:38:02.302 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server built:  
Sep 11 2019 19:47:51 UTC
14-Aug-2021 16:38:02.320 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Server version number: 
9.0.16.0
14-Aug-2021 16:38:02.343 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log OS Name:   
Linux
14-Aug-2021 16:38:02.345 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log OS Version:
5.4.0-80-generic
14-Aug-2021 16:38:02.348 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Architecture:  
amd64
14-Aug-2021 16:38:02.374 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Java Home: 
/usr/lib/jvm/java-11-openjdk-amd64
14-Aug-2021 16:38:02.380 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log JVM Version:   
11.0.11+9-Ubuntu-0ubuntu2.18.04
14-Aug-2021 16:38:02.382 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:
Ubuntu
14-Aug-2021 16:38:02.384 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: 
/var/lib/tomcat9
14-Aug-2021 16:38:02.385 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: 
/usr/share/tomcat9

Re: Error loading PKCS12 keystore, java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.

2021-08-16 Thread Christopher Schultz

All,

On 8/16/21 10:32, Christopher Schultz wrote:

All,

Anyone ever seen this before?

I'm using an older Tomcat (7.0.x) on an older Java (1.7.0_80) along with 
a certificate from Let's Encrypt. This was the server I used to 
initially develop my "Let's Encrypt Apache Tomcat" presentation and 
scripts, so I am familiar with the process and everything that needs to 
happen.


I was updating the script to use the new snap-based certbot instead of 
the older one which is fraught with dependency issues, etc. and I'm able 
to renew the certificate just fine, but after assembling the PKCS12 
keystore, I'm getting this error when Tomcat attempts to start the HTTPS 
connector.


My old script first converted from raw PEM files to PKCS12 using the 
"openssl pkcs12" command, then converted to JKS using Java's "keytool". 
I decided to cut-out the middle-man and use PKCS12 files directly this 
time.


Here is my (sanitized)  configuration:

     

I added the "truststoreType" just in case Tomcat was using the 
keystoreType as the truststoreType, and defaulting to using the keystore 
as the truststore. None of those things are true, but I left it in the 
configuration.


When using "keytool" on the command-line to dump the certs, I get no 
errors and the keystore contains the expected data.


Here is the command I use to assemble the pkcs12 file:

   openssl pkcs12 -export -in "${LE_BASE}/cert.pem" -inkey 
"${LE_BASE}/privkey.pem" \

    -certfile "${LE_BASE}/fullchain.pem" \
    -out "${CATALINA_BASE}/${HOSTNAME}.p12" -name tomcat \
    -passout "pass:changeit"


Here is the complete stack trace of the error:

Aug 16, 2021 10:22:23 AM org.apache.coyote.AbstractProtocol start
SEVERE: Failed to start end point associated with ProtocolHandler 
["http-nio-8443"]

java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
     at 
sun.security.util.DerInputStream.getLength(DerInputStream.java:561)

     at sun.security.util.DerValue.init(DerValue.java:365)
     at sun.security.util.DerValue.(DerValue.java:320)
     at 
sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1233)

     at java.security.KeyStore.load(KeyStore.java:1226)
     at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:392) 

     at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustStore(JSSESocketFactory.java:343) 

     at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustManagers(JSSESocketFactory.java:599) 

     at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustManagers(JSSESocketFactory.java:511) 

     at 
org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:493)
     at 
org.apache.tomcat.util.net.AbstractEndpoint.start(AbstractEndpoint.java:647) 

     at 
org.apache.coyote.AbstractProtocol.start(AbstractProtocol.java:449)
     at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1007)
     at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
     at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:459) 

     at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
     at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:731) 

     at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)

     at org.apache.catalina.startup.Catalina.start(Catalina.java:689)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 

     at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 


     at java.lang.reflect.Method.invoke(Method.java:606)
     at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:321)
     at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455)

Aug 16, 2021 10:22:23 AM org.apache.catalina.core.StandardService 
startInternal
SEVERE: Failed to start connector 
[Connector[org.apache.coyote.http11.Http11NioProtocol-8443]]
org.apache.catalina.LifecycleException: Failed to start component 
[Connector[org.apache.coyote.http11.Http11NioProtocol-8443]]
     at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
     at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:459) 

     at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
     at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:731) 

     at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)

     at org.apache.catalina.startup.Catalina.start(Catalina.java:689)
     at sun.reflect.NativeMethodAccessorImpl.in

Error loading PKCS12 keystore, java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.

2021-08-16 Thread Christopher Schultz

All,

Anyone ever seen this before?

I'm using an older Tomcat (7.0.x) on an older Java (1.7.0_80) along with 
a certificate from Let's Encrypt. This was the server I used to 
initially develop my "Let's Encrypt Apache Tomcat" presentation and 
scripts, so I am familiar with the process and everything that needs to 
happen.


I was updating the script to use the new snap-based certbot instead of 
the older one which is fraught with dependency issues, etc. and I'm able 
to renew the certificate just fine, but after assembling the PKCS12 
keystore, I'm getting this error when Tomcat attempts to start the HTTPS 
connector.


My old script first converted from raw PEM files to PKCS12 using the 
"openssl pkcs12" command, then converted to JKS using Java's "keytool". 
I decided to cut-out the middle-man and use PKCS12 files directly this time.


Here is my (sanitized)  configuration:



I added the "truststoreType" just in case Tomcat was using the 
keystoreType as the truststoreType, and defaulting to using the keystore 
as the truststore. None of those things are true, but I left it in the 
configuration.


When using "keytool" on the command-line to dump the certs, I get no 
errors and the keystore contains the expected data.


Here is the command I use to assemble the pkcs12 file:

  openssl pkcs12 -export -in "${LE_BASE}/cert.pem" -inkey 
"${LE_BASE}/privkey.pem" \

   -certfile "${LE_BASE}/fullchain.pem" \
   -out "${CATALINA_BASE}/${HOSTNAME}.p12" -name tomcat \
   -passout "pass:changeit"


Here is the complete stack trace of the error:

Aug 16, 2021 10:22:23 AM org.apache.coyote.AbstractProtocol start
SEVERE: Failed to start end point associated with ProtocolHandler 
["http-nio-8443"]

java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
at 
sun.security.util.DerInputStream.getLength(DerInputStream.java:561)

at sun.security.util.DerValue.init(DerValue.java:365)
at sun.security.util.DerValue.(DerValue.java:320)
at 
sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1233)

at java.security.KeyStore.load(KeyStore.java:1226)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:392)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustStore(JSSESocketFactory.java:343)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustManagers(JSSESocketFactory.java:599)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustManagers(JSSESocketFactory.java:511)
at 
org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:493)
at 
org.apache.tomcat.util.net.AbstractEndpoint.start(AbstractEndpoint.java:647)
at 
org.apache.coyote.AbstractProtocol.start(AbstractProtocol.java:449)
at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1007)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:459)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:731)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)

at org.apache.catalina.startup.Catalina.start(Catalina.java:689)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:321)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455)

Aug 16, 2021 10:22:23 AM org.apache.catalina.core.StandardService 
startInternal
SEVERE: Failed to start connector 
[Connector[org.apache.coyote.http11.Http11NioProtocol-8443]]
org.apache.catalina.LifecycleException: Failed to start component 
[Connector[org.apache.coyote.http11.Http11NioProtocol-8443]]
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:459)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:731)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)

at org.apache.catalina.startup.Catalina.start(Catalina.java:689)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at 

Re: [OT] Other connection may not see updated date immediately

2021-08-13 Thread Christopher Schultz

W,

On 8/11/21 11:48, W wrote:

On Wednesday, August 11, 2021, 07:00:22 AM PDT, Christopher Schultz
 wrote:


W, On 8/9/21 12:04, W wrote:>> Hi,I have a web application. It is a
java-jsp-tomcat-mysql. It is working, but sometimes, it is slow. For
each data update statement, it is not slow: the next jsp page shows
promptly. But the next page does not see updated data. I wait a coupe
seconds, refresh the page, the updated date shows. Each connection is
from tomcat.DataSource, so I believe each jsp page may use a
different database connection. So, mysql inside is slow. Anything I
can do?>> I checked server cpu and memory. Cpu is 20%, memory is
lower than 50%.> Everything is running on one server machine, one
tomcat, one mysql, runs on Ubuntu: 4.15.0-54-generic, Tomcat/9.0.16,
mysql: 8.0.21.>> Any information would be appreciated. Thanks in
advance.

This is certainly an application issue, so I have marked this
thread as "off-topic". That doesn't mean we can't help. Please
confirm the following: 1. An initial request arrives on the server
which executes a SQL DML query, which changes some data in your
database. The transaction is>committed. The response is sent to the
client.

>

The query is commited, otherwise I would not see updated data after I
refresh the next page.


So you steps 1 and 2 occur rapidly, you see old data, but if you RELOAD 
the page shown in step 2, the data refreshes?



2. A second request arrives *after the completion of the first
request and queries the data which was changed in #1 above. The
data retrieved from the database appears to have values which are
"old" -- that is, the>value that was expected before #1 above
occurred.

>

Yes.

>
Some questions: * Are you sure that #2 happens fully after #1? How 
are you sure?

Yes. Otherwise the second page would not appear.
You didn't say how you were sure. How does the user get from #1 to #2? 
HTTP redirect?


* Are you absolutely sure you are querying the *same* data from 
the database?

Yes.

Okay.


* Are you absolutely sure that there is no "step
1.5" where the data are>changed *back* to their original values?
How are you sure? Yes.


Okay.


* What is the "transaction isolation level"
of your database connections? Do you execute your query in #2
within a transaction?

>

I did not set, it should be default. REPEATABLE READ?


The JDBC default should be whatever the driver supplies, so it depends 
upon your database driver.



I believe, correct me if I am wrong:tomcat.connection.commit() calls
mysql.connection.commit()


I don't know what tomcat.connection.commit() means. I also don't know 
what mysql.connection.commit() means. You would need to provide sample 
code including full class names and how you are obtaining various object 
references.


If you are using either of Tomcat's built-in JDBC connection pools, then 
calling java.sql.Connection.commit(() on the Connection object you 
obtained from the JDBC connection pool should indeed call the MySQL 
driver's commit() method.



Is it possible that actually
operating-system-file-writing not finished when the calls return?


No. Assuming you did something like this:

UPDATE user SET name='Chris' WHERE id=10;
COMMIT;

Then any subsequent thread which performs a query like this:

SELECT name FROM user WHERE id=1;

Should get the value 'Chris'. That's the whole contract that the 
database enforces. Caching, buffering, etc. are not your concern; you 
can rely on the database to implement things properly. (Well, unless you 
are using MySQL 2.x or something like that.)


If you are seeing an "old" value for the user's name, it's due to one of 
several possibilities:


a. Your SELECT happens before the COMMIT
b. Your SELECT happens in a transaction where you started the 
transaction before the COMMIT was executed
c. You are caching data in your own application and no SELECT is being 
executed



or
there is a delay, or updating query has lower priority


In relational databases, unless you try very hard, all writes are 
synchronous. So once your Statement.execute() returns (if not in a 
transaction) or Connection.commit() returns (if you are using a 
transaction), then the data is written and visible to all threads, 
connections, etc. This behavior is known as "Atomicity" and is the "A" 
in the term "ACID" when referring to data-storage systems. It is very 
closely related to "Consistency" which is the "C".


Atomicity requires that the effects of the whole transaction appear to 
occur at the same time (or they fail and are rolled-back). Consistency 
requires that all observers see the same thing (unless they are in 
transactions that started before some related COMMIT).



either tomcat or mysql?
Tomcat passes your method calls directly to the driver. Tomcat itself 
performs no JDBC operations when you make your calls.



The following connectio

Re: how to tune cacheMaxSize

2021-08-13 Thread Christopher Schultz

Michael,

On 8/12/21 11:05, Michael Richardson wrote:

I am trying to deploy OSCAR-EMR


Wow, that still exists? I remember more than a decade ago being asked to 
integrate a product at $work with that thing as a demo. We never did, 
because the market seemed not to really exist. I see you are in Canada. 
I know OSCAR same from McMaster University. Does it have a good 
ecosystem and install base in CA?



in a new location (for my wife's office), with better encryption and
database replication.  We have an existing bare-metal instance
running that her boss assembled. It's fragile, but it runs.

In both ubuntu 18.04 and devuan beowulf VMs, I can start up tomcat9
and openjdk (8 or 11) and talk to the tomcat9-admin interface.

I then deploy the oscar.war to /var/lib/tomcat19/webapps, and observe
in htop that I get 5-6 threads that get very busy, as it extracts the app.


Hmm. I wouldn't expect more than 1 thread to get busy extracting that 
application.



Then, port 8080 stops responding.  And also I see new connections just stall.

I wind up with two threads of java each chewing 100% of the CPU.
strace on it doesn't help, telling me that it looks like 32-bit code.
I think that the JIT might confuse it.  Are these threads doing I/O or system
calls? I can't tell.

(I can see the new connections stalling in netstat -tan, with unprocessed
bytes in the recv Q)

If I stop the java processes, and restart them, then they seem to continue
the "deploy", even if I have removed the oscar.war and
/var/lib/tomcat19/webcaps/oscar directory.  Clearly something else remembers
it.  When that happens, I get *no output* in catalina.out.


What makes you think those threads are continuing to deploy the WAR 
file? If the WAR file is missing, deployment would be most difficult. 
When you remove the WAR file, are you also removing the 
exploded-WAR-directory that Tomcat creates during the deployment of the WAR?



And _apt-get purge tomcat9_, and re-install, gets me back to the start, but I'd
like to understand where the deploy is being recorded and how I can undo only
that.

I will get one message that I am trying to look at the cacheMaxSize
value in /etc/tomcat9/context.xml.
   

My question is, if the cacheMaxSize is too small, will it lead to some kind
of continual cache replacement where it never actually starts up?
If so, is there some debug that would let me estimate what an appropriate
cache size is?  The running machine has:


(I initially suspected the whole /dev/random issue, so I moved the TLS
to a proxy-pass Apache, but also I have virtio /dev/random, and I also
ln /dev/urandom to /dev/random just in case...)


Okay, I don't mean to sound mean, but it sounds like you have no idea 
what's going on, here. There are probably several issues, but let's 
start with the first one: what are those threads doing at 100% CPU.


You don't have a /dev/random problem, because really nobody has that 
problem anymore. Also, the /dev/random problem manifests as a "hung" 
server with *zero* CPU usage.


Reset your environment back to the beginning: fresh Tomcat, no log 
files, no WAR deployed or anything like that. Start up Tomcat and make 
sure everything looks good so far. Then deploy the WAR file and let 
everything go to hell. After things settle down and you are in your "2 
threads eating the CPU" situation, do the following:


1. Grab the log file in CATALINA_BASE/logs/catalina.out (or similar)
2. Take a thread-dump of the running JVM[1]

Sanitize the files in whatever way is necessary and post them back to 
this mailing list and we'll take a look.


-chris

[1] 
https://cwiki.apache.org/confluence/display/TOMCAT/HowTo#HowTo-HowdoIobtainathreaddumpofmyrunningwebapp?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Clarification on behaviour after pool exhaustion happen in tomcat jdbc pool 9.0.16

2021-08-13 Thread Christopher Schultz

Sampath,

On 8/12/21 07:02, Sampath Rajapakshe wrote:

Hi Chris,

Thanks for the detailed explanation, yes, we tried with abandoned true logs
and found an issue with our code base as well.
It seems we had a case where a single thread creates a new connection and
before closing that connection creates a new connection and closes that new
connection and then afterwards closes the initial connection. So in a
scenario where a huge traffic goes through the same logic path pool gets
exhausted due to all threads waiting to create another connection before
closing their initial connection.

After fixing that issue, now the system runs without pool exhaustion.
So thank you very much for your explanations.



Yes, this is item #1 in my (ancient!) blog post's "general tips" section:

1. In development, set your connection pool to a fixed size of 1 
connection. [...]


If you had set you pool size to "exactly 1" in development, you would 
have caught this problem long ago.


-chris


On Wed, Aug 11, 2021 at 7:25 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Sampath,

On 8/9/21 01:45, Sampath Rajapakshe wrote:

In our case, we know the reason for the pool exhausted behaviour,
there are slow queries and also due to high TPS where pool is not
enough. So we are expected to get pool exhaustion with current
configurations.

Ok.


What we wanted to verify was the behaviour after pool exhaustion. Do
the current executing connections continue their executions during
pool exhausted duration?

I would not expect the connection pool to actively kill connections
unless explicitly configured to do so. Usually, connections that are
"orphaned" will stay that way, "just in case". If you aren't seeing
exceptions being thrown due to "connection is closed" or some such
thing, you are probably okay as far as the long-running queries are
concerned.

Do you know in advance which queries will take a "long time"? Perhaps
you'd like to use a different connection pool for those long-running
queries -- one where the timeout is significantly higher.


As per our observations, they do not, and connections are stuck
without executing any queries until maxWait. is that the expected
behaviour after pool exhaustion?

Let's be clear what we mean when we say "connection". The only
"connection" here that is relevant is the "connection to the database."
It sounds like you mean "incoming HTTP connection" whose thread will
stall if a DB connection is not immediately available from the pool.
That may be true, but the "(HTTP) connection" isn't waiting for a DB
connection; the request-processing thread is waiting for a DB connection.

Do you mean "behavior of connections checked-out and used long-term" or
do you mean "behavior of the pool when all connections are checked-out
and we need a NEW one?"

I assume the second question is what you are asking.

When all the connections are being used, the pool usually stalls,
meaning that your code will just sit there a wait (possibly forever) for
a connection. To fix that, you'd have to adjust the configuration of the
pool (e.g. add more possible connections, increase maxWait to avoid
errors). You can also usually configure the pool to allow connections
which are checked-out and not returned after a certain period of time
("abandoned" to use the Commons-Pool terminology) to be allowed to
"leak" and replenish the pool.

You didn't say which pool you were using, so I will assume you are using
the default DB connection pool based upon Apache commons-dbcp2. Here is
the documentation for that pool; you can use these configuration
settings on your  element in your web application's
META-INF/context.xml file:

https://commons.apache.org/proper/commons-dbcp/configuration.html

I recommend looking at the "abandoned"-related configuration options.

-chris


On Sat, Aug 7, 2021 at 3:43 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Sampath,

On 8/6/21 08:37, Sampath Rajapakshe wrote:

Hi All,

In my local setup before pool exhaustion exception is thrown, all the
connections seem to be in freezed and when checking processList in

mysql,

those connections are in sleep state and doesn't execute any queries.

After

waiting for maxWait period the pool exhausted exception gets thrown and
seems to reset the connections and then the queries are getting

processed

as normally.

   >

So, my question is, with pool exhausted scenarios, doesn't existing
connections execute their queries during that time(maxWait) and try to
resolve the exhausted behaviour by releasing those connections to idle
queue automatically? When checking the JMX matrix during this pool
exhausted time all the connections are in the active queue.





https://blog.christopherschultz.net/2009/03/16/properly-handling-pooled-jdbc-connections/



If not, what

Re: [OT] Other connection may not see updated date immediately

2021-08-11 Thread Christopher Schultz

W,

On 8/9/21 12:04, W wrote:

Hi,I have a web application. It is a java-jsp-tomcat-mysql. It is working, but 
sometimes, it is slow. For each data update statement, it is not slow: the next 
jsp page shows promptly. But the next page does not see updated data. I wait a 
coupe seconds, refresh the page, the updated date shows. Each connection is 
from tomcat.DataSource, so I believe each jsp page may use a different database 
connection. So, mysql inside is slow. Anything I can do?
I checked server cpu and memory. Cpu is 20%, memory is lower than 50%.
Everything is running on one server machine, one tomcat, one mysql, runs on 
Ubuntu: 4.15.0-54-generic, Tomcat/9.0.16, mysql: 8.0.21.
Any information would be appreciated. Thanks in advance.


This is certainly an application issue, so I have marked this thread as 
"off-topic". That doesn't mean we can't help.


Please confirm the following:

1. An initial request arrives on the server which executes a SQL DML 
query, which changes some data in your database. The transaction is 
committed. The response is sent to the client.


2. A second request arrives *after the completion of the first request* 
and queries the data which was changed in #1 above. The data retrieved 
from the database appears to have values which are "old" -- that is, the 
value that was expected before #1 above occurred.


Some questions:

* Are you sure that #2 happens fully after #1? How are you sure?

* Are you absolutely sure you are querying the *same* data from the 
database?


* Are you absolutely sure that there is no "step 1.5" where the data are 
changed *back* to their original values? How are you sure?


* What is the "transaction isolation level" of your database 
connections? Do you execute your query in #2 within a transaction?


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Clarification on behaviour after pool exhaustion happen in tomcat jdbc pool 9.0.16

2021-08-11 Thread Christopher Schultz

Sampath,

On 8/9/21 01:45, Sampath Rajapakshe wrote:

In our case, we know the reason for the pool exhausted behaviour,
there are slow queries and also due to high TPS where pool is not
enough. So we are expected to get pool exhaustion with current
configurations.

Ok.


What we wanted to verify was the behaviour after pool exhaustion. Do
the current executing connections continue their executions during
pool exhausted duration?
I would not expect the connection pool to actively kill connections 
unless explicitly configured to do so. Usually, connections that are 
"orphaned" will stay that way, "just in case". If you aren't seeing 
exceptions being thrown due to "connection is closed" or some such 
thing, you are probably okay as far as the long-running queries are 
concerned.


Do you know in advance which queries will take a "long time"? Perhaps 
you'd like to use a different connection pool for those long-running 
queries -- one where the timeout is significantly higher.



As per our observations, they do not, and connections are stuck
without executing any queries until maxWait. is that the expected
behaviour after pool exhaustion?
Let's be clear what we mean when we say "connection". The only 
"connection" here that is relevant is the "connection to the database." 
It sounds like you mean "incoming HTTP connection" whose thread will 
stall if a DB connection is not immediately available from the pool. 
That may be true, but the "(HTTP) connection" isn't waiting for a DB 
connection; the request-processing thread is waiting for a DB connection.


Do you mean "behavior of connections checked-out and used long-term" or 
do you mean "behavior of the pool when all connections are checked-out 
and we need a NEW one?"


I assume the second question is what you are asking.

When all the connections are being used, the pool usually stalls, 
meaning that your code will just sit there a wait (possibly forever) for 
a connection. To fix that, you'd have to adjust the configuration of the 
pool (e.g. add more possible connections, increase maxWait to avoid 
errors). You can also usually configure the pool to allow connections 
which are checked-out and not returned after a certain period of time 
("abandoned" to use the Commons-Pool terminology) to be allowed to 
"leak" and replenish the pool.


You didn't say which pool you were using, so I will assume you are using 
the default DB connection pool based upon Apache commons-dbcp2. Here is 
the documentation for that pool; you can use these configuration 
settings on your  element in your web application's 
META-INF/context.xml file:


https://commons.apache.org/proper/commons-dbcp/configuration.html

I recommend looking at the "abandoned"-related configuration options.

-chris


On Sat, Aug 7, 2021 at 3:43 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Sampath,

On 8/6/21 08:37, Sampath Rajapakshe wrote:

Hi All,

In my local setup before pool exhaustion exception is thrown, all the
connections seem to be in freezed and when checking processList in mysql,
those connections are in sleep state and doesn't execute any queries.

After

waiting for maxWait period the pool exhausted exception gets thrown and
seems to reset the connections and then the queries are getting processed
as normally.

  >

So, my question is, with pool exhausted scenarios, doesn't existing
connections execute their queries during that time(maxWait) and try to
resolve the exhausted behaviour by releasing those connections to idle
queue automatically? When checking the JMX matrix during this pool
exhausted time all the connections are in the active queue.



https://blog.christopherschultz.net/2009/03/16/properly-handling-pooled-jdbc-connections/


If not, what i am experiencing is as expected behaviour where the system

is

stuck after pool exhaustion for the best case of maxWait?


Most of the time I've seen this kind of behavior it's due to sloppy
resource-management.

-chris

-
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: Clarification on behaviour after pool exhaustion happen in tomcat jdbc pool 9.0.16

2021-08-06 Thread Christopher Schultz

Sampath,

On 8/6/21 08:37, Sampath Rajapakshe wrote:

Hi All,

In my local setup before pool exhaustion exception is thrown, all the
connections seem to be in freezed and when checking processList in mysql,
those connections are in sleep state and doesn't execute any queries. After
waiting for maxWait period the pool exhausted exception gets thrown and
seems to reset the connections and then the queries are getting processed
as normally.

>

So, my question is, with pool exhausted scenarios, doesn't existing
connections execute their queries during that time(maxWait) and try to
resolve the exhausted behaviour by releasing those connections to idle
queue automatically? When checking the JMX matrix during this pool
exhausted time all the connections are in the active queue.


https://blog.christopherschultz.net/2009/03/16/properly-handling-pooled-jdbc-connections/


If not, what i am experiencing is as expected behaviour where the system is
stuck after pool exhaustion for the best case of maxWait?


Most of the time I've seen this kind of behavior it's due to sloppy 
resource-management.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Help Needed

2021-08-05 Thread Christopher Schultz

Mohan,

On 8/5/21 23:51, Mohan T wrote:

Dear All,

We are using Tomcat 8.5 on Suse LINUX.

We enabled JAvA security in  tomcat and invoking the Catalina.sh. We are facing 
some permission issues in the environment.

We could see the below error messages.

access: access allowed ("java.util.logging.LoggingPermission" "control")
java.lang.Exception: Stack trace
 at java.lang.Thread.dumpStack(Thread.java:1336)
 at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:419)
 at 
java.security.AccessController.checkPermission(AccessController.java:884)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
 at java.util.logging.LogManager.checkPermission(LogManager.java:1586)
 at java.util.logging.Logger.checkPermission(Logger.java:422)
 at java.util.logging.Logger.removeHandler(Logger.java:1764)
 at 
org.apache.juli.ClassLoaderLogManager.resetLoggers(ClassLoaderLogManager.java:393)
 at 
org.apache.juli.ClassLoaderLogManager.shutdown(ClassLoaderLogManager.java:377)
 at 
org.apache.juli.ClassLoaderLogManager$Cleaner.run(ClassLoaderLogManager.java:81)
policy: getPermissions:
 PD CodeSource: 
(file:/home/ilas/tomcat8.5_tech/apache-tomcat-8.5.35/bin/tomcat-juli.jar )
 PD ClassLoader: sun.misc.Launcher$AppClassLoader@3d4eac69
 PD Principals: 
policy: evaluate codesources:
 Policy CodeSource: (file:/usr/java/jdk1.8.0_162/jre/lib/- )
 Active CodeSource: 
(file:/home/ilas/tomcat8.5_tech/apache-tomcat-8.5.35/bin/tomcat-juli.jar )


If you require signed JAR files, please use a more recent version of 
Tomcat 8.5.x. I'm not sure when signing was introduced, but 8.5.35 
nearly 3 years ago and definitely should be upgraded if you are 
sensitive to security issues.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: More information, Re: Tomcat 8.5.68 failing on takeoff!

2021-08-05 Thread Christopher Schultz

James,

On 8/5/21 18:33, James H. H. Lampert wrote:
I finally had a chance to switch the customer back to the failing Tomcat 
8.5.68, and this is what the browser error page shows (with a 500 error):



Type Exception Report

Message AuthConfigFactory error: 
java.lang.reflect.InvocationTargetException


Description The server encountered an unexpected condition that 
prevented it from fulfilling the request.


Exception

java.lang.SecurityException: AuthConfigFactory error: 
java.lang.reflect.InvocationTargetException

 
javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:85)
 
org.apache.catalina.authenticator.AuthenticatorBase.findJaspicProvider(AuthenticatorBase.java:1421)
 
org.apache.catalina.authenticator.AuthenticatorBase.getJaspicProvider(AuthenticatorBase.java:1411)
 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:535)
 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:698)
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:364)
 org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:624)
 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:831)
 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1651)
 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 java.lang.Thread.run(Thread.java:811)
Root Cause

java.lang.reflect.InvocationTargetException
 sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:83)
 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
 java.lang.reflect.Constructor.newInstance(Constructor.java:437)
 
javax.security.auth.message.config.AuthConfigFactory$1.run(AuthConfigFactory.java:76)
 
javax.security.auth.message.config.AuthConfigFactory$1.run(AuthConfigFactory.java:67)
 java.security.AccessController.doPrivileged(AccessController.java:696)
 
javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:66)
 
org.apache.catalina.authenticator.AuthenticatorBase.findJaspicProvider(AuthenticatorBase.java:1421)
 
org.apache.catalina.authenticator.AuthenticatorBase.getJaspicProvider(AuthenticatorBase.java:1411)
 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:535)
 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:698)
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:364)
 org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:624)
 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:831)
 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1651)
 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 java.lang.Thread.run(Thread.java:811)
Root Cause

java.lang.SecurityException: org.xml.sax.SAXNotRecognizedException: 
Feature: http://apache.org/xml/features/allow-java-encodings

 
org.apache.catalina.authenticator.jaspic.PersistentProviderRegistrations.loadProviders(PersistentProviderRegistrations.java:65)
 
org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl.loadPersistentRegistrations(AuthConfigFactoryImpl.java:345)
 
org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl.(AuthConfigFactoryImpl.java:68)
 sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:83)
 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
 java.lang.reflect.Constructor.newInstance(Constructor.java:437)
 
javax.security.auth.message.config.AuthConfigFactory$1.run(AuthConfigFactory.java:76)
 

Re: reloading tls configuration programmatically

2021-08-04 Thread Christopher Schultz

Ivano,

On 8/4/21 18:22, Ivano Luberti wrote:
Hello, in order to improve management of our servers I would like to 
implement the ability to timely reload Tomcat TLS configuration so to 
make tomcat aware of renewed certificates


Do you want to do this from script or something else?

I have seen that in the manager web application I can reload TLS 
configuration with the Re Read button in the Re-read TLS configuration 
files section.


Reading documentation at

https://tomcat.apache.org/tomcat-8.5-doc/manager-howto.html#Reload_TLS_configuration 



I have seen that it doesn't parse server.xml, so I guess this function 
is not going to load new certificates if a SSLHostConfig is added to 
server.xml . Right?


Correct. However, you can alter the runtime configuration and /then/ 
reload it, causing new certificates to be loaded, etc.



So my questions are:

1) has anyone tried to write something callable outside tomcat to induce 
it to reload certificates starting form the code in 
ManagerServlet.java.sslReload method?


You can call from the outside. Is there something you want to do that 
you think can't be done with existing options? (I realize that part of 
your question is asking about those options, so maybe we'll wait on this 
question until later).


2) if no one is aware of such a try, I guess that the shortest path 
would be to not reimplement the whole process but write a script that calls


http://localhost:8080/manager/text/sslReload?tlsHostName=name

Am I right ? Better suggestions?


Why not simply call 
http://localhost:8080/manager/text/sslReload?tlsHostName=name directly 
from script?


3) However If this is not going to load new certificates  It would solve 
only (a certainly big) part of my problem. Is there any suggestion or 
starting point to implement also this feature?


You can invoke a reload using JMX, either by connecting using a JMX 
client or by using my favorite: JMXProxyServlet.


You can read about the JMXProxyServlet here:
https://tomcat.apache.org/tomcat-8.5-doc/monitoring.html#Using_the_JMXProxyServlet

To reload the SSL configuration, you need to locate your ProtocolHandler 
 within JMX and invoke the reloadSslHostConfigs method on that object.


This presentation is a little terse, but it includes an example of how 
to do this on slide 33:


https://people.apache.org/~schultz/ApacheCon%20NA%202019/Let's%20Encrypt%20Apache%20Tomcat.pdf

You can see the video of the most recent presentation of that material 
on Tomcat's "presentations" page which may help put that into context a 
little.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 8.5.68 failing on takeoff!

2021-08-03 Thread Christopher Schultz

James,

On 8/3/21 08:42, Christopher Schultz wrote:

James,

On 8/2/21 19:31, James H. H. Lampert wrote:
This is beyond my pay grade, I'm afraid. Hopefully somebody here has a 
clue what went wrong.


I installed Tomcat 8.5.68 on an AS/400 with Java 8, that had been 
running Tomcat 7 for years with no problems.


On launching Tomcat 8, if I try to connect to "manager" (the only 
context currently in Webapps), right after:


02-Aug-2021 18:15:11.655 INFO [main] 
org.apache.catalina.startup.Catalina.load Initialization processed in 
3271 ms


I'm getting

02-Aug-2021 18:15:11.707 WARNING [main] 
org.apache.catalina.users.MemoryUserDatabase.open Exception 
configuring digester to permit java encoding names in XML files. Only 
IANA encoding names will be supported.
org.xml.sax.SAXNotRecognizedException: Feature: 
http://apache.org/xml/features/allow-java-encodings
 at 
org.apache.crimson.parser.XMLReaderImpl.setFeature(XMLReaderImpl.java:213) 

 at 
org.apache.crimson.jaxp.SAXParserImpl.setFeatures(SAXParserImpl.java:143)
 at 
org.apache.crimson.jaxp.SAXParserImpl.(SAXParserImpl.java:126)
 at 
org.apache.crimson.jaxp.SAXParserFactoryImpl.newSAXParserImpl(SAXParserFactoryImpl.java:113) 

 at 
org.apache.crimson.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:141) 

 at 
org.apache.tomcat.util.digester.Digester.setFeature(Digester.java:526)
 at 
org.apache.catalina.users.MemoryUserDatabase.open(MemoryUserDatabase.java:440) 

 at 
org.apache.catalina.users.MemoryUserDatabaseFactory.getObjectInstance(MemoryUserDatabaseFactory.java:105) 

 at 
org.apache.naming.factory.FactoryBase.getObjectInstance(FactoryBase.java:96) 

 at 
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:332)

 at org.apache.naming.NamingContext.lookup(NamingContext.java:847)
 at org.apache.naming.NamingContext.lookup(NamingContext.java:157)
 at 
org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal(NamingContextBindingsEnumeration.java:115) 

 at 
org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:69) 

 at 
org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:32) 

 at 
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:131) 

 at 
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:105) 

 at 
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:80) 

 at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) 

 at 
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) 

 at 
org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
 at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:763) 

 at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)

 at org.apache.catalina.startup.Catalina.start(Catalina.java:688)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90) 

 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) 


 at java.lang.reflect.Method.invoke(Method.java:508)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476)


I can't recall ever seeing anything like this.


I checked the code and this is a non-fatal warning. I can find no 
information about the 
http://apache.org/xml/features/allow-java-encodings SAX parser feature 
and Google seems to be no help, here.


For completeness, here is the refefence that explains this feature:

https://xerces.apache.org/xerces2-j/features.html

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 8.5.68 failing on takeoff!

2021-08-03 Thread Christopher Schultz

Konstantin,

On 8/3/21 04:07, Konstantin Kolinko wrote:

вт, 3 авг. 2021 г. в 02:31, James H. H. Lampert
:


This is beyond my pay grade, I'm afraid. Hopefully somebody here has a
clue what went wrong.

I installed Tomcat 8.5.68 on an AS/400 with Java 8, that had been
running Tomcat 7 for years with no problems.

On launching Tomcat 8, if I try to connect to "manager" (the only
context currently in Webapps), right after:

02-Aug-2021 18:15:11.655 INFO [main]
org.apache.catalina.startup.Catalina.load Initialization processed in
3271 ms

I'm getting

02-Aug-2021 18:15:11.707 WARNING [main]
org.apache.catalina.users.MemoryUserDatabase.open Exception configuring
digester to permit java encoding names in XML files. Only IANA encoding
names will be supported.
org.xml.sax.SAXNotRecognizedException: Feature:
http://apache.org/xml/features/allow-java-encodings
 at
org.apache.crimson.parser.XMLReaderImpl.setFeature(XMLReaderImpl.java:213)
 at
org.apache.crimson.jaxp.SAXParserImpl.setFeatures(SAXParserImpl.java:143)
 at org.apache.crimson.jaxp.SAXParserImpl.(SAXParserImpl.java:126)
 at
org.apache.crimson.jaxp.SAXParserFactoryImpl.newSAXParserImpl(SAXParserFactoryImpl.java:113)
 at
org.apache.crimson.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:141)
 at 
org.apache.tomcat.util.digester.Digester.setFeature(Digester.java:526)
 at
org.apache.catalina.users.MemoryUserDatabase.open(MemoryUserDatabase.java:440)


[...]


 at org.apache.catalina.startup.Catalina.start(Catalina.java:688)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
 at java.lang.reflect.Method.invoke(Method.java:508)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476)


1. It is a warning, not an error. If you look at
MemoryUserDatabase.java:440 you will see that it is caught and
ignored.

It means that the XML parser does not recognize the
"http://apache.org/xml/features/allow-java-encodings; feature name.


2. The stack trace starts with "Bootstrap.main". I.e. it is the thread
that starts Tomcat.

I.e. this occurs when Tomcat starts up and has nothing to do with your
attempt to access the Manager web application.


3. The stack trace contains "org.apache.crimson".

Apache Crimson project was retired 11 years ago and should not be used nowadays.
https://xml.apache.org/crimson/
https://attic.apache.org/projects/crimson.html

You have that library in Tomcat classpath? Where? Why?


Good catch.

The JVM has been bundled with a SAX parser for ages, now. You might ask 
your application/engineering team if it's okay to try your application 
without a bundled XML library.


You might also ask why it's being put into CATALINA_BASE/lib (or 
endorsed-libs?) instead of in the application's WEB-INF/lib where it 
belongs.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 8.5.68 failing on takeoff!

2021-08-03 Thread Christopher Schultz

James,

On 8/2/21 19:31, James H. H. Lampert wrote:
This is beyond my pay grade, I'm afraid. Hopefully somebody here has a 
clue what went wrong.


I installed Tomcat 8.5.68 on an AS/400 with Java 8, that had been 
running Tomcat 7 for years with no problems.


On launching Tomcat 8, if I try to connect to "manager" (the only 
context currently in Webapps), right after:


02-Aug-2021 18:15:11.655 INFO [main] 
org.apache.catalina.startup.Catalina.load Initialization processed in 
3271 ms


I'm getting

02-Aug-2021 18:15:11.707 WARNING [main] 
org.apache.catalina.users.MemoryUserDatabase.open Exception configuring 
digester to permit java encoding names in XML files. Only IANA encoding 
names will be supported.
org.xml.sax.SAXNotRecognizedException: Feature: 
http://apache.org/xml/features/allow-java-encodings
 at 
org.apache.crimson.parser.XMLReaderImpl.setFeature(XMLReaderImpl.java:213)
 at 
org.apache.crimson.jaxp.SAXParserImpl.setFeatures(SAXParserImpl.java:143)
 at 
org.apache.crimson.jaxp.SAXParserImpl.(SAXParserImpl.java:126)
 at 
org.apache.crimson.jaxp.SAXParserFactoryImpl.newSAXParserImpl(SAXParserFactoryImpl.java:113) 

 at 
org.apache.crimson.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:141) 

 at 
org.apache.tomcat.util.digester.Digester.setFeature(Digester.java:526)
 at 
org.apache.catalina.users.MemoryUserDatabase.open(MemoryUserDatabase.java:440) 

 at 
org.apache.catalina.users.MemoryUserDatabaseFactory.getObjectInstance(MemoryUserDatabaseFactory.java:105) 

 at 
org.apache.naming.factory.FactoryBase.getObjectInstance(FactoryBase.java:96) 

 at 
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:332)

 at org.apache.naming.NamingContext.lookup(NamingContext.java:847)
 at org.apache.naming.NamingContext.lookup(NamingContext.java:157)
 at 
org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal(NamingContextBindingsEnumeration.java:115) 

 at 
org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:69) 

 at 
org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:32) 

 at 
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:131) 

 at 
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:105) 

 at 
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:80) 

 at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) 

 at 
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) 

 at 
org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
 at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:763) 

 at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)

 at org.apache.catalina.startup.Catalina.start(Catalina.java:688)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90) 

 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) 


 at java.lang.reflect.Method.invoke(Method.java:508)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476)


I can't recall ever seeing anything like this.


I checked the code and this is a non-fatal warning. I can find no 
information about the 
http://apache.org/xml/features/allow-java-encodings SAX parser feature 
and Google seems to be no help, here.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: JDBCRealm driver location 9.0.24

2021-08-01 Thread Christopher Schultz

Stephane,

On 8/1/21 11:17, Stephane wrote:

I'm trying to distinguish catalina_home from catalina_base and I use a
JDBCRealm and soon will probably use other realms.


Don't use JDBCRealm. Instead, use DataSourceRealm. It's a long story, 
but DataSourceRealm is what you want for production and JDBCRealm is 
more of a toy.


They are configured very similarly.


I read the documentation, mentioning JDBC driver needs to be in
catalina_home/lib. I don't understand why as catalina.properties
specify common.loader
as "${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.hom
e}/lib","${catalina.base}/lib/*.jar"

>
> Can someone explain ?

common.loader includes both catalina.base/lib/*.jar and 
catalina.home/lib/*.jar, so it doesn't matter whether you put it in one 
place of the other.


I prefer using catalina.base for *everything* because it means that your 
catalina.home is never polluted with stuff that didn't come from the 
original tarball. The only changes I ever make to the extracted-contents 
of the tarball are to sometimes change some file permissions.


My recommendation would be to put your JDBC driver library in 
catalina.base/lib



I also tried to modify catalina.properties (to test with
server.loader) but as soon as I have the file in catalina_base (even
empty), the server doesn't start at all
(java.lang.ClassNotFoundException:
org.apache.catalina.startup.Catalina).

Can someone help on this too ?


Do you have the library in multiple places?

I wouldn't mess-around with catalina.properties unless you absolutely 
have to. Every default in there makes a *LOT* of sense.


Hope that helps,
-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Load balancing websockets

2021-08-01 Thread Christopher Schultz

Sridar,

On 7/28/21 20:16, Sridhar Rao wrote:

We are using the tomcat8.5 app nodes behind an Nginx Load Balancer.
Whenever the LB takes out an app node from the pool, "existing" WebSocket
connections are still staying with the app node. Also, if a new app node is
added to the pool, WS connections are not load balanced as they are
persistent. In general, wondering what are some of the mechanisms/tools are
employed to handle WebSocket load balancing issues.


Websocket is a connection-oriented protocol negotiated through a 
connectionless protocol (HTTP), and you end up with a persistent 
connection from client to server. Compare this to the (very!) old style 
of connecting a telephone call between two distant callers by making a 
series of physical connections such that you have one continuous circuit 
between the caller and the receiver. (That was before switching was 
introduced.)


Anyhow, once the connection has been established, what you describe is 
expected behavior: only HTTP can be load-balanced. Once the Websocket 
connection has been established, there is no way to "migrate" the 
connection to another node.


What you *can* do is terminate the connection and establish a new one, 
which will indeed be load-balanced as you expect.


Note that this may be awkward for your application.

One of the easiest possible things to do would be to implement a 
timed-termination of the connection on the client and/or the server so 
that Webocket connections never last more than e.g. 1 minute so your 
load-balancing becomes effective again.


Another possibility would be to think about why you are using Websocket 
in a way that would *require* load-balancing.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Ho to upgrade to newest version in tomcat 9

2021-08-01 Thread Christopher Schultz

W,

On 7/28/21 04:08, Olaf Kock wrote:


On 27.07.21 19:01, W wrote:

Hi,
I am on Ubuntu with tomcat 9.0.16I tried    sudo apt-get update    sudo apt-get 
upgradeBut did not work. How to do it?


The distribution packages (here: Debian) typically pick one version and
keep it stable, optionally backporting security fixes to it. Odds are
that you're already not running the same code as in stock 9.0.16, but a
patched version.


+1

In order to get the latest Tomcat, you may have to switch your Ubuntu 
repository to point to the latest Ubuntu, then upgrade the whole distro 
which will include the latest Tomcat available.


If you want to be on the latest version as soon as it's out, you'll 
either have to install manually from https://tomcat.apache.org, or

find a repository that you trust, that offers a packaged version.

+1 again

You might be able to cobble-together a sources.list file that merges the 
latest Tomcat package (and maybe some dependencies) but allows the OS to 
otherwise remain at the older level, but I'd recommend upgrading the 
whole OS in general, even if you stop using the package-managed version 
of Tomcat.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat Usage Data Interest

2021-07-26 Thread Christopher Schultz

Coty,

On 7/26/21 07:13, Coty Sutherland wrote:

Hi all,

I'm curious about whether or not we have/can get some information about the
usage of Tomcat out in the wild. Things like download count across various
versions (including archived version downloads) for the last few years, svn
history and GitHub stats, project website visitors, committer numbers (and
some other info which I can get from the regular board reports), counts of
tomcat-users list unique topics, etc. I'd like to compile data into a
community interest report (or something like that) and try to draw some
insights on which way the Tomcat project is trending. I would also be
looking to include adoption outside of just the vanilla ASF distro, like
the most popular Tomcat Docker container, Ansible collection, tomcat
package downloads from any OS that has the data available, etc.

Does anyone think that such a report has value? Is there already something
like this in existence somewhere (there is an annual jrebel technology
report like https://www.jrebel.com/blog/2020-java-technology-report which
is pretty cool, but it's a survey)? Feel free to tell me that this
undertaking has little value and I can move on to something else :)
Thoughts?


Certainly would be interesting.

Debian has "popularity contest". It looks like it would be a ton of 
data, but it's available: https://popcon.debian.org/


I don't happen to use the Debian-packaged version of Tomcat, but I am a 
Debian user and fan.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Strange incomplete response/truncation with Tomcat 9.0.48 AND 9.0.50 [OT]

2021-07-26 Thread Christopher Schultz

All,

On 7/23/21 11:27, Mark Thomas wrote:

On 23/07/2021 15:49, jonmcalexan...@wellsfargo.com.INVALID wrote:

Is there an estimated target date for release of 9.0.51


Normally I'd say early August, some time in the first 2 weeks. But as we 
are entering vacation season it might slip. It largely depends on the 
release manager's availabaility.


I happen to be on vacation myself, but was still planning to do the 
8.5.70 release around the first of the month.


If neither Mark nor Rémy are available, I could attempt to do the 9.0.51 
release as well.


-chris


-Original Message-
From: Mark Thomas 
Sent: Friday, July 23, 2021 2:56 AM
To: users@tomcat.apache.org
Subject: Re: Strange incomplete response/truncation with Tomcat 9.0.48
AND 9.0.50

On 22/07/2021 22:06, jonmcalexan...@wellsfargo.com.INVALID wrote:

I have a team that is running into issues since version 9.0.48 where
they are receiving incomplete message responses from Tomcat when the
request was made from WebLogic.


Incomplete responses from 9.0.48 onwards. That sounds like a recently 
fixed

regression. That issue happened with TLS.




*adrum.js:27 Error: Loading chunk 28 failed.*

(timeout:
https://.../.5af0fea300ccf52ff152.js)


That looks like TLS is being used which is consistent with the 
suspected root

cause.




*_Network level_* we are seeing *TCP Window Full* intermittently when
this file transfer.


This is also consistent with the likely root cause. The regression 
was in the

handling of incomplete writes.




After some additional research we assume this issue is related to one
of the known bugs listed in RedHat TC release notes
.


Fix:  Expand the unit tests for HttpServlet.doHead()


Not an unreasonable guess but it looks to be an incorrect one.

I always recommend looking at the open bugs and the changelog from 
the CI

system to see if the issue being observed has already been reported (and
possibly fixed).

https://urldefense.com/v3/__https://ci.apache.org/projects/tomcat/tomcat
-
9.0.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!69FyojmXXQigaRKpGDi
wpMgSsgODh4HrEhdK9d8ZbHZsJjpqNcD2ZmKprbbGjevC8PK9tLQ$

This looks much more like bug 65448 to me:
https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cgi?
id=65448__;!!F9svGWnIaVPGSwU!69FyojmXXQigaRKpGDiwpMgSsgODh4HrE
hdK9d8ZbHZsJjpqNcD2ZmKprbbGjevCqMV6SbI$




Any help?


The fix will be in 9.0.51.

Snapshots (NOT formal releases) are available for testing from:
https://urldefense.com/v3/__https://repository.apache.org/content/group
s/snapshots/org/apache/tomcat/tomcat/9.0-
SNAPSHOT/__;!!F9svGWnIaVPGSwU!69FyojmXXQigaRKpGDiwpMgSsgODh4
HrEhdK9d8ZbHZsJjpqNcD2ZmKprbbGjevCZcMI2B0$

Usual caveats apply. These aren't releases. Use them entirely at your 
own

risk.

In terms of a workaround, switching from NIO to NIO2 should avoid the
issue.

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




-
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 8.5.57 stops killing sessions after some time

2021-07-26 Thread Christopher Schultz

Ivano,

On 7/23/21 02:20, Ivano Luberti wrote:
I have found the issue: one of the webapps has several thread locked on 
a MultiThreadedHttpConnectionManager during sessionUnbound and 
unboundEvents.


So the background process killing the sessions is stuck as well.


This is a very easy problem to encounter. Session event-handlers really 
need to be bulletproof and execute very quickly.


If you need a long-running process to trigger, use an executor service 
or something where you can capture the information to be used and 
off-load it onto another thread. Remember that the session cannot be 
used after the event-handler completes, so capture whatever information 
you need from the session FIRST, then dispatch to another thread, then 
return from the event-handler.


-chris


Il 21/07/2021 18:13, Mark Thomas ha scritto:

On 21/07/2021 16:00, Ivano Luberti wrote:


Il 21/07/2021 16:44, Mark Thomas ha scritto:
Take 3 thread dumps 5 seconds apart and post them here. 


How to take thread dumps?

  kill -3  ?


That will work. There are lots of ways. This is most of them:

https://www.baeldung.com/java-thread-dump

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



Re: Request for suggestion

2021-07-16 Thread Christopher Schultz

Mohan,

On 7/11/21 01:41, Mohan T wrote:

We are using tomcat 8.5 on Suse linux. We would like to know the way
to load a property file.

I put the file in tomcat  / lib folder.

Still I am getting the error

DEBUG 2021-07-11 07:56:15,108 [http-nio-8081-exec-8] 
control.CompositeCacheManager - Instance is null, creating with default config
INFO  2021-07-11 07:56:15,109 [http-nio-8081-exec-8] 
control.CompositeCacheManager - Creating cache manager from config file: 
/cache.ccf
ERROR 2021-07-11 07:56:15,109 [http-nio-8081-exec-8] 
control.CompositeCacheManager - Failed to load properties for name [/cache.ccf]


Loading files can be done in a lot of different ways. How is the code 
attempting to load the .properties file?


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Internals of setMaxInactiveInterval

2021-07-14 Thread Christopher Schultz

Saurav,

On 7/12/21 23:33, Saurav Sarkar wrote:

Hi All,

I would like to understand the internals of Session~setMaxInactiveInterval
in tomcat.

I understand that if HTTP requests are not received within the said
interval then the session is cleared. All the objects belonging to the
session will be gone.

Does that also mean that the existing requests part of the session will be
terminated ?

I have a scenario for large file transfer to happen over a single request.

So if one request (A) is long running and there are no other requests sent
within the time interval.

Then will the request A will be terminated and subsequent requests even if
with valid cookie will not be part of the same session ? Or will the
ongoing request's fate is determined by other timeouts like read time out?


Requests that were related to a certain session will never be terminated 
due to a session state-change.


But, if your servlet works like this, you may have a problem:

doGet() {
  HttpSession session = request.getSession(true);

  // take 45 minutes to stream data to the client

  session.setAttribute("foo", "bar");
}

My recommendation would be to do all of your session-work "up front" 
(before the long data-stream) and not touch the session after the 
download completes.


This may not meet your requirements, but if you are doing extraordinary 
things, you may require extraordinary workarounds :)


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Mixing Root Context webapp with other webapps

2021-07-09 Thread Christopher Schultz

Jerry,

On 7/9/21 01:58, Jerry Malcolm wrote:
I have one webapp that processes REST-style url paths and therefore 
needs to run in the ROOT context.


I'm not sure the conclusion follows from the premise, here. You can 
certainly use REST-style URL paths and not have a context at the top-level.


Is it possible to run other webapps 
in the same host with other non-root contexts?


It is, but I wouldn't recommend it. Well... I would definitely recommend 
/against/ it in some situations. Specifically, when both the root and 
other web applications both need to use cookie-based sessions. If you 
have two applications fighting over whose JSESSIONID cookie is the one 
to use for login, Bad Things can happen.


If your root context and/or none of the non-root contexts will be using 
cookie-based session-tracking, then you will probably be fine.



In other words, when resolving a URL to a web app, does it try to map
the url to the defined context strings first, and then to ROOT if
there are no matches?  Or does ROOT override everything, and all URLs
go to ROOT if it's defined?
It's the latter, otherwise it would be pretty much impossible to deploy 
anything when a ROOT context was present.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



[ANN] Apache Tomcat 8.5.69 available

2021-07-06 Thread Christopher Schultz

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.69.

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.69 is a bugfix and feature release. The notable 
changes compared to 8.5.68 include:


- Re-work the HTTP/2 overhead protection to reduce the likelihood of
  false positives. Note that the default overheadCountFactor has changed
  from 1 to 10 and that the useful range is now 0 to ~20.

- Fix regressions in JSP compilation in the previous release.

- Improve HTTP header parsing to ignore empty elements in 1#token
   values, as per RFC 7230 section 7.

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



[ANN] Apache Tomcat 8.5.68 available

2021-07-06 Thread Christopher Schultz

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.69.

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.69 is a bugfix and feature release. The notable 
changes compared to 8.5.68 include:


- Re-work the HTTP/2 overhead protection to reduce the likelihood of
  false positives. Note that the default overheadCountFactor has changed
  from 1 to 10 and that the useful range is now 0 to ~20.

- Fix regressions in JSP compilation in the previous release.

- Improve HTTP header parsing to ignore empty elements in 1#token
   values, as per RFC 7230 section 7.

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: CVE-2021-25329, was Re: Most recent security-related update to 8.5

2021-07-02 Thread Christopher Schultz

James,

On 7/2/21 11:44, James H. H. Lampert wrote:

On 7/2/21 12:02 AM, Mark Thomas wrote:

It is an alternative session manager that persists session data via a 
configured Store. There are two Store implementations provided by 
default - File and DataSource.


You would know if you were using it as it requires explicit 
configuration.


Thanks for the specific documentation link; I would not have known where 
to look in the docs. My friends and colleagues seem to think I have 
brilliant research skills; in fact, I simply have no qualms about asking 
for help.


Our webapp totally lacks a "context.xml" (I looked for one) but I see 
such files, with Manager elements, in the manager and host-manager 
webapps. Are they affected by CVE-2021-25329/CVE-2020-9484?


Incidentally, speaking of those webapps, when installing, we immediately 
jettison all as-shipped webapps *except* manager and host-manager. We 
use manager all the time, but I'm not even sure what host-manager does.


I honestly have never seen a real-world use-case for where the 
host-manager is useful. I'm sure its critically important for somebody 
out there, though.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Question about directory listing sorting ..

2021-07-02 Thread Christopher Schultz

Konstantin,

On 7/2/21 05:28, Konstantin Kolinko wrote:

пт, 2 июл. 2021 г. в 04:04, John Dale (DB2DOM) :


Doesn't seem to work for me on 9.0.41 (it's an older development box).

I found these interesting:
ow with patch v3:
1. "s=NA" name=asc
2. "s=ND" name=dsc
3. "s=SA" size=asc
4. "s=SD" size=dsc
5. "s=MA" modify=asc
6. "s=MD" modify=dsc

 From here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57287

Before I get too far down the road, I thought I would reach out.
Params don't seem to affect listing sort order.


It is off by default. I updated the BZ issue to point this out.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57287#c12

Parameter names are a bit different.
E.g. with 9.0.50 (I modified DefaultServer configuration, and using
the examples web app):

http://localhost:8080/examples/jsp/cal/?C=N;O=A
http://localhost:8080/examples/jsp/cal/?C=N;O=D


My first thought was "holy crap, someone cares about this feature?" :)

John, you're just made my trip to Brussels entirely worth it.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: JSESSION ID

2021-07-02 Thread Christopher Schultz

Mohan,

On 7/1/21 07:27, Mohan T wrote:

Dear All,

We are using tomcat 8.5.35 on Linux.

We are getting two session ID for the same Http request.. Similar session ID is 
marked in yellow

This is the session ID in startup JSESSIONID=FFE8F98C012CDB4461FC8E68C109298E
This is the session ID in dispatcher 
JSESSIONID=7CAFF4519565D00381DF792E375D241C; 
JSESSIONID=FFE8F98C012CDB4461FC8E68C109298E

Request for any inputs on this


Can you reproduce this yourself? If so, go into your browser and open 
the "developer tools" and have a look at the cookies for the site.


Check the "path" of the cookie. Browsers identify cookies based upon a 
number of different metadata fields, including the "path". If you have a 
JSESSIONID cookie for / and another one for /foo, then both will be sent 
if you are vising resources at /foo.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Strange error with JSP

2021-07-02 Thread Christopher Schultz

Konstantin,

On 7/1/21 04:17, Konstantin Kolinko wrote:

вт, 29 июн. 2021 г. в 19:35, Christopher Schultz :


Konstantin,

On 6/29/21 10:21, Konstantin Kolinko wrote:

ср, 2 июн. 2021 г. в 23:16, Christopher Schultz :

[...]

Has the page been compiled once, or its modification time is being
checked over and over, or even worse: being recompiled?


Probably not being recompiled. The source JSP has a file-date in 2016
and the generated .java and .class files also have a date in 2016.


File dates do not matter: Tomcat resets them to match the original
file, as that is a way to track the changes. That is why I asked about
the file system and its supported time precision.

The time when the java file was generated is shown with a comment,
"Generated at: " at the top of the file.


I have two Tomcat nodes.

Node 1:

 * Version: Apache Tomcat/8.5.34
 * Generated at: 2021-04-08 21:22:24 UTC

I'm currently running 8.5.65, so this was certainly generated during a 
previous JVM lifetime.


Note 2:
 * Version: Apache Tomcat/8.5.42
 * Generated at: 2021-02-27 23:04:06 UTC


Also note "_jspx_dependants.put(...)" lines in the java file. Those
are dependencies whose modification timestamps are checked as well.


Node 1:

_jspx_dependants.put("/admin/httpheaderreferences.jsp", 
Long.valueOf(140008319L));

_jspx_dependants.put("/admin/util.jsp", Long.valueOf(140008319L));
_jspx_dependants.put("/admin/htmlescape.jsp", 
Long.valueOf(1573394428000L));


Those dates, respectively, are:
2014-05-14 15:59:50 +
2014-05-14 15:59:50 +
2019-11-10 14:00:28 +

So... well before the launch of the JVM.

Node 2:
_jspx_dependants.put("/admin/httpheaderreferences.jsp", 
Long.valueOf(156288322L));

_jspx_dependants.put("/admin/util.jsp", Long.valueOf(156288322L));
_jspx_dependants.put("/admin/htmlescape.jsp", 
Long.valueOf(1573394718000L));


Those dates, respectively, are:

2019-07-11 22:13:40 +
2019-07-11 22:13:40 +
2019-11-10 14:05:18 +

So... again, well before JVM launch.


Are "webapps" and "work" directories on the same kind of file system
(with the same supported precision for file modification times)?


Exactly the same filesystem.


I can't remember which of the 2 nodes threw this error. I may be able to 
go back into the logs if it would be helpful.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Issue while launching the applicaion

2021-06-30 Thread Christopher Schultz

Mohan,

On 6/30/21 10:28, Mohan T wrote:

Dear All,

I am getting this error while launching the application.

We are using tomcat 8.5.35 on linux .



30-Jun-2021 18:37:16.194 INFO [main] org.apache.coyote.AbstractProtocol.start Starting 
ProtocolHandler ["ajp-nio-8009"]
30-Jun-2021 18:37:16.207 INFO [main] org.apache.catalina.startup.Catalina.start 
Server startup in 17283 ms
Unexpected token END OF FILE at position 0.
 at org.json.simple.parser.JSONParser.parse(Unknown Source)
 at org.json.simple.parser.JSONParser.parse(Unknown Source)
 at org.json.simple.parser.JSONParser.parse(Unknown Source)
 at com.ramco.security.servlet.LoadCSS.service(Unknown Source)


It looks like the LoadCSS servlet is encountering an end-of-file while 
reading a JSON file during request-processing.


You may want to look at that servlet, or the file it's trying to load.

This is not a Tomcat-related issue.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: 500 instances of tomcat on the same server

2021-06-29 Thread Christopher Schultz

Eric,

On 6/28/21 13:08, Eric Robinson wrote:

-Original Message-
From: Christopher Schultz 
Sent: Monday, June 28, 2021 8:54 AM
To: users@tomcat.apache.org
Subject: Re: 500 instances of tomcat on the same server

Eric,

On 6/25/21 22:58, Eric Robinson wrote:

We can run 75 to 125 instances of tomcat on a single Linux server with
12 cores and 128GB RAM. It works great. CPU is around 25%, our JVMs
are not throwing OOMEs, iowait is minimal, and network traffic is
about 30Mbps. We're happy with the results.

Now we're upping the ante. We have a 48-core server with 1TB RAM, and
we're planning to run 600+ tomcat instances on it simultaneously.
What caveats or pitfalls should we watch out for? Are there any hard
limits that would prevent this from working as expected?

If you have the resources, I see no reason why this would present any
problems.

On the other hand, what happens when you need to upgrade the OS on this
beast? You are now talking about disturbing not 72-125 clients, but 600 of
them.



There are two load-balanced servers, each with adequate power to support the 
whole load. When we want to maintain Server A, we drain it at the load balancer 
and wait for the last active connection to complete. Then we reboot/maintain 
the server and add it back into the rotation gracefully.


Sounds good. I'm curious, are you using the LoadBalancerDrainingValve 
for that purpose? What are you using for your load-balancer and/or 
reverse-proxy?



If I had a beast like this, I'd run VMWare (or similar) on it, carve it up into
virtual machines, and run fewer clients on each just for the sheer 
flexibility
of it.



We considered doing it that way. Performance is top priority, so we ultimately 
decided to run the instances on metal rather than introducing a few trillion 
lines of OS code into the mix.  We might consider containerizing.



If this is already a virtualized/cloud environment, then I think you're doing it
wrong: don't provision one huge instance and use it for multiple clients.
Instead, provision lots of small instances and use them for fewer (or even 1)
at a time.



That makes sense until you know the environment better. It's a canned 
application and we're not the publisher. Breaking it out this way gives us the 
ability to present each customer and a unique entity to the publisher for 
support purposes. When their techs connect, the sandbox allows them to 
troubleshoot and support our mutual customer independently, which puts them in 
an environment their techs are comfortable with, and removed the risk of them 
doing something that impacts everybody on the server (or in the VM, if we used 
those).


Okay. I'm sure I don't understand, but if you have heterogeneous support 
getting involved, to me it would be even more important to isolate all 
those applications from each other. Maybe you mean in-application 
support for mutual customers and not in-OS, etc. support.



All I can tell you is we've been running it this way for 15 years and we've 
never looked back and wished we were doing it differently.


That's a good position to be in. :)

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: 500 instances of tomcat on the same server

2021-06-29 Thread Christopher Schultz

All,

On 6/29/21 11:33, Eric Robinson wrote:

-Original Message-
From: Berneburg, Cris J. - US 
Sent: Tuesday, June 29, 2021 7:16 AM
To: users@tomcat.apache.org
Subject: RE: 500 instances of tomcat on the same server

Eric and Mark

Just curious...

Eric> We can run 75 to 125 instances of tomcat on a single Linux server

Eric, Do you have or need a centralized way of managing all those instances?


Hi Cris and Mark,

We have about 1500 instances of tomcat (750 load-balanced virtual services 
across 20 physical servers). We currently manage the environment with scripts. 
Due to the simplicity and consistency of our internal deployment standards, it 
works well and is pretty easy to manage on an instance-by-instance basis, but a 
web console where we can see the environment as a whole, or filter on portions 
of it, would be amazing!


A few years ago, a team from Cerner health came to ApacheCon and 
introduced their product called Jwala that was intended to do this kind 
of thing. You can find their presentation slides and video linked from 
the Tomcat presentations page:

http://tomcat.apache.org/presentations.html

The product appears to have undergone very little development in the 
past 4 years: it looks like they dropped it on GitHub and mostly forgot 
about it.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Strange error with JSP

2021-06-29 Thread Christopher Schultz

Konstantin,

On 6/29/21 10:21, Konstantin Kolinko wrote:

ср, 2 июн. 2021 г. в 23:16, Christopher Schultz :


All,

On 6/2/21 13:52, Christopher Schultz wrote:

All,

I don't do too much work with JSPs, but I do have a few quick-and-dirty
administrative things including one called the "session snooper" which
just dumps out loads of information about the current user's session
object.

I'm getting this error in production, and I can reproduce it every time
I access the page. Here's the exception stack trace:

java.lang.ClassNotFoundException: org.apache.jsp.admin.SessionSnooper_jsp
java.net.URLClassLoader.findClass(URLClassLoader.java:382)
 at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:128)
 at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:59)
 at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:159)

 at
org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:192)

 at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:413)

 at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
 [...filters, etc...]

This is a relatively simple JSP. There are no tag libraries in use and
there are 3 imports of JSPs which contain some static utility functions.

Both files
app/work/Catalina/localhost/[$context]/org/apache/jsp/admin/SessionSnooper_jsp.java
and
app/work/Catalina/localhost/[$context]/org/apache/jsp/admin/SessionSnooper_jsp.java
exist and have file-dates from way back in 2016. (No recent changes)

The context has been restarted/reloaded (not redeployed) recently using
JMX a few times, but nothing else relevant comes to mind.

This is Tomcat 8.5.65 from a stock ASF-distrubuted tarball, launched
using "catalina.sh start". Nothing fancy.

What other information can I collect to help debug this? My expectation
would be that the class should be findable and runnable. Tomcat should
not be tripping over its own feet on this one IMO.


There is more in my catalina.out file:

Jun 02, 2021 4:12:27 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [jsp] in context with path
[/[$context]] threw exception [java.lang.NullPointerException] with root
cause
java.lang.NullPointerException
  at
org.apache.jasper.JspCompilationContext.createOutputDir(JspCompilationContext.java:685)
  at
org.apache.jasper.JspCompilationContext.getOutputDir(JspCompilationContext.java:204)
  at
org.apache.jasper.JspCompilationContext.getClassFileName(JspCompilationContext.java:537)
  at
org.apache.jasper.compiler.Compiler.isOutDated(Compiler.java:464)
  at
org.apache.jasper.compiler.Compiler.isOutDated(Compiler.java:430)
  at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:590)
  at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399)
  at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
  at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)

Here's the code from createOutputDir:


l684File base = options.getScratchDir();
l685baseUrl = base.toURI().toURL();
l686outputDir = base.getAbsolutePath() + File.separator + path +
l687File.separator;
l688if (!makeOutputDir()) {
l689throw new
IllegalStateException(Localizer.getMessage("jsp.error.outputfolder"));
l690}

I'm not playing any games with JSP configuration or scratch/work
directory locations, etc.


Looking at line 685,

It is odd:

If options.getScratchDir() were returning null, you would see fatal
errors in your log earlier: The "options" variable should be an
instance of o.a.j.EmbeddedServletOptions. Its constructor initializes
the scratchDir field, does some checks and logs with log.fatal() when
the dir is null or not readable and writable.

A java.io.File.toURI() call cannot return null: the only possible
returned value is a new object, "new URI(...)" (looking into the
sources from Java 8u292).



BTW, I wonder whether your JspServlet is configured "for production",
http://tomcat.apache.org/tomcat-8.5-doc/jasper-howto.html#Production_Configuration


Unfortunately, I have restarted (or possibly reloaded) the server since 
then and can no longer replicate the error. But I'm happy to answer 
questions if it helps zero-in on a bug in Tomcat. I think there's 
definitely someting that CAN go wrong but shouldn't. So I think there is 
a bug hidden, here, somewhere.


I have no special configuration for JSP in my application: it's whatever 
the defaults are that ship with a stock 

Re: TLSv1.3 Support in Tomcat

2021-06-29 Thread Christopher Schultz

Daniel,

On 6/29/21 02:03, Daniel Savard wrote:

https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites

TLSv1.3 supports 5 cipher suites and none is in your list.


+1

Abirami,

Also, you aren't providing any  or other elements, so we 
can't tell what type of ey/cert you are using: RSA or EC?


Try adding:
  TLS_AES_128_GCM_SHA256
  TLS_AES_256_GCM_SHA384
  TLS_CHACHA20_POLY1305_SHA256

... to your list.

Note that you have both RSA and EC-based cipher suites in your cipher 
suites string, and with only a single certificate, you cannot possibly 
actually support both.


-chris


Le mar. 29 juin 2021 à 01:44, S Abirami  a
écrit :


Hi Christopher,

Below is my Connector element, sslEnabledProtocols =TLSv1.2 ,TLS 1.3 it is
working fine with TLSv1.2.  When sslEnabledProtocols=TLSv1.3, Tomcat is
started but, the browser unable to perform handshake with webapp.

Is there any dependency with Cipher suites?





Regards,
Abirami.S

-Original Message-
From: Christopher Schultz 
Sent: Monday, June 28, 2021 7:27 PM
To: users@tomcat.apache.org
Subject: Re: TLSv1.3 Support in Tomcat

Abirami,

On 6/28/21 07:16, S Abirami wrote:

TLSv1.3 support is available in Tomcat.

I tried just updating server.xml[sslEnabledProtocols=TLSv1.3] and
restarted tomcat. It doesn't work.

[We are using Tomcat 9.0.46 and JDK 8u291]

Please let me know any other configuration also needs to be changed.


Can you please post your  configuration (minus any secrets)?

When you say "it doesn't work", what exactly do you mean?

-chris

-
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: 500 instances of tomcat on the same server

2021-06-28 Thread Christopher Schultz

Mark,

On 6/28/21 10:04, Mark Thomas wrote:

On 28/06/2021 14:53, Christopher Schultz wrote:

Eric,

On 6/25/21 22:58, Eric Robinson wrote:
We can run 75 to 125 instances of tomcat on a single Linux server 
with 12 cores and 128GB RAM. It works great. CPU is around 25%, our

JVMs are not throwing OOMEs, iowait is minimal, and network traffic
is about 30Mbps. We're happy with the results.

Now we're upping the ante. We have a 48-core server with 1TB RAM, and
we're planning to run 600+ tomcat instances on it simultaneously.
What caveats or pitfalls should we watch out for? Are there any hard
limits that would prevent this from working as expected?
If you have the resources, I see no reason why this would present any 
problems.


On the other hand, what happens when you need to upgrade the OS on 
this beast? You are now talking about disturbing not 72-125 clients, 
but 600 of them.


If I had a beast like this, I'd run VMWare (or similar) on it, carve 
it up into virtual machines, and run fewer clients on each just 
for the sheer flexibility of it.

>
That just moves the goal posts. You'll have the same issue when the 
hypervisor needs updating (which admittedly may need a reboot less often 
than the OS).


Agreed. My assertion is that the hypervisor should require updates far 
less frequently. My AWS EC2 instances can stay up for months without 
being forcibly rebooted, for example. (I tend to restart them, anyway, 
for e.g. OS updates, but the point is the same.)


If this is already a virtualized/cloud environment, then I think 
you're doing it wrong: don't provision one huge instance and use it 
for multiple clients. Instead, provision lots of small instances and 
use them for fewer (or even 1) at a time.


But it adds the overhead of an OS for each instance. And costs if you 
have to pay for that OS instance.


As always there are trade-offs to be made and the "right" answer will 
vary based on circumstances and what you are trying to optimize for. I 
do agree that, generally, more smaller instances will be a closer fit to 
more use cases but that is only a general answer.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: TLSv1.3 Support in Tomcat

2021-06-28 Thread Christopher Schultz

Abirami,

On 6/28/21 07:16, S Abirami wrote:

TLSv1.3 support is available in Tomcat.

I tried just updating server.xml[sslEnabledProtocols=TLSv1.3] and
restarted tomcat. It doesn't work.

[We are using Tomcat 9.0.46 and JDK 8u291]

Please let me know any other configuration also needs to be changed.


Can you please post your  configuration (minus any secrets)?

When you say "it doesn't work", what exactly do you mean?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



  1   2   3   4   5   6   7   8   9   10   >