Re: Question about thread's "keep alive time" value in Embed Tomcat 8.5 in Spring Boot 1.5

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Roy,

On 11/4/19 18:22, Roy Zhang wrote:
> Dear Christopher,
> 
> Really appreciate ur quick response! Sorry for late reply due to
> personal affairs...
> 
 I haven't read the code in detail, but I'm guessing that the
 thread pool
> uses a queue and not a stack of threads, so each thread gets used, 
> repeatedly, in order of availability.
 Note that Tomcat's thread pool is just a wrapper around
 Java'sThreadPoolExecutor
> -- adding methods to handle Tomcat's lifecycle events, etc.
 So if the pool isn't behaving as you'd like it, you'll need
 to file a
> but against the Java API and not Tomcat. [Roy] Based on ur comment,
> my understanding is tomcat is using Java'sThreadPoolExecutor, 
> Java's ThreadPoolExecutor pick up new threads from thread pool
> using FIFO approach. Regarding "So if the pool isn't behaving as
> you'd like it, you'll need to file a but against the Java API and
> not Tomcat.", do we have any mature solution (e.g, any open source
> project) which change the tomcat thread pool's behavior (e.g, FIFO
> approach)?

So you'd like to use a LIFO thread pool? If you can find a LIFO
executor in Java, then we can probably configure it in Tomcat. But
writing a LIFO executor isn't exactly on our list of things to add to
Tomcat itself.

What's the goal, here? Your process must be able to tolerate a
completely full thread-pool, so you have to plan for maximum capacity.
Reducing process threads buys absolutely you nothing except bragging
rights for "using the fewest possible resources".

If you want fewer threads, make your thread pool smaller.

If you want to auto-scale, don't look at live-threads. Look instead at
recent-peak-concurrency.

- -chris

> On Fri, Nov 1, 2019 at 9:56 PM Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Roy,
> 
> On 11/1/19 08:23, Roy Zhang wrote:
 I am confused about "keep alive time" value in Embed Tomcat.
 I am using Spring Boot 1.5, embed tomcat version is 8.5.
 
 According to 
 https://github.com/spring-projects/spring-boot/issues/16450#issueco
mme
>
 
nt-480236238
> 
>
> 
,
 
 
> we can't configured thread's "keep alive time" via "maxIdleTime"
 parameter, "keep alive time" value is hard coded as 60s via 
 https://github.com/apache/tomcat/blob/de1f55e672106031821948d5cac80
f40
>
 
adc09513/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L884
> 
>
> 
,
> 
> It
 
> is only hard-coded if you use the internal, default Executor. You 
> can instantiate your own Executor with whatever settings you wish.
> 
> It's a bad name for that setting, but this is how long "excess" 
> threads will live when they are not being used.
> 
 I found 60s "keep alive time" sometimes take effect, some
 times it doesn't take effect. Could u please kindly help to
 review my following two cases and kindly provide explanation?
 Really appreciate ur help in advance!
 
 *Case 1 (60s "keep alive time" DOESN'T take effect):* API
 latency: _100ms_ Test step: run API with 800 concurrent
 threads for 1 minutes, then run API with 10 concurrent
 threads for about 1 hour. As we can see from following graph,
 after BusyThreads reduced from ~800 to 10,
 CurrentThreadsCount remains at 800 for following 1 hour (60s
 "keep alive time" DOESN'T take effect). After test stopped, 
 CurrentThreadsCount reduced from 800 to
 100(MinSpareThreads). image.png
> 
> Your images have been stripped from the mailing list. Find another
> way to describe your problem.
> 
> When you say "X concurrent threads", how often are requests being 
> made? Constantly? So you are sending requests as fast as possible
> with c=10?
> 
> I haven't read the code in detail, but I'm guessing that the
> thread pool uses a queue and not a stack of threads, so each thread
> gets used, repeatedly, in order of availability. That means that if
> you keep making requests, you'll keep hitting *all* the threads in
> the queue and not just the same 10 over and over again. So they
> never time out.
> 
 *Case 2 (60s "keep alive time" DOES take effect):* API
 latency: _10s_ Test step: run API with 800 concurrent threads
 for 1 minutes, then run API with 10 concurrent threads for
 about 1 hour. As we can see from following graph, after
 BusyThreads reduced from ~800 to 10, CurrentThreadsCount
 reduced from 800 to 100(MinSpareThreads). 60s "keep alive
 time" DOES take effect)
> 
> Note that Tomcat's thread pool is just a wrapper around Java's 
> ThreadPoolExecutor -- adding methods to handle Tomcat's lifecycle 
> events, etc.
> 
> So if the pool isn't behaving as you'd like it, you'll need to file
> a but against the 

Re: How to stop logging 401 unauthorized errors

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dean,

On 11/5/19 16:52, Dean Del Ponte wrote:
> I'm using Tomcat 9.0.26 on Ubuntu.
> 
> I would like to configure Tomcat to NOT log any 401 - unauthorized
> errors.
> 
> What's the best way to do this?

What kind of logging are you trying to suppress?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3CBB0ACgkQHPApP6U8
pFjv8g/9Ee20i0iYBlDns/3HMtfmrAWvUNsSjhbx7llUn5ZFpc4pkIj30O1zyqLb
wDdjA4shnVUncgvWWZNfrk4vWmQ+PY5MaSSatxektchDcmkSXHy7dmxxQy0sd83l
zfmfsc4MGCgw8rhyB7/p2BILmEIlc11qZLnbUc10D1/oUHvbVZ7mO+d6wpURZhEG
EQ516YUBUBSeMQknis4BaGjcRDniK5Q1qimnFQqbXZaclQOc0liSGzNhh3nQES4A
9HflxwxI0k5l+C1+j/lT6DwX58Md3RI7POhDM59LYFGp5yXKymnXKXSvO+6/yHcF
ZTQmyQl7aTNUz4NZuseUssDqhHMR19H4Dvdk8ufcfFuRdDobRIzjSi6VdH0eYkyk
JfEAT3yv4m5aSNeFjbq7TrHFxi6tBnN7iNSIEy5h8C4p6apIH/6akXjAvTuke0yM
L6U5z12ZVy+zR6tSosYSPmXZEQ4kp8RIYbctKmK/g0rfd9o8ENcKJ3C5wCBKED7A
5RcQJU1ZZSpKgMRPMj6iqgmUDEopWWr/+pHTUdrJI1a3gI9CiwzCQ5aGWkXfmn6v
gcWfTMXbwlKbx3uppgaVPsvJnFkLK75159Q5yzZJaCakN6UOXlj7KskO/gqyqfI5
PZUlMCWfRKGXhfItsZW942xeya/l3c45oJ61+RGsXJ1oA6PkHZc=
=d8j2
-END PGP SIGNATURE-

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

Re: Generating passwords digests for 9.0.27

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Pawel,

On 11/5/19 03:33, Mark Thomas wrote:
> On 05/11/2019 00:52, Pawel Veselov wrote:
>> Hello.
>> 
>> I'm doing something where I need to generate a password for a
>> tomcat user that is authenticated using
>> org.apache.catalina.realm.UserDatabaseRealm with "sha" digest,
>> the user database is produced by
>> org.apache.catalina.users.MemoryUserDatabaseFactory from an xml 
>> file (standard conf/tomcat-users.xml)
>> 
>> Reading 
>> https://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html#Digested_Pa
sswords
>> I see that it says:
>> 
>>  If you are writing an application that needs to calculate
>> digested passwords dynamically, call the static Digest() method
>> of the org.apache.catalina.realm.RealmBase class, passing the
>> cleartext password, the digest algorithm name and the encoding as
>> arguments. This method will return the digested password. 
>> 
>> 
>> However, there is no static method Digest in
>> org.apache.catalina.realm.RealmBase.
>> 
>> What is the proper way to programmatically generate a proper
>> password hash?
> 
> See org.apache.catalina.realm.RealmBase.main(String[] args)

There is also bin/digest.sh and bin/digest.bat, if you happen to have
a package which contains the scripts.

Run that command and you'll get some help text.

I would highly recommend against using "plain-old SHA-1" signatures.

Have a look at this presentation for some hopefully good justification
and ideas for making things better:

https://tomcat.apache.org/presentations.html#latest-credential-security

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3CAzEACgkQHPApP6U8
pFg++A/+Mpev6LEDPCYDVNzTQYZc9+baSDwH7d4yO3vUweh890VVzkmXqSn4mCnY
ti9xMcc1pcXYC18q0Vr65X54H5r/o1PtfIiezhNRJdnVzpOr7uUMINuWV7Tt5heN
UIgdc48CmvA4KC2wP7YsnkGi61KU50p2h0N/vCxIrWMFRhE5R/QcH50ruRZPb9g1
FdsiTPgPS7DhIlBs8rY64P/ERwTKAYIPU+Y/zFCCZQlog6XfLpilBF8O7zCOz+ls
gHkOx02YaYZs2g5tg1SUEI9fx4Lb5pNsSuq3VuWUM9uylCTYQuvaUeSo4L21T4dP
gSvQBRvrPa4ZD/H5aTSWjOI6+1D8pndphxYNPa6NIBnRyTXL0+1hm2IeStzwf+0x
Uag9Uwjc67iZKTJd6eLtpzrLoDZpMHYxfmo1KAZe5+LjY3vLFirNAQqpBrjqSjjR
bBLCrkIh8Ao1i9s5Yyuol3KAJklZFRhhqOYirO0/upySzxuTo1+8XED28bQIAtcs
3bE4ON1VBwlMrMDRccZmMsdiPBOKmjs/NmvIyrqPL3TXZ5tx7BdeszgMcuAfny6U
pZRIqRxtiT8/moTRfBH63F7Qnl5xOuCXetGGq/uFwrCNIyLjK70vfL7y5tjNm3z4
y8csIdM7rC+i83pL4z21m9pHo3OwLr79hTMdN7JlyxF6CpKvF1k=
=vTrl
-END PGP SIGNATURE-

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

How to stop logging 401 unauthorized errors

[Dean Del Ponte]

I'm using Tomcat 9.0.26 on Ubuntu.

I would like to configure Tomcat to NOT log any 401 - unauthorized errors.

What's the best way to do this?

Thanks!

Re: Roadmap for Tomcat and Jakarta EE

[Campbell, Lance]

Thanks.

On 11/5/19, 1:33 PM, "Rémy Maucherat"  wrote:

On Tue, Nov 5, 2019 at 8:19 PM Campbell, Lance  wrote:

> Is there an article describing a general roadmap for Tomcat and Jakarta EE
> that I could read?
>

http://tomcat.apache.org/presentations.html
The latest "State of the Cat" presentation from ApacheCon EU looks into the
Jakarta stuff.

Rémy


>
>
> Thanks,
>
>
>
> *LANCE CAMPBELL *
>
> *Software Architect*
>
>
>
> Web Services 
>
> Public Affairs 
>
> Contact the Webtools Team 
>
> 217.333.0382
>
> la...@illinois.edu
>
>
>
>
>
> [image:
> 
/var/folders/wp/1f6l7hw95y718z976kgnl5f9kr5rtc/T/com.microsoft.Outlook/WebArchiveCopyPasteTempFiles/signature_logo.png]
> 
>
>
>
> *Under the Illinois Freedom of Information Act any written communication
> to or from university employees regarding university business is a public
> record and may be subject to public disclosure.*
>
>
>

Re: Roadmap for Tomcat and Jakarta EE

[Rémy Maucherat]

On Tue, Nov 5, 2019 at 8:19 PM Campbell, Lance  wrote:

> Is there an article describing a general roadmap for Tomcat and Jakarta EE
> that I could read?
>

http://tomcat.apache.org/presentations.html
The latest "State of the Cat" presentation from ApacheCon EU looks into the
Jakarta stuff.

Rémy


>
>
> Thanks,
>
>
>
> *LANCE CAMPBELL *
>
> *Software Architect*
>
>
>
> Web Services 
>
> Public Affairs 
>
> Contact the Webtools Team 
>
> 217.333.0382
>
> la...@illinois.edu
>
>
>
>
>
> [image:
> /var/folders/wp/1f6l7hw95y718z976kgnl5f9kr5rtc/T/com.microsoft.Outlook/WebArchiveCopyPasteTempFiles/signature_logo.png]
> 
>
>
>
> *Under the Illinois Freedom of Information Act any written communication
> to or from university employees regarding university business is a public
> record and may be subject to public disclosure.*
>
>
>

Roadmap for Tomcat and Jakarta EE

[Campbell, Lance]

Is there an article describing a general roadmap for Tomcat and Jakarta EE that 
I could read?

Thanks,

LANCE CAMPBELL
Software Architect

Web Services
Public Affairs
Contact the Webtools Team
217.333.0382
la...@illinois.edu


[/var/folders/wp/1f6l7hw95y718z976kgnl5f9kr5rtc/T/com.microsoft.Outlook/WebArchiveCopyPasteTempFiles/signature_logo.png]

Under the Illinois Freedom of Information Act any written communication to or 
from university employees regarding university business is a public record and 
may be subject to public disclosure.

Re: Help requested to fix the tomcat vulnerability

[Magosányi Árpád]

Hi,

I suggest to follow this guide:
https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html

On 11/5/19 2:29 PM, thulasiram k wrote:
> Hi,
>
> we have installed tomcat 7.0.94 on windows 2016 and no SSL enabled. But
> while qualys scan we found the below vulnerability. can you guide how can
> we fix it.
>
> 1)
> QID : 86763 - Web Server Uses Plain Text Basic Authentication
> Impact : Using Readable Clear Text can help eavesdropping and thereby
> compromise confidentiality.
> An attacker can successfully exploit this issue when the 401 error is
> returned when authentication is required. Also, an attacker can find out
> that the Basic Authentication scheme is used using the WWW-authenticate
> header.
>
> I can see requests are redirecting to 8443 from server.xml
>
> 
> connectionTimeout="2"
>
> redirectPort="8443" />
> let me know if you have any suggestions.
>
> Thanks
> Ram
>


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

Help requested to fix the tomcat vulnerability

[thulasiram k]

Hi,

we have installed tomcat 7.0.94 on windows 2016 and no SSL enabled. But
while qualys scan we found the below vulnerability. can you guide how can
we fix it.

1)
QID : 86763 - Web Server Uses Plain Text Basic Authentication
Impact : Using Readable Clear Text can help eavesdropping and thereby
compromise confidentiality.
An attacker can successfully exploit this issue when the 401 error is
returned when authentication is required. Also, an attacker can find out
that the Basic Authentication scheme is used using the WWW-authenticate
header.

I can see requests are redirecting to 8443 from server.xml


let me know if you have any suggestions.

Thanks
Ram

Re: Intermittent JSP Caching/Compiling Issue while under load

[Tim K]

On Tue, Nov 5, 2019 at 3:01 AM Mark Thomas  wrote:
> This looks like some sort of concurrency issue. In your test
> environment, how likely is it that:
> - there are concurrent (or at least very close together) changes to a
>   JSP
> - that there are concurrent requests for a modified JSP?

In my test env, I am the sole person making changes to the JSP.  Also,
in production, its only 1 single person making changes to a particular
JSP.

It is very likely that there are concurrent requests for the modified
JSP.  That is exactly how I am reproducing this, I basically have a
curl command being executed every 0.5-1 seconds for that modified JSP
when this intermittent issue occurs.  With high production traffic,
it's very possible that one or more users are hitting a modified JSP.

> Also, what process are you using to update the JSP content?

In my tests, I'm simply using VIM, in production, it's using a content
management system which likely just copies the new JSP over, similar
to an rsync or cp command.  The issue is reproducible in both cases,
as long as there are active requests for the modified JSP.

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

Re: Generating passwords digests for 9.0.27

[Mark Thomas]

On 05/11/2019 00:52, Pawel Veselov wrote:
> Hello.
> 
> I'm doing something where I need to generate a password for a tomcat user
> that is authenticated using org.apache.catalina.realm.UserDatabaseRealm
> with "sha" digest, the user database is
> produced by org.apache.catalina.users.MemoryUserDatabaseFactory from an xml
> file (standard conf/tomcat-users.xml)
> 
> Reading
> https://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html#Digested_Passwords I
> see that it says:
> 
> 
> If you are writing an application that needs to calculate digested
> passwords dynamically, call the static Digest() method of the
> org.apache.catalina.realm.RealmBase class, passing the cleartext password,
> the digest algorithm name and the encoding as arguments. This method will
> return the digested password.
> 
> 
> However, there is no static method Digest
> in org.apache.catalina.realm.RealmBase.
> 
> What is the proper way to programmatically generate a proper password hash?

See org.apache.catalina.realm.RealmBase.main(String[] args)


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

Re: Intermittent JSP Caching/Compiling Issue while under load

[Mark Thomas]

On 05/11/2019 02:51, Tim K wrote:



> The cached JSP actually survives a tomcat restart because the work
> directory still contains the cached JSP content even though the timestamp
> of the class/java files appear to match that of the latest JSP file's
> content.

Ah. That is useful new information. It rules out the non-volatile field
issue I found yesterday as the root cause (the issue has been fixed
anyway for the next round of releases). I'll take another look at the
source.

This looks like some sort of concurrency issue. In your test
environment, how likely is it that:
- there are concurrent (or at least very close together) changes to a
  JSP
- that there are concurrent requests for a modified JSP?

Also, what process are you using to update the JSP content?

Mark

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