Monitoring and Tuning Tomcat

2024-04-30 Thread Jerry Malcolm 
I'm trying to optimize my instance, CPU, tuning, and size requirements 
for Tomcat.  It's easy to see CPU usage.  But this TC instance is 
running a lot of microservices that are often in and out fairly 
quickly.  So there can be a huge number of requests coming in.  I'm not 
sure that CPU starving is my biggest concern. I'm more interested is 
getting an understanding of TC front end bottlenecks and also JDBC data 
connection bottlenecks.   So I need a bit of education.   Am I correct 
that maxThreads on the connector throttles the number of requests that 
can come in at one time?  And connectionTimeout is the time to wait to 
get in the door if threads are maxed out before giving up and failing, 
correct?  I'd really like to track total threads in use and then track 
wait time if total threads are maxed out.  Likewise, with database 
connections.  I'd like to monitor the jdbc connection pool as well and 
see when and where the code is having to wait for a db connection and 
how long the average wait is.  I assume there are jms hooks to monitor 
this? But I don't want to reinvent the wheel.  Are there tools out there 
to assist with this already? Thx



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

Re: [EXTERNAL] Disabling OPTIONS HTTP method with * path

2024-04-30 Thread Joey Cochran 
From: Oleg Frenkel 
Sent: Tuesday, April 30, 2024 1:56 PM
To: users@tomcat.apache.org 
Subject: [EXTERNAL] Disabling OPTIONS HTTP method with * path

This issue exists in 9.0.88 and 10.1.23.

I am looking to disable the following HTTP request (note 'OPTIONS *' in the 
request):

$ curl -v --request-target "*" -X OPTIONS 
http://:
* Rebuilt URL to: :/
*   Trying ...
* TCP_NODELAY set
* Connected to  () port  (#0)
> OPTIONS * HTTP/1.1
> Host: :
> User-Agent: curl/7.61.1
> Accept: */*

I don't seem to be able to disable this OPTIONS request in Tomcat.

  Perhaps a CorsFilter setup can help ?

The following configuration doesn't work either:






Available HTTP 
methods
/*
GET
POST



The above section properly disables OPTIONS request to '/' path, but not to '*' 
path. In fact, the Tomcat response is that all methods are allowed:

$ curl -v --request-target "*" -X OPTIONS 
http://:
* Rebuilt URL to: http://:/
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying ...
* TCP_NODELAY set
* Connected to  () port  (#0)
> OPTIONS * HTTP/1.1
> Host: :
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 200
< Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS
< Content-Length: 0
< Date: Tue, 30 Apr 2024 18:49:07 GMT
<
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
* Connection #0 to host  left intact

Note that it is impossible to put '*' as URL pattern - Tomcat fails to start 
complaining that '*' is not a valid url pattern.

Please confirm if this is a bug in Tomcat or if I am missing something in 
Tomcat configuration.

Thanks,
Oleg Frenkel
SS Technologies Inc
Lead Software Engineer
ofren...@sscinc.com | 
www.ssctech.com

Disabling OPTIONS HTTP method with * path

2024-04-30 Thread Oleg Frenkel 
This issue exists in 9.0.88 and 10.1.23.

I am looking to disable the following HTTP request (note 'OPTIONS *' in the 
request):

$ curl -v --request-target "*" -X OPTIONS 
http://:
* Rebuilt URL to: :/
*   Trying ...
* TCP_NODELAY set
* Connected to  () port  (#0)
> OPTIONS * HTTP/1.1
> Host: :
> User-Agent: curl/7.61.1
> Accept: */*

I don't seem to be able to disable this OPTIONS request in Tomcat.

The following configuration doesn't work either:






Available HTTP 
methods
/*
GET
POST



The above section properly disables OPTIONS request to '/' path, but not to '*' 
path. In fact, the Tomcat response is that all methods are allowed:

$ curl -v --request-target "*" -X OPTIONS 
http://:
* Rebuilt URL to: http://:/
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying ...
* TCP_NODELAY set
* Connected to  () port  (#0)
> OPTIONS * HTTP/1.1
> Host: :
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 200
< Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS
< Content-Length: 0
< Date: Tue, 30 Apr 2024 18:49:07 GMT
<
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
* Connection #0 to host  left intact

Note that it is impossible to put '*' as URL pattern - Tomcat fails to start 
complaining that '*' is not a valid url pattern.

Please confirm if this is a bug in Tomcat or if I am missing something in 
Tomcat configuration.

Thanks,
Oleg Frenkel
SS Technologies Inc
Lead Software Engineer
ofren...@sscinc.com | 
www.ssctech.com

Re: Regarding Tomcat url redirection

2024-04-30 Thread Christopher Schultz 

Lavanya,

On 4/30/24 07:10, lavanya tech wrote:

Can you tell me how to do the below ? How should I setup Tomcat in
server.xml ?


If you want to use port 443 (the default port for HTTPS) then you will
need to change Tomcat to bind to port 443 (if that's allowed on your OS)
or arrange to have port 443 routed to port 8443. You may need additional
configuration in Tomcat (specifically: proxyPort) to avoid having Tomcat
generate URLs with ":8443" in them.

Looking forward to your reply.


If Tomcat is listening on port 8443 then you will need to include that 
in your URL, period. If you want to allow URLs without a port number, 
you will have to arrange to have something listening on port 443.


On Windows, Tomcat can listen directly on port 443. On UNIX and 
UNIX-like systems, you won't be able to do this without running Tomcat 
as root WHICH YOU ABSOLUTELY SHOULD NOT DO.


There are other ways to get port 443 working, but I'll need to know more 
about your environment. The port issue is "easier" than figuring out 
whatever is going on with your DNS, aliases, etc. so I would recommend 
we fix one thing at a time.


-chris


On Mon, Apr 29, 2024 at 2:03 PM lavanya tech 
wrote:


Hi Chris,

There is no issues with browser, because I tested with different browsers
and it all works fine. I am sure that there is no issue with the
certificate.
  Because I was able to establish successful connections with port 8443, it
just doesnot work with out port

  curl  https://example.lbg.com/towl
curl: (56) Received HTTP code 504 from proxy after CONNECT
curl: (56) Received HTTP code 504 from proxy after CONNECT


If you want to use port 443 (the default port for HTTPS) then you will
need to change Tomcat to bind to port 443 (if that's allowed on your OS)
or arrange to have port 443 routed to port 8443. You may need additional
configuration in Tomcat (specifically: proxyPort) to avoid having Tomcat
generate URLs with ":8443" in them.



should i use connect port like the above ?  But you mentioned before we
dont need any configuration changes. Please clarify I am not able to figure
this out and I have this issue many days pending. How to make it work with
port 8443 and with out port

Also I wanted to use weburl with alias name permanently instead of the
hostname. How can I achieve both

Thanks,
Lavanya


   -->


On Fri, Apr 26, 2024 at 9:28 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Lavanya,

On 4/25/24 07:24, lavanya tech wrote:

Hi Chris,

One question / doubt:

As I mentioned earlier, the below URLS already working in the browser

https://server.lbg.com:8443/towl
https://example.lbg.com:8443/towl -> redirect ( which means when I

hit in

browser) it points to https://server.lbg.com:8443/towl ---> To be

frank,

even I donot need redirect here, not sure why it redirects.

My question is why its working even though SAN is not registered with

the

certificate ? It doesnot even throw warning in the browser.


I'm not sure. Is it possible you have dismissed this error in the past
and the browser is remembering that? Try this with a different web
browser or maybe with curl from the command-line to see what happens.


Why https://server.lbg.com/towl or https://example.lbg.com/towl -->

How it

should work with New SAN certificate ?


You don't need to worry about the port number or application name, only
the hostname is a part of the SAN.

-chris


On Thu, Apr 25, 2024 at 10:16 AM lavanya tech 
Hi Chris,


Thanks I will request new certificate with SANs and I will try to fix

the

things from our end.

Best Regards,
Lavanya

On Wed, Apr 24, 2024 at 11:12 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Lavanya,

On 4/24/24 15:39, lavanya tech wrote:

Local host means the machine i am logged in to server.lbg.com

You are right, example.lbg.com is CNAME record.


Okay, thanks for clearing that up.


I dont have any SAN configured for the certificate. The certificate

is

requested for only server.lbg.com


You will never be able to make a secure request to anything other than
server.lbg.com without seeing an error. I highly recommend adding the
other hostname as a SAN to your certificate if you really want to
support this.

Even if you wanted https://example.lbg.com/whatever to return an HTTP
302 redirect to https://server.lbg.com/whatever, the user would see a
certificate hostname mismatch error which is ugly. It's best to make

it

work without users seeing ugly things.


So if i just request new certificate with SAN it should work ? If

yes, I

will request for it and follow your steps as below suggested.


Yes, it should.


Should i use CName record or DNS? Does it make difference?


CNAME *is* DNS.

Whenever possible, use hostnames and not IP addresses as SANs. It's

more

flexible that way, and users get to see hostnames instead of IP

addresses.


-chris


On Wednesday, April 24, 2024, Christopher Schultz <
ch...@christopherschultz.net> wrote:


Lavanya,

On 4/24/24 07:37, lavanya

Re: Regarding Tomcat url redirection

2024-04-30 Thread lavanya tech 
Hi Chris,

Can you tell me how to do the below ? How should I setup Tomcat in
server.xml ?


If you want to use port 443 (the default port for HTTPS) then you will
need to change Tomcat to bind to port 443 (if that's allowed on your OS)
or arrange to have port 443 routed to port 8443. You may need additional
configuration in Tomcat (specifically: proxyPort) to avoid having Tomcat
generate URLs with ":8443" in them.

Looking forward to your reply.

Thanks,
Lavanya

On Mon, Apr 29, 2024 at 2:03 PM lavanya tech 
wrote:

> Hi Chris,
>
> There is no issues with browser, because I tested with different browsers
> and it all works fine. I am sure that there is no issue with the
> certificate.
>  Because I was able to establish successful connections with port 8443, it
> just doesnot work with out port
>
>  curl  https://example.lbg.com/towl
> curl: (56) Received HTTP code 504 from proxy after CONNECT
> curl: (56) Received HTTP code 504 from proxy after CONNECT
>
>
> If you want to use port 443 (the default port for HTTPS) then you will
> need to change Tomcat to bind to port 443 (if that's allowed on your OS)
> or arrange to have port 443 routed to port 8443. You may need additional
> configuration in Tomcat (specifically: proxyPort) to avoid having Tomcat
> generate URLs with ":8443" in them.
>
> connectionTimeout="2"
>redirectPort="8443"
>maxThreads="150"
>scheme="https" secure="true" SSLEnabled="true"
>keystoreFile="path_to_your_keystore_file"
>keystorePass="your_keystore_password"
>keystoreType="PKCS12"
>clientAuth="false" sslProtocol="TLS"
>proxyPort="443"/>
>
> should i use connect port like the above ?  But you mentioned before we
> dont need any configuration changes. Please clarify I am not able to figure
> this out and I have this issue many days pending. How to make it work with
> port 8443 and with out port
>
> Also I wanted to use weburl with alias name permanently instead of the
> hostname. How can I achieve both
>
> Thanks,
> Lavanya
>
>
>   -->
>
>
> On Fri, Apr 26, 2024 at 9:28 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> Lavanya,
>>
>> On 4/25/24 07:24, lavanya tech wrote:
>> > Hi Chris,
>> >
>> > One question / doubt:
>> >
>> > As I mentioned earlier, the below URLS already working in the browser
>> >> https://server.lbg.com:8443/towl
>> >> https://example.lbg.com:8443/towl -> redirect ( which means when I
>> hit in
>> > browser) it points to https://server.lbg.com:8443/towl ---> To be
>> frank,
>> > even I donot need redirect here, not sure why it redirects.
>> >
>> > My question is why its working even though SAN is not registered with
>> the
>> > certificate ? It doesnot even throw warning in the browser.
>>
>> I'm not sure. Is it possible you have dismissed this error in the past
>> and the browser is remembering that? Try this with a different web
>> browser or maybe with curl from the command-line to see what happens.
>>
>> > Why https://server.lbg.com/towl or https://example.lbg.com/towl -->
>> How it
>> > should work with New SAN certificate ?
>>
>> You don't need to worry about the port number or application name, only
>> the hostname is a part of the SAN.
>>
>> -chris
>>
>> > On Thu, Apr 25, 2024 at 10:16 AM lavanya tech > >
>> > wrote:
>> >
>> >> Hi Chris,
>> >>
>> >>
>> >> Thanks I will request new certificate with SANs and I will try to fix
>> the
>> >> things from our end.
>> >>
>> >> Best Regards,
>> >> Lavanya
>> >>
>> >> On Wed, Apr 24, 2024 at 11:12 PM Christopher Schultz <
>> >> ch...@christopherschultz.net> wrote:
>> >>
>> >>> Lavanya,
>> >>>
>> >>> On 4/24/24 15:39, lavanya tech wrote:
>>  Local host means the machine i am logged in to server.lbg.com
>> 
>>  You are right, example.lbg.com is CNAME record.
>> >>>
>> >>> Okay, thanks for clearing that up.
>> >>>
>>  I dont have any SAN configured for the certificate. The certificate
>> is
>>  requested for only server.lbg.com
>> >>>
>> >>> You will never be able to make a secure request to anything other than
>> >>> server.lbg.com without seeing an error. I highly recommend adding the
>> >>> other hostname as a SAN to your certificate if you really want to
>> >>> support this.
>> >>>
>> >>> Even if you wanted https://example.lbg.com/whatever to return an HTTP
>> >>> 302 redirect to https://server.lbg.com/whatever, the user would see a
>> >>> certificate hostname mismatch error which is ugly. It's best to make
>> it
>> >>> work without users seeing ugly things.
>> >>>
>>  So if i just request new certificate with SAN it should work ? If
>> yes, I
>>  will request for it and follow your steps as below suggested.
>> >>>
>> >>> Yes, it should.
>> >>>
>>  Should i use CName record or DNS? Does it make difference?
>> >>>
>> >>> CNAME *is* DNS.
>> >>>
>> >>> Whenever possible, use hostnames and not IP addresses as SANs. It's
>> more
>> >>> flexible that way, and