Re: Tomcat 7.0.103

[Olaf Kock]

Hi Greg,

On 21.04.20 04:13, Hebner, Greg D. wrote:
> We are migrating from 7.0.68 to 7.0.103 to close some security 
> vulnerabilities. We are running LDAP authentication via JAAS. Authentication 
> was working normally on 7.0.68. we use scripts to configure Tomcat 
> installations so every install is exactly alike and we get expected results 
> and operation. On version 7.0.103, even though the catalina.out indicates 
> that LDAP authentication succeeded, I am returned to the login page. I have a 
> second authentication mechanism for non-LDAP authentication, and it still 
> operates normally.
>
> Is it possible that some configuration argument has been changed/added that 
> would cause this behavour? When I revert back to the 7.0.68 version, LDAP 
> authentication is restored. Help?

I didn't run into that issue, so can't answer from memory. But
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html might help
identifying - it's a bit of a reading, but might just help you find what
exactly changed and when.

Olaf


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

Tomcat 7.0.103

[Hebner, Greg D.]

We are migrating from 7.0.68 to 7.0.103 to close some security vulnerabilities. 
We are running LDAP authentication via JAAS. Authentication was working 
normally on 7.0.68. we use scripts to configure Tomcat installations so every 
install is exactly alike and we get expected results and operation. On version 
7.0.103, even though the catalina.out indicates that LDAP authentication 
succeeded, I am returned to the login page. I have a second authentication 
mechanism for non-LDAP authentication, and it still operates normally.

Is it possible that some configuration argument has been changed/added that 
would cause this behavour? When I revert back to the 7.0.68 version, LDAP 
authentication is restored. Help?

Greg D. Hebner
Senior Platform Engineer (Informatica Administrator)
WDP&R Technology
Office: (407) 248-7165  (Tie Line: 8-358-7165  Cellphone: 321-695-7707)
Email: greg.d.heb...@disney.com
Group Email:  #WDPR Informatica Admin Team

Re: JNDI match of LDAP hashed passwords fail against cleartext

[Mark Thomas]

On 19/04/2020 06:59, Brian Burch wrote:
> On 17/4/20 10:28 pm, Mark Thomas wrote:
>> On 16/04/2020 09:56, Brian Burch wrote:
>>> On 15/4/20 6:24 am, Mark Thomas wrote:
>>
>> 
>>
 I'd expect you to see an error message if your server.xml isn't quite
 right although that is what this looks like.
>>>
>>> There was no error message. I think my xml was syntax-free, but it did
>>> not reflect my intent.
>>
>> Can you provide before and after extracts from server.xml. I'm not 100%
>> what your non-working configuration looked like. I'll see if we can do
>> anything to highlight the configuration issue.
> 
> 
> My Realm definitions are always nested inside the https Connector and
> its Engine definition.
> 
> Here is the definitions of the two Realms for tc 7.0.52, which
> successfully authenticated the browser-supplied cleartext passwords
> against the SHA hashes from my LDAP server.
> 
>     cacheSize="1000"
>  failureCount="4"
>  lockOutTime="1200"
>  cacheRemovalWarningTime="86400" >
> 
>     connectionName="uid=tomcatAuthenticate,ou=Special
> Users,o=pingtoo.com"
>  connectionPassword=""
>  connectionURL="ldap://ldap.pingtoo.com:10389";
>  userBase="ou=people,o=pingtoo.com"
>  userSubtree="false"
>  userSearch="(uid={0})"
>  userRoleName="tomcatRole"
>  userPassword="userPassword"
>  digest="SHA" />
>   
> 
> The JNDIRealm is nested properly inside the LockoutRealm.
> 
> This server.xml could not authenticate users under tomcat 8.54,
> presumably because the Realm algorithm parameter had been deprecated.

If I take that and copy it to 8.5.54 (with a dummy password) the very
first line of the log file is:

20-Apr-2020 21:03:48.770 WARNING [main]
org.apache.tomcat.util.digester.SetPropertiesRule.begin
[SetPropertiesRule]{Server/Service/Engine/Realm/Realm} Setting property
'digest' to 'SHA' did not find a matching property.

I then patched 8.5.x so the JNDIRealm didn't complain when it couldn't
open a connection to an LDAP server (that was quicker than setting up an
LDAP server) to test your next configuration.

> 
> 
> The following Realm definition caused JNDIRealm to call
> MessageDigestCredentialHandler.matches, which called its own
> getAlgorithm method, which returned null (not SHA-1).
> 
>     cacheSize="1000"
>  failureCount="4"
>  lockOutTime="1200"
>  cacheRemovalWarningTime="86400" >
> 
>     connectionName="uid=tomcatAuthenticate,ou=Special
> Users,o=pingtoo.com"
>  connectionPassword=""
>  connectionURL="ldap://ldap.pingtoo.com:10389";
>  userBase="ou=people,o=pingtoo.com"
>  userSubtree="false"
>  userSearch="(uid={0})"
>  userRoleName="tomcatRole"
>  userPassword="userPassword" />
>      className="org.apache.catalina.realm.MessageDigestCredentialHandler"
>    algorithm="MD5" />
>   
> 
> My mistake was to Nest JNDIRealm properly, but code it as
> self-terminating. I guess the CredentialHandler was associated with the
> LockoutRealm, rather than the JNDIRealm.

Ah. Got it. You are right about what is happening.

I think we can add a warning for this case as a CredentialHandler set on
CombinedRealm will never be used. The other option would be to try and
look for a CredentialHandler on the parent Realm if the current Realm
doesn't have one but that will get really messy, really quickly with the
combination of nested Realms, nested CredentialHandlers and trying to
distinguish between a Realm that should inherit a CredentialHandler from
a parent and a Realm that deliberately does not have a CredentialHandler
(when the parent does).

> --
> 
> Just to finish the story, here's the properly nested version which works
> with SHA-1 and LDAP password hashes prefixed with {SHA}.
> 
>     cacheSize="1000"
>  failureCount="4"
>  lockOutTime="1200"
>  cacheRemovalWarningTime="86400" >
> 
>     connectionName="uid=tomcatAuthenticate,ou=Special
> Users,o=pingtoo.com"
>  connectionPassword=""
>  connectionURL="ldap://ldap.pingtoo.com:10389";
>  userBase="ou=people,o=pingtoo.com"
>  userSubtree="false"
>  userSearch="(uid={0})"
>  userRoleName="tomcatRole"
>  userPassword="userPassword" >
> 
>    className="org.apache.catalina.realm.MessageDigestCredentialHandler"
>   algorithm="SHA-1" />
>   
>   

Yep, that looks better.

> Thanks for your help getting me this far!

You are 

Re: Manager save text command bug giving path parameter

[Mark Thomas]

On 19/04/2020 18:34, Arnaud Yahoo wrote:
> Hello,
> 
> following
> https://tomcat.apache.org/tomcat-8.5-doc/manager-howto.html#Save_Configuration
> documentation,
> 
> calling save with path parameter is failing giving following error:
> *FAIL - Encountered exception [javax.management.MBeanException: Cannot
> find operation store] *
> 
> looking at Manager source code when path parameter is given
> org.apache.catalina.manager.ManagerServlet.save(PrintWriter, String,
> StringManager) is wrongly calling *store *operation with
> *java.lang.String* argument on JMX MBean *Catalina:type=StoreConfig
> *
> 
> There is no such method in this MBean which is implemented in
> *org.apache.catalina.storeconfig.StoreConfig*, the argument
> *org.apache.catalina.Context *should be called instead (confirmed by the
> fact that in source code the given argument is not a java.lang.String
> but a org.apache.catalina.Context)
> 
> I think even fixing ManagerServlet, it will probably still fail as it
> seems there is a typo in
> *org/apache/catalina/storeconfig/mbeans-descriptors.xml *
> **
> 
> / //   description="Store Context"//
> //   impact="ACTION" returnType="void" >//
> //   // description="Context"//
> // type="org.apache.catalina.context"/>//
> //    /
> 
> Type is supposed to be /org.apache.catalina.*C*ontext /I guess (wrong
> case for type)

Thanks for reporting this. All confirmed. I think there might be
additional issues as well. I'm working on fixes.

Mark

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

Re: JNDI match of LDAP hashed passwords fail against cleartext

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Brian,

On 4/17/20 08:28, Mark Thomas wrote:
> On 16/04/2020 09:56, Brian Burch wrote:
>> On 15/4/20 6:24 am, Mark Thomas wrote:
>
> 
>
>>> I'd expect you to see an error message if your server.xml isn't
>>> quite right although that is what this looks like.
>>
>> There was no error message. I think my xml was syntax-free, but
>> it did not reflect my intent.
>
> Can you provide before and after extracts from server.xml. I'm not
> 100% what your non-working configuration looked like. I'll see if
> we can do anything to highlight the configuration issue.
>
>> My tomcat users are in transition. Many still have SHA-1 LDAP
>> hashes, but for non-tomcat reasons they need to be migrated to
>> SHA-256 fairly soon.
>>
>> Having stepped through MessageDigestCredentialHandler.matches I
>> am surprised it makes an explicit test for
>> storedCredentials.startsWith("{SHA}"). This means the code is
>> too simplistic to recognise al LDAP hash of {SHA-1}. It certainly
>> can't recognise {SHA256} from the directory.
>>
>> https://docs.oracle.com/javase/7/docs/api/java/security/MessageDigest
.html
>>
>>
states the jvm is required to support the MD5, SHA-1 and SHA-256
>> algorithms, but I can't see how to coerce
>> MessageDigestCredentialHandler to recognise and match SHA-256
>> hashes.
>>
>> Do you agree with my analysis? Should I just hack the code and
>> see what happens?
>
> Chris is probably the best person to comment on this as he did the
> research and work on this.

Hmm. The LDAP stuff I think wasn't me, but I understand it a little
bit. Brian, is there a standard I can read for this? I'm familiar with
LDAP servers storing credentials with "{sha}" prefixes but not others.
Honestly, for an LDAP backend, I'd expect the LDAP server to be
checking the credentials sent by the client, not to have the client
fetch the credentials and do its own checking. That's the whole point
of delegating authentication to the LDAP server.

>> Also, given the LDAP mixture of SHA-1 and SHA-256 hashes, do you
>> think it is worth me trying to nest two CredentialHandlers within
>> the single JNDIRealm?
>
> Yes.
>
> From memory, each MessageDigestCredentialHandler uses a single
> hash. If you need to support multiple hashes you use the
> NestedCredentialHandler and nest multiple
> MessageDigestCredentialHandler instances, in preference order.
>
> Additional forms of {...} at the start of the hash look to
> something MessageDigestCredentialHandler needs to be adjusted to
> handle. Maybe look for {SSHA} first and then look for {...} and
> simply remove the {...} before processing the hash.
>
> Alternatively, a smarter MessageDigestCredentialHandler that looks
> at the leading {...} and adjusts the algorithm accordingly (maybe
> falling back to a configured default if none is found) looks to be
> a more efficient solution for your use case.

Honestly, allowing the LDAP server to consume the user's plaintext
password would probably be the best. I'm not sure familiar with
Tomcat's LDAPREalm, but I'm assuming you can either connect as a
service-user and then check other users' credentials, or you can use
the login-user's credentials to authenticate directly. The latter
scheme seems like a better plan to me: the server gets to make the
decision for how to check the credentials and Tomcat doesn't need to
worry about it at all.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6dyzEACgkQHPApP6U8
pFi+qQ/+OJ9xHJZ0ntR/1NIo++wYfZUus6QhJv3qWGIUCKqkTWUdf28A2u+00h1A
XMjf6imOrzOmTCD39t4DcQQQ5BGtn6a+NmCagDQ90UdtxS72YgoQhbimOrQHOjDS
ZRFpuAThVj3qldwKMNawOFSAQUlLt0a4t8SMYrKn8hIuMaiU9ze7BEr6/s7pDNgr
hLA/JZXF1BCowBQMBMWChZ3ryFaHjTfdREL1V59qCEY7+7w4e2oPJHT74lEoAU9N
1WX2CziILN8JUEMS8VFQ1y+il8dN+Yw1Jebb3iM8OgLj2qVSGVI7Zj/T3ScViH//
SexNTRTzeCAzOPD9g7k7QZEgE/DFWgDkAHzzmssmV0Ws/C02plJKFvMtDwLk37XS
Lp9YlymtJF3coypnvaBRcc8POI3q89NQvF4yPOXL3g4Y5Dm52qD+hCNZ21L3MfkT
6S0YdpX/DEs2MC6jFYpsI3r0gZppstRRt3YxnI9gLSZ0NrroMrOl60+QFBRduYYi
4mfuSyD8nhyVvualbvGg3b/x4qjPokEyuOygGmM6C3B18iWF9N1BiT49dmvooFuo
0Rp6ql0bx5nyRS5mfsonHgxJMQcmwSnkaIMProV+bbDBMVsjh1sEhad4jBtkHLzE
GN3iqt7iPrQ/1PgTVEkOpAuvnL4OdPcFTVIPfjkOSCvDwCFEh1I=
=370p
-END PGP SIGNATURE-

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

Re: JNDI match of LDAP hashed passwords fail against cleartext

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Brian,

On 4/20/20 12:17, Christopher Schultz wrote:
> Brian,
>
> On 4/17/20 08:28, Mark Thomas wrote:
>> On 16/04/2020 09:56, Brian Burch wrote:
>>> On 15/4/20 6:24 am, Mark Thomas wrote:
>
>> 
>
 I'd expect you to see an error message if your server.xml
 isn't quite right although that is what this looks like.
>>>
>>> There was no error message. I think my xml was syntax-free,
>>> but it did not reflect my intent.
>
>> Can you provide before and after extracts from server.xml. I'm
>> not 100% what your non-working configuration looked like. I'll
>> see if we can do anything to highlight the configuration issue.
>
>>> My tomcat users are in transition. Many still have SHA-1 LDAP
>>> hashes, but for non-tomcat reasons they need to be migrated to
>>> SHA-256 fairly soon.
>>>
>>> Having stepped through MessageDigestCredentialHandler.matches
>>> I am surprised it makes an explicit test for
>>> storedCredentials.startsWith("{SHA}"). This means the code is
>>> too simplistic to recognise al LDAP hash of {SHA-1}. It
>>> certainly can't recognise {SHA256} from the directory.
>>>
>>> https://docs.oracle.com/javase/7/docs/api/java/security/MessageDiges
t
>
>>>
.html
>>>
>>>
> states the jvm is required to support the MD5, SHA-1 and SHA-256
>>> algorithms, but I can't see how to coerce
>>> MessageDigestCredentialHandler to recognise and match SHA-256
>>> hashes.
>>>
>>> Do you agree with my analysis? Should I just hack the code and
>>> see what happens?
>
>> Chris is probably the best person to comment on this as he did
>> the research and work on this.
>
> Hmm. The LDAP stuff I think wasn't me, but I understand it a
> little bit. Brian, is there a standard I can read for this? I'm
> familiar with LDAP servers storing credentials with "{sha}"
> prefixes but not others. Honestly, for an LDAP backend, I'd expect
> the LDAP server to be checking the credentials sent by the client,
> not to have the client fetch the credentials and do its own
> checking. That's the whole point of delegating authentication to
> the LDAP server.
>
>>> Also, given the LDAP mixture of SHA-1 and SHA-256 hashes, do
>>> you think it is worth me trying to nest two CredentialHandlers
>>> within the single JNDIRealm?
>
>> Yes.
>
>> From memory, each MessageDigestCredentialHandler uses a single
>> hash. If you need to support multiple hashes you use the
>> NestedCredentialHandler and nest multiple
>> MessageDigestCredentialHandler instances, in preference order.
>
>> Additional forms of {...} at the start of the hash look to
>> something MessageDigestCredentialHandler needs to be adjusted to
>> handle. Maybe look for {SSHA} first and then look for {...} and
>> simply remove the {...} before processing the hash.
>
>> Alternatively, a smarter MessageDigestCredentialHandler that
>> looks at the leading {...} and adjusts the algorithm accordingly
>> (maybe falling back to a configured default if none is found)
>> looks to be a more efficient solution for your use case.
>
> Honestly, allowing the LDAP server to consume the user's plaintext
> password would probably be the best. I'm not sure familiar with
> Tomcat's LDAPREalm, but I'm assuming you can either connect as a
> service-user and then check other users' credentials, or you can
> use the login-user's credentials to authenticate directly. The
> latter scheme seems like a better plan to me: the server gets to
> make the decision for how to check the credentials and Tomcat
> doesn't need to worry about it at all.

Aha: if you remove this:

 userPassword="userPassword"

Then you'll end up "binding as user" instead of "comparing
credentials". If you do that, you'll delegate credential-checks to the
server.

In that case, I think you will not need any  or
anything like that.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6dzJMACgkQHPApP6U8
pFiboA/+L8+kTZxAWdKq+oO7bKMkC7DzVYCxzlXrPJpMzR1bO80cP8OTOY4EWQQ0
BafXn/PQ5SSZS4rNUjUX3tz5nlVVoPk3WP8jChdV7ccPzkEAxfGa3Dzzt7vX/h1F
npEh20Ss5p5ESIfo6rqawjW+9dwad4Ov2rXv4yjKNxvmrkIKjrKP+GMe9iZbZV78
G8JP/WdnEkBGu4gIo63L16zco7f6kKqNo5e9m2UKpeSgR00M92SxuhOG+f5RQhdf
n9RkaL0y2XXnbm2oXv2O1yFNXkl/uxe3ySKVqJeEImrHyWoqdi4Z9qSIknjZoPjY
S1WUOgmxLqqIrssdBl0/BJBFezVFO0zBiKd9DXZg4nALp3aVwHpJrg6tXg7qhiON
nuiPY1bMXJzTF9TFFTnYNb1AxWW0T37VJx2Ni6/uAOXTdK0yDAB+9itz/kLgVgvx
3RS1P74VJ6u508iX30c04kXa1qZBfDpcpyAiRQEsKONHkU2mZPBFGuDBATyOc0n+
poAdnhDlOLP7FyrXwdDAxPpDXVDsX1KrRqxhVvXNrBBPCEkzZa6vWOdJz58JB84Z
CgbNaxd2gcPx9kogZ7183Xs91t4KsqZtbOzFQPdQINvNuRB0SkMCGpRM6vsJ5eoz
jUYcMhnzSk4vCqipgn42X+uEEqRxt5EwoMN6esCe/BkY9dgPOkE=
=ZSsb
-END PGP SIGNATURE-

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

Re: Reverse proxy and SSL redirect

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John,

On 4/17/20 13:02, rugman66 . wrote:
> I have Apache 2.4.6 running as reverse proxy

Stop right now and patch that thing.

> for Tomcat 7.0.96

Not quite as old, but depending upon your environment, there may be
some critical changes in later versions. (Looks like you are using
mod_proxy_http and should therefore be okay for the worst of these
issues).

> both running SSL, and a functioning redirect from HTTP to HTTPS
> for both Apache and Tomcat.


> ( Need to use both these releases due to IT availability and app
> requirements )
You (or someone else) is making a dangerous security decision by
staying on these versions. If you can't get someone to change their
mind, you may want to remove yourself from the situation or end up
being blamed for your upcoming intrusion.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6dyYIACgkQHPApP6U8
pFjvUw/9EW+34NLWMDALVUoh5hWdvDChoozLAO34a27TAqtqZWqG+QQUKRJId64y
pHrFWrH2P+3E9VqkMdKrXVmQLFX7NJJfCzN1eB1PcQuWs/JOCoFCGKgM6V/MTgpq
QucO/kQ5r1YJge1Us9KmF+FHLdHCFfzB20vUcL6BoteVTnd/j5BQ3mHGOuy3Lnja
SJC4WX9AJF6vFixLL0AMRif+0njQY3NarXvOFppGBNA0cfWdqYv5SZxe9p1K80sB
y0z71v2S1+Cex+4Rmpk86Eq6kWdG1UTpRbmasr6IKlQ11pgsykUwPbbREUxu5rQQ
/HUCx5nugYRbnOTMklLdU1DCqA+kypS749bEm28YtPVUCz5GUUJSJp+rG92tTWl5
RxUprl0it+4dVV/jjIigMjkosp2sBm8lkuFNcsSGiH1zTof2fIRnxVtYOtrzhs63
5iDxjRKrLdG7F1UZDrGal7adGJ3677RT+ZYE2ZzBr08tx3FAlKQ6jk816wE7egn4
cH4XEwk6YAJuxMXtNLRooz4eEJgo3BrxJT4TJNvdlaIijFt9XeIwHDhlvzdHOmhe
GTTbtzH0AASoBSMh97TzZ9ktpnQ+tEQvq9bhGpjoJfCSs1wEw2a/x3uA/Qjc7kcb
CJlTeiqtoytfNF+IhJvJANg6hiYKmo5L7cwUWtyyXdS4MK6ZdnM=
=8RC0
-END PGP SIGNATURE-

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

Re: How to shutdown tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Olaf and Blake,

On 4/17/20 11:51, Olaf Kock wrote:
>
> On 17.04.20 16:55, Blake McBride wrote:
>> I suppose, never mind.  I created a startup listener that just
>> does a System.exit(0) on contextDestroyed which is what I want -
>> exit.
>>
>> Thanks.
>>
>> Blake
>>
>>
>> On Fri, Apr 17, 2020 at 8:53 AM Blake McBride
>>  wrote:
>>
>>> Greetings,
>>>
>>> I am running vanilla tomcat 9.0.34 on a 64 bit Linux box.
>>> Short of killall, I can't stop tomcat.  I am trying
>>> bin/shutdown.sh.  Sure appreciate some help.
>
> The proper solution is in your log:
>
> "The web application [Kiss] appears to have started a thread named
> [Thread-5] but has failed to stop it."
>
> If that's not a daemon thread, the JVM, by design, can't stop.
>
> Instead of calling System.exit(), do the right thing and implement
> proper shutdown for all threads that the application starts on its
> own.

+1

> By the way: This behavior will keep the application from proper
> redeployment. My recommendation: Correct your implementation rather
> than nuking it from orbit.

+1

Calling System.exit() will cause your (Blake's) application to
take-down the JVM every time it stops. Maybe that's okay for the time
being, but being able to deploy an updated version of your application
without any downtime might be a desirable feature.

- -chris

>>> 17-Apr-2020 08:44:41.745 WARNING [main]
>>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThre
ads
>>> The web application [Kiss] appears to have started a thread
>>> named [Thread-5] but has failed to stop it. This is very likely
>>> to create a memory leak. Stack trace of thread:
>>> sun.misc.Unsafe.park(Native Method)
>>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>>>
>>>
>>>
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.aw
ait(AbstractQueuedSynchronizer.java:2044)
>>>
>>> java.util.concurrent.LinkedBlockingDeque.takeFirst(LinkedBlockingDeq
ue.java:492)
>>>
>>>
org.kissweb.rest.QueueManager$Dispatcher.run(QueueManager.java:61)
>>> java.lang.Thread.run(Thread.java:748) 17-Apr-2020 08:44:41.745
>>> WARNING [main]
>>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThre
ads
>>> The web application [Kiss] appears to have started a thread
>>> named [pool-1-thread-1] but has failed to stop it. This is very
>>> likely to create a memory leak. Stack trace of thread:
>>> sun.misc.Unsafe.park(Native Method)
>>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>>>
>>>
>>>
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.aw
ait(AbstractQueuedSynchronizer.java:2044)
>>>
>>> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.ja
va:442)
>>>
>>>
>>>
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:
1074)
>>>
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor
.java:1134)
>>>
>>>
>>>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
va:624)
>>> java.lang.Thread.run(Thread.java:748) 17-Apr-2020 08:44:41.749
>>> INFO [main] org.apache.coyote.AbstractProtocol.stop Stopping
>>> ProtocolHandler ["http-nio-8080"] 17-Apr-2020 08:44:41.750 INFO
>>> [main] org.apache.coyote.AbstractProtocol.destroy Destroying
>>> ProtocolHandler ["http-nio-8080"]
>>> blake@i9-tower:~/intellijProjects/Kiss/tomcat/logs$
>>>
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6dxxMACgkQHPApP6U8
pFjMwBAAl0Xh2yGJ5x+zpIXFUGhKY/laHdWq7mTXQiioPSpPwAuBKlScujtwWRBn
7eD/mdldJI/G+whyzmSSkxpo/oBpuxq9RL/SbtYrVk5u9XBgqB0ylQLUW/VnNo/0
D/jEKMrTtorn3hHEUeKqDPpmFdlbYOPTBkM/+Kl9DPZLGyLZCdhc9z7Bqcgrbf+V
dghRxMC1PW2gZRT0xMrLKGdESf8hoN31x91uBEWeEtpNZEKy5pE37OaEZRjZIEg8
WbDJDTNQ+AhcPIWUsEyCPPD05SMoq5nk7QUb91nZzvvoA/EQ3kUutfOyWKf+Oq8V
lSFOJyjcF9/d24/iMviZw1ILXuft/yvZObvkETCg0OnEmlCpBKAD3y+WCjbJi2fI
5Uff1T+w2zr2/Ml9f1WR3KLJKnA3rBK+SdmoDk/5ld2C++Dq31drCj4sVFcHQ4Pr
WU8sbAbSZW99r6qKTJEfALu/DYYzRtQBWVD+ZOwCv00VS50Elf//N2Jx/5Xnoomx
UwMpX83NbFT1AuTQfz99jSup8JSoKeYv78z9T0Fajn6Pjw3NLQpoyegI6l9NEKib
zWV+BOCVgIZKdneBTd/+cTc2fW4Cg+SrxtXUrnCDtOyMKTGHrzoSuMb0UhcRD/D1
zz6aVNHVn4xRFwPf/oX+c67ZDIQRuweMAqxsYMLqGEvDLsPzqh8=
=2Fvb
-END PGP SIGNATURE-

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

Re: Is ARM64 architecture officially supported ?

[Martin Grigorov]

Hi Michael,

On Sun, Apr 19, 2020 at 9:08 PM Michael Osipov  wrote:

> Am 2020-04-19 um 19:51 schrieb Martin Grigorov:
> > Hi Emilio,
> >
> > On Fri, Apr 17, 2020 at 2:14 PM Emilio Fernandes <
> > emilio.fernande...@gmail.com> wrote:
> >
> >> Hola Tomcat community!
> >>
> >> We consider using AWS Graviton [1] based instances which use ARM64
> >> processors for our backend services.
> >> I've googled around and found [2] saying that Tomcat is being tested on
> >> ARM64 architecture at TravisCI! This is great!
> >> Does this mean that Tomcat is officially supported on ARM64 ? I was not
> >> able to find any specific documentation listing which platforms are
> >> officially supported.
> >>
> >> Does anyone from the community have any experience with Tomcat/HTTPD on
> >> ARM64 in production ?
> >>
> >
> > I work a lot with ARM64 servers lately!
> > So far we didn't face any issue related to ARM64 & Tomcat in our
> > application!
> > I've introduced the testing on TravisCI that you have found. In addition
> > for my daily job we have created a nightly test setup:
> > - build and test Tomcat 9.x (as at Travis)
> > - run some smoke tests with our application
> > - run some performance tests on x86_64 and ARM64 VMs with similar
> hardware
> > specs. The results for both architectures are very similar. One thing
> that
> > still bothers me is that the throughput on HTTPS is 3 times less than
> HTTP.
>
> OpenSSL or SunJSSE?
>

Both.
With OpenSSL it is slightly faster than with JSSE, but again around 3 times
slower than HTTP.

Here are some details:
Tomcat: 9.x nightly build
tcnative: nightly build from master branch
JDK: AdoptJDK 14
OpenSSL 1.1.1  11 Sep 2018 (this comes from Ubuntu 18.04 repos. I will try
with a newer build)
JMeter: 5.2.1
The application is Spring Boot 2.2.6 with REST GET/PUT/POST/DELETE
endpoints that simply sets/gets data to/from Memcached. No usage of Spring
Security! No redirects from HTTP to HTTPS!

Let me know if you need more information!