Re: TomcatCon Meetup (UPDATE)

[Coty Sutherland]

Aw, I missed the picture :( maybe I'll have my wife Photoshop me in

On May 18, 2017 4:19 PM, "Leon Rosenberg"  wrote:

> Awesome, thanks!
>
> Sent from my iPhone
>
> > On 18. May 2017, at 14:58, Huxing Zhang  wrote:
> >
> > Hi All,
> >
> > The pic for the meetup yesterday can be found here:
> >
> > https://www.dropbox.com/s/vu02lnrs77up5mc/IMG_0591.JPG
> >
> >> On Wed, May 17, 2017 at 8:46 PM, Coty Sutherland 
> wrote:
> >> Sorry I had to run off, hopefully you guys had a productive meeting :)
> >>
> >>> On May 17, 2017 7:02 PM, "Coty Sutherland" 
> wrote:
> >>>
> >>> We're sitting next to the pool. The room is occupied :(
> >>>
> >>> On May 17, 2017 9:12 AM, "Christopher Schultz" <
> >>> ch...@christopherschultz.net> wrote:
> >>>
>  All,
> 
>  Let's move the Meetup to "immediately following the Lightning Talks",
>  since that is a popular event at the conference.
> 
>  -chris
> 
> >
> > All,
> >
> > For those of you at ApacheCon in Miami, here are the details for the
>  Tomcat Meetup. Come and meet fellow members of the community,
> committers,
>  and new friends.
> >
> > Time: 18:00 EDT
> > Place: Escorial Conference Room (where all TomcatCon sessions are
> being
>  held)
> >
> > All are welcome to the meetup, and also the inevitable dinner and
>  drinks to follow.
> >
> > Thanks,
> > -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: Tomcat 7.0: getting digester.Digester startElement error

[Saurav Maulick]

here is the error : digester.Digester startElement SEVERE: Begin event
threw error

On Thu, May 18, 2017 at 3:10 PM, Mark Thomas  wrote:

> On 18/05/2017 19:59, Saurav Maulick wrote:
>
>> Hi Team,
>>
>> After doing windows patch installation we are getting digester.Digester
>> startElement error. Can you please help on this? we are using Tomcat 7.0.
>>
>> Inline image 1
>>
>
> Images get removed by the mail list software. Please paste the text of the
> error you are seeing.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Thanks and Regards,
Saurav Maulick

Re: TomcatCon Meetup (UPDATE)

[Leon Rosenberg]

Awesome, thanks!

Sent from my iPhone

> On 18. May 2017, at 14:58, Huxing Zhang  wrote:
> 
> Hi All,
> 
> The pic for the meetup yesterday can be found here:
> 
> https://www.dropbox.com/s/vu02lnrs77up5mc/IMG_0591.JPG
> 
>> On Wed, May 17, 2017 at 8:46 PM, Coty Sutherland  wrote:
>> Sorry I had to run off, hopefully you guys had a productive meeting :)
>> 
>>> On May 17, 2017 7:02 PM, "Coty Sutherland"  wrote:
>>> 
>>> We're sitting next to the pool. The room is occupied :(
>>> 
>>> On May 17, 2017 9:12 AM, "Christopher Schultz" <
>>> ch...@christopherschultz.net> wrote:
>>> 
 All,
 
 Let's move the Meetup to "immediately following the Lightning Talks",
 since that is a popular event at the conference.
 
 -chris
 
> 
> All,
> 
> For those of you at ApacheCon in Miami, here are the details for the
 Tomcat Meetup. Come and meet fellow members of the community, committers,
 and new friends.
> 
> Time: 18:00 EDT
> Place: Escorial Conference Room (where all TomcatCon sessions are being
 held)
> 
> All are welcome to the meetup, and also the inevitable dinner and
 drinks to follow.
> 
> Thanks,
> -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: Tomcat 8.5.4 and LegacyCookieProcessor

[Mark Thomas]

On 18/05/2017 19:12, Caldarale, Charles R wrote:

From: jared.paul.wal...@gmail.com [mailto:jared.paul.wal...@gmail.com] On 
Behalf Of Jared Walker
Subject: Tomcat 8.5.4 and LegacyCookieProcessor



We are migrating to the version of tomcat identified in the subject


Before exposing an almost year-old version to the nasty real world, you might 
want to look at this:
 http://tomcat.apache.org/security-8.html
and then pick a newer level (hint: 8.5.15 would be good).


Plus that version includes a fix for the problem the OP is seeing:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60627



1. What are the security and compatibility concerns when using the
legacy processor


Sorry, can't answer that one.


Security concerns - none known (if there were we'd have fixed them)

Compatibility - tends to play better with older browsers. Lots of config 
options to handle various edge cases.


Mark




2. The header for LegacyCookieProcesor.java explicitly states: "This
class is not thread-safe."



Can someone here with background knowledge explain exactly whats not
thread-safe about the processor?  Does this mean you cannot use it for
multiple simultaneous requests (pretty hindering for a server) or does
this mean that you cannot have multiple threads parse the cookie
contents of a request in parallel (which isn't a very normal thing to
do)?


It's neither, really; there is one instance of CookieProcessor per , and the 
fields within LegacyCookieProcessor that make it not thread-safe are only set (in Tomcat) 
when the  is initialized.  Were you to dynamically reset the fields while 
requests were in progress, you could get in trouble.  The fields are described here:

http://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html

  - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
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 7.0: getting digester.Digester startElement error

[Mark Thomas]

On 18/05/2017 19:59, Saurav Maulick wrote:

Hi Team,

After doing windows patch installation we are getting digester.Digester 
startElement error. Can you please help on this? we are using Tomcat 7.0.


Inline image 1


Images get removed by the mail list software. Please paste the text of 
the error you are seeing.


Mark

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

Tomcat 7.0: getting digester.Digester startElement error

[Saurav Maulick]

Hi Team,

After doing windows patch installation we are getting digester.Digester
startElement error. Can you please help on this? we are using Tomcat 7.0.

[image: Inline image 1]

Thanks
Rav

Re: TomcatCon Meetup (UPDATE)

[Huxing Zhang]

Hi All,

The pic for the meetup yesterday can be found here:

https://www.dropbox.com/s/vu02lnrs77up5mc/IMG_0591.JPG

On Wed, May 17, 2017 at 8:46 PM, Coty Sutherland  wrote:
> Sorry I had to run off, hopefully you guys had a productive meeting :)
>
> On May 17, 2017 7:02 PM, "Coty Sutherland"  wrote:
>
>> We're sitting next to the pool. The room is occupied :(
>>
>> On May 17, 2017 9:12 AM, "Christopher Schultz" <
>> ch...@christopherschultz.net> wrote:
>>
>>> All,
>>>
>>> Let's move the Meetup to "immediately following the Lightning Talks",
>>> since that is a popular event at the conference.
>>>
>>> -chris
>>>
>>> >
>>> > All,
>>> >
>>> > For those of you at ApacheCon in Miami, here are the details for the
>>> Tomcat Meetup. Come and meet fellow members of the community, committers,
>>> and new friends.
>>> >
>>> > Time: 18:00 EDT
>>> > Place: Escorial Conference Room (where all TomcatCon sessions are being
>>> held)
>>> >
>>> > All are welcome to the meetup, and also the inevitable dinner and
>>> drinks to follow.
>>> >
>>> > Thanks,
>>> > -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: TLS handshake performance

[Rainer Jung]

Am 18.05.2017 um 16:03 schrieb john.e.gr...@wellsfargo.com.INVALID:

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Thursday, May 18, 2017 8:47 AM
To: users@tomcat.apache.org
Subject: Re: TLS handshake performance

This time to the right list...

On 18/05/2017 06:04, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 5/17/17 5:31 PM, Mark Thomas wrote:

I got asked in the corridor at TomcatCon earlier today what the
relative performance of the TLS handshake was with 8.5.x, the NIO
connector and JSSE vs OpenSSL TLS implementation.

I'm curious about what exactly "TLS handshake" was intended to mean
(by the person who asked the question) in this context.


They are using Tomcat in a scenario where clients are making single requests
(so keep alve doesn't help). Given that the handshake uses asymmetric
encryption which is more expensive that symmetric encryption (which is why
the handshake is used to establish a shared secret so symmetric encryption
can used for the actual data) they wanted a sense of the performance
benefit - if any - of NIO and 8.5.x with OpenSSL vs NIO and 8.5.x with JSSE.


The handshake itself does not perform any bulk transfer of encrypted
data, so the negotiated cipher suite does not matter. However...


Tested with: ab -n 1000 -c 2 -f TLS1.2 -Z
ECDHE-RSA-AES128-GCM-SHA256 https://localhost:8443/test.txt


Here the cipher suite matters very much, since the client is not only
performing the TLS handshake but also transferring the client's
request to the server and the server's response back to the client. >
Support for a particular algorithm may dominate the benchmark, here.


Agreed. But it is the handshake that dominates the timings (if you add -k to
use keep-alive the req/sec are an order of magnitude higher).

The cipher suite was the default one chosen by by one of the configs (I
forget which).

The cipher suite will affect the results since it also impacts the enctrpyion
used during the handshake but for any 'reaosnably' secure cipher suite, I'd
expect similar results in terms of the relative performance.




What about SSL session reuse?  Did you have any way of disabling that?  If 
you're testing against a single server, you'll get 100% reuse, which makes a 
big difference in the CPU load (lower) on the server.  If your real world case 
involves dozens or hundreds of servers behind a load balancer, you get almost 
no reuse.


Session reuse does not work magically. The client and the server have to 
support it, being it using a session cache and IDs or using TLS session 
tickets.


I am pretty sure, that "ab", the client used during these tests, does 
not support TLS session reuse.


Regards,

Rainer

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

RE: Tomcat 8.5.4 and LegacyCookieProcessor

[Caldarale, Charles R]

> From: jared.paul.wal...@gmail.com [mailto:jared.paul.wal...@gmail.com] On 
> Behalf Of Jared Walker
> Subject: Tomcat 8.5.4 and LegacyCookieProcessor

> We are migrating to the version of tomcat identified in the subject

Before exposing an almost year-old version to the nasty real world, you might 
want to look at this:
http://tomcat.apache.org/security-8.html
and then pick a newer level (hint: 8.5.15 would be good).

> 1. What are the security and compatibility concerns when using the
> legacy processor

Sorry, can't answer that one.

> 2. The header for LegacyCookieProcesor.java explicitly states: "This
> class is not thread-safe."

> Can someone here with background knowledge explain exactly whats not
> thread-safe about the processor?  Does this mean you cannot use it for
> multiple simultaneous requests (pretty hindering for a server) or does
> this mean that you cannot have multiple threads parse the cookie
> contents of a request in parallel (which isn't a very normal thing to
> do)?

It's neither, really; there is one instance of CookieProcessor per , 
and the fields within LegacyCookieProcessor that make it not thread-safe are 
only set (in Tomcat) when the  is initialized.  Were you to 
dynamically reset the fields while requests were in progress, you could get in 
trouble.  The fields are described here:

http://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Tomcat 8.5.4 and LegacyCookieProcessor

[Jared Walker]

Hello,

We are migrating to the version of tomcat identified in the subject
and during our testing we ran into an issue with an external automated
client used to submit specialized requests to your web application.
It was failing to connect because it was submitting cookies with
version set to 0.

I have read through the documentation and found that configuring the
legacy processor does resolve this issue.

Now, I know this is only a work around as the "spec" being used by
this client is ancient.  We are considering using the legacy parser as
a stop-gap measure until we can update the external clients with a new
version.

My groups concern however is two fold:

1. What are the security and compatibility concerns when using the
legacy processor
2. The header for LegacyCookieProcesor.java explicitly states: "This
class is not thread-safe."

Can someone here with background knowledge explain exactly whats not
thread-safe about the processor?  Does this mean you cannot use it for
multiple simultaneous requests (pretty hindering for a server) or does
this mean that you cannot have multiple threads parse the cookie
contents of a request in parallel (which isn't a very normal thing to
do)?

Any advice would be appreciated.

Thanks,
-Jared

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

Re: Tomcat 8.5: wrong classloader used during context startup?

[Mark Thomas]

On 17/05/2017 14:32, Michael Heinen wrote:
I am currently migrating a web app from Tomcat 7.0.73 to 8.5.15. An 
embedded Tomcat is used on development systems.


The web-inf/lib folder of the application contains a jar with a 
SAXParserFactory implementation. This SAXParserFactory is now used with 
TC 8.5 by the WebXmlParser in order to parse the web.xml (and fails 
unfortunately). The ServiceLoader finds the jar because the 
ParallelWebappClassLoader is used for the lookup.


TC 7.0.73 uses the sun.misc.Launcher$AppClassLoader and does therefore 
not use the jar under web-inf\lib. It creates the webXml Digester in the 
init() phase of the stanrardContext. TC 8.5 does this in the 
startInternal() phase where the ParallelWebappClassLoader is 
instantiated and bound to the current thread.


Specifying "javax.xml.parsers.SAXParserFactory" as VM param solves the 
issue of course.


I think this is the fix that triggered this:
https://svn.apache.org/viewvc?view=revision=1731216


My question:
Is this behaviour expected?


It looks like an unintended side-effect of the change.

Should Tomcat use libraries of the web app for the startup of a context, 
here for web-xml parsing?


The change has been in place for over a year and this is the first 
problem we have seen. I'm curious, what exactly was the problem you saw?


I'd probably lean towards fixing this on the grounds that you want to 
parsing of web.xml to be deterministic rather than dependent on what 
may, or may not, be included in the app.


What do others think?

Mark

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

Re: Tomcat on macOS

[Israel Timoteo]

Thank Thad!


Any comments from the community for ...

1) What tools is the community using for simultaneous applications deployment 
on several servers, let’s say more than 20?

4) Is JAVA_OPTS required?






Israel Timoteo

> On May 18, 2017, at 6:53 AM, Thad Humphries  wrote:
> 
> On Wed, May 17, 2017 at 9:25 PM, Israel Timoteo  > wrote:
> 
>> Hi all,
>> 
>> My environment is Tomcat 8.5.12, Java 1.8.0_112 running on macOS 10.12 and
>> planning to update Tomcat to 8.5.15.
>> 
>> I’m wondering if I can get comments from the community for my questions
>> below?
>> 
>> 
>> 1) What tools is the community using for simultaneous applications
>> deployment on several servers, let’s say more than 20?
>> 
>> 2) Would having the logs located outside of the Tomcat home directory, if
>> possible, affect Tomcat operation?
>> 
>> 3) Are there any recommendations/best practices for installing and running
>> Tomcat 8.5.15 on macOS 10.12?
>> 
> 
> On #2 and #3, setup up separate CATALINA_HOME and CATALINA_BASE directories
> as described in RUNNING.txt. This will keep logs out of CATALINA_HOME and
> make upgrading to new releases of Tomcat fairly easy.
> 
> My Macs aren't production, so you may need to adapt this. I unpack Tomcat
> releases to /Library/Tomcat. I remove all but ./bin and ./lib, and rename
> ./conf to ./conf-ORIG. I diff this ./conf-ORIG with the ./conf-ORIG from
> the last release, making tweaks to my $CATALINA_BASE/conf files as
> required. Then I create a link
> 
>$ cd /Library/Tomcat
>$ tar zxvf ~/Downloads/apache-tomcat-8.5.11.tar.gz
> ... // remove subdirectories...
>$ rm catalina
>$ ln -s /Library/Tomcat/apache-tomcat-8.5.11 catalina
> 
> and in ~/.bash_profile `export CATALINA_HOME=/Library/Tomcat/catalina` (I
> also set CATALINA_HOME and CATALINA_BASE in my org.apache.tomcat plist).
> Now restart Tomcat.
> 
> 
>> 
>> 4) Is JAVA_OPTS required?
>> 
>> 
>> 
>> Thanks for your comments.
>> 
>> Israel
>> 
>> 
>> 
>> 
> 
> 
> -- 
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v. 121-24)

getting digester.Digester startElement error

[Saurav Maulick]

Hi Team,

After doing windows patch installation we are getting digester.Digester
startElement error. Can you please help on this? we are using Tomcat 7.0.

[image: Inline image 1]
-- 
Thanks and Regards,
Saurav Maulick

RE: TLS handshake performance

[John.E.Gregg]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Thursday, May 18, 2017 8:47 AM
> To: users@tomcat.apache.org
> Subject: Re: TLS handshake performance
> 
> This time to the right list...
> 
> On 18/05/2017 06:04, Christopher Schultz wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Mark,
> >
> > On 5/17/17 5:31 PM, Mark Thomas wrote:
> >> I got asked in the corridor at TomcatCon earlier today what the
> >> relative performance of the TLS handshake was with 8.5.x, the NIO
> >> connector and JSSE vs OpenSSL TLS implementation.
> > I'm curious about what exactly "TLS handshake" was intended to mean
> > (by the person who asked the question) in this context.
> 
> They are using Tomcat in a scenario where clients are making single requests
> (so keep alve doesn't help). Given that the handshake uses asymmetric
> encryption which is more expensive that symmetric encryption (which is why
> the handshake is used to establish a shared secret so symmetric encryption
> can used for the actual data) they wanted a sense of the performance
> benefit - if any - of NIO and 8.5.x with OpenSSL vs NIO and 8.5.x with JSSE.
> 
> > The handshake itself does not perform any bulk transfer of encrypted
> > data, so the negotiated cipher suite does not matter. However...
> >
> >> Tested with: ab -n 1000 -c 2 -f TLS1.2 -Z
> >> ECDHE-RSA-AES128-GCM-SHA256 https://localhost:8443/test.txt
> >
> > Here the cipher suite matters very much, since the client is not only
> > performing the TLS handshake but also transferring the client's
> > request to the server and the server's response back to the client. >
> > Support for a particular algorithm may dominate the benchmark, here.
> 
> Agreed. But it is the handshake that dominates the timings (if you add -k to
> use keep-alive the req/sec are an order of magnitude higher).
> 
> The cipher suite was the default one chosen by by one of the configs (I
> forget which).
> 
> The cipher suite will affect the results since it also impacts the enctrpyion
> used during the handshake but for any 'reaosnably' secure cipher suite, I'd
> expect similar results in terms of the relative performance.
> 


What about SSL session reuse?  Did you have any way of disabling that?  If 
you're testing against a single server, you'll get 100% reuse, which makes a 
big difference in the CPU load (lower) on the server.  If your real world case 
involves dozens or hundreds of servers behind a load balancer, you get almost 
no reuse.

Thanks

Re: TLS handshake performance

[Mark Thomas]

This time to the right list...

On 18/05/2017 06:04, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 5/17/17 5:31 PM, Mark Thomas wrote:

I got asked in the corridor at TomcatCon earlier today what the
relative performance of the TLS handshake was with 8.5.x, the NIO
connector and JSSE vs OpenSSL TLS implementation.

I'm curious about what exactly "TLS handshake" was intended to mean
(by the person who asked the question) in this context.


They are using Tomcat in a scenario where clients are making single 
requests (so keep alve doesn't help). Given that the handshake uses 
asymmetric encryption which is more expensive that symmetric encryption 
(which is why the handshake is used to establish a shared secret so 
symmetric encryption can used for the actual data) they wanted a sense 
of the performance benefit - if any - of NIO and 8.5.x with OpenSSL vs 
NIO and 8.5.x with JSSE.



The handshake itself does not perform any bulk transfer of encrypted
data, so the negotiated cipher suite does not matter. However...


Tested with: ab -n 1000 -c 2 -f TLS1.2 -Z
ECDHE-RSA-AES128-GCM-SHA256 https://localhost:8443/test.txt


Here the cipher suite matters very much, since the client is not only
performing the TLS handshake but also transferring the client's
request to the server and the server's response back to the client. >
Support for a particular algorithm may dominate the benchmark, here.


Agreed. But it is the handshake that dominates the timings (if you add 
-k to use keep-alive the req/sec are an order of magnitude higher).


The cipher suite was the default one chosen by by one of the configs (I 
forget which).


The cipher suite will affect the results since it also impacts the 
enctrpyion used during the handshake but for any 'reaosnably' secure 
cipher suite, I'd expect similar results in terms of the relative 
performance.



What happens if you negotiate a NULL cipher for instance? Or, perform
the TLS handshake but never make an HTTP request after connecting? I
don't know of a tool that can do that out of the box (e.g. ab makes
HTTP requests, not just TLS connections) but one could be written in
Java fairly easily.


test.txt is a 3 byte text file.

The results were: JSSE:17 reqs/sec OpenSSL: 23 reqs/sec

So around a 35% increase.


I'd like to see a NULL or very low-overhead cipher under the same
circumstances.


The test was with Tomcat trunk and the test keystore from the Tomcat PMC 
private repo so you should be able to set up those tests pretty quickly. 
(I did it in around 30 mins which incuded building tc-native).


Mark




YMMV with different versions of TLS and associated ciphers, JREs,
OpenSSl versions etc. >

Noted. ;)

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkdK1IACgkQHPApP6U8
pFhfQw/+NGm1CNQcFZ2qVzlCZ36W+TXhaKaBcWeiSCKw60jf/utEFycONRldm5Q3
cRM7Nbrfx1GcPwAs8ufedOtHgsAfzp6JkpzqwVFqZjUX1GODbJhz1vaNgQgB3mL8
YlGBoLqQIRKvQNOcTYJx5bP+tbnqARu96uINH16rMT+GQUF9nIzk+ua7ec0Goe+e
6yO6euDrkV75uOMPArBWDDToSrQVZ9QKiliqlcYpnG2IPDMu1CGWDHZtwO1pxaLG
aMbtqea9gAj42rw3NpFjUNxqYdN4EJHhCFjIIdVCAbiqs5BZQQAjcWjaRPniq45M
ySsuBLNFqPj2sltlhZrdg7CEklvDbVvVgVIWZA21pw0wyfIofZnsiy+KsLo8q/wD
gHcOF/TkQ4pAYGVoP+wh5AnQHwze2SFTJq0RE7kE0s6cohtfXeNSH/Ga6lzbJW5d
B+vHpU8+U6X1Lpha8Hg0A1KxbP7hcANfdLTiRqZNIVMQES8p6Zh+fbIX+DlVYIFR
WLFNmFADdlZ5msxHwRjfdQ8dtL6McwyvM3kmDQeADU/YzN80bhXmr8ZHJJUevTUJ
cya5zcw5MmPrzdlavXhH0VKspbprPoJxrd9llRU0ra5aNfUmJ4xA79jD5VxQmNL/
Cglw5DT8QoxG3knjZEQ8YLRj0gq0NrQXQmzowxqekfMcyNc2EGg=
=+yjT
-END PGP SIGNATURE-

-
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: Problem with get ROOT context in servlet on tomcat 8.0.30 (jdk 1.7.0_79)

[Mark Thomas]

On 15/05/2017 14:49, mwbxtr wrote:

I believe I am having an issue with getting the ROOT context from a different
app context. This was working in 8.0.14, but no longer works in 8.0.43.


This works for me with a clean build of 8.0.x.

You'll need to put together the simplest test case that demsontrates the 
problem starting from a clean install of the latest 8.0.x release.


Mark




Root context exists and (includes crossContext=true in conf/context.xml)

Within Context: /app1

public class CrossContextExample {

 private ServletContext app1Context;

 public someMethod() {
 ServletContext rootContext = this.app1Context.getContext("/");
 // rootContext == null :( Used to be the ServletContext of ROOT
 }
}

I think this came as a result of  this change

by markt?



--
View this message in context: 
http://tomcat.10.x6.nabble.com/Problem-with-get-ROOT-context-in-servlet-on-tomcat-8-0-30-jdk-1-7-0-79-tp509p5063440.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

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




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

RE: Can't get over 100 client connections?

[John.E.Gregg]

Hi Chris

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Thursday, May 18, 2017 12:06 AM
> To: users@tomcat.apache.org
> Subject: Re: Can't get over 100 client connections?
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> John,
> 
> On 5/16/17 1:57 PM, john.e.gr...@wellsfargo.com.INVALID wrote:
> > All,
> >
> > I'm using Tomcat 7.0.75.
> >
> > I cannot get my connection or thread count over 100 no matter how much
> > load I throw at the server.  Currently I just have a dummy app
> > deployed that doesn't do much except sleep for about 500ms and return
> > a canned response.  Initially I had maxThreads=20 with no explicit
> > maxConnections.  I could get the "current threads busy"
> > metric to 20 easily.  Then I raised it to 100 and was able to reach
> > that number easily.  Additionally, netstat told me I had 100 incoming
> > connections to port 5114.  However raising the maxThreads higher
> > doesn't make any difference, nor does explicitly specifying
> > maxConnections=200.  In either case, I can only get 100 busy threads
> > and 100 active connections.  Once I reach that limit, the response
> > times on the client start going up.  The Tomcat server itself isn't
> > stressed at all.  CPU and GC are low.  The client is on a different
> > server in the same data center.
> >
> > I'm not going through a load balancer.  I'm going directly to the
> > connector below:
> >
> >
> >  > maxConnections="200" maxThreads="200" maxKeepAliveRequests="100"
> > keepAliveTimeout="1" scheme="https" secure="true"
> > clientAuth="true" sslProtocol="TLS"
> > keystoreFile="/app/comp/myapp/certs/appcerttestkeystore"
> > keystorePass="${keystore.password}" keyAlias="test"
> > truststoreFile="/app/comp/myapp/certs/cacerts"
> > truststorePass="${truststore.password}"
> > allowUnsafeLegacyRenegotiation="false" ciphers="blah blah blah" />
> 
> What is the benchmark client and how do you invoke it?
> 
> - -chris

LoadRunner --> vendor app using Commons HttpClient 4.x --> my Tomcat server.  
Tomcat is running an app I wrote to stub out the backend because we're not 
allowed to run load tests against it.  I confirmed that Tomcat itself could 
handle more than 100 connections by running the vendor app under load, as well 
as a test from JMeter directly against my Tomcat server.  Worked fine.  It's 
the vendor app that appears to have hit a 100 connection limit.

Interestingly, JMeter with the option to use HttpClient 4.x opens and closes a 
lot of connections.  The exact same JMeter test with HttpClient 3.x selected 
reuses the connection the way I expect.

If you're on the HttpClient users list, you might see a question from me!  I 
don't understand why HttpClient is behaving the way it is.

Thanks

Re: TLS handshake performance

[Rémy Maucherat]

2017-05-17 23:31 GMT+02:00 Mark Thomas :

> Hi all,
>
> I got asked in the corridor at TomcatCon earlier today what the relative
> performance of the TLS handshake was with 8.5.x, the NIO connector and JSSE
> vs OpenSSL TLS implementation.
>
> This might be something that is of interest to a wider audience so here
> goes...
>
> The following results are very rough and ready and generated with my
> (slightly aging now) laptop (4 cores).
>
> I tested trunk but the code is close enough to 8.5.x for this purpose.
>
> I used exacty the same config for each test. The only change was to
> add/remove the tc-native library to enable/disable OpenSSL.
>
> Tested with:
> ab -n 1000 -c 2 -f TLS1.2 -Z ECDHE-RSA-AES128-GCM-SHA256
> https://localhost:8443/test.txt
>
> test.txt is a 3 byte text file.
>
> The results were:
> JSSE:17 reqs/sec
> OpenSSL: 23 reqs/sec
>
> So around a 35% increase.
>
> JRE: Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
> OpenSSL: 1.0.2k
>
> YMMV with different versions of TLS and associated ciphers, JREs, OpenSSl
> versions etc.
>
> I did another test run on my own since I had never tested handshake.
Platform: Fedora 25 with its default JVM
(openjdk-1.8.0.131-1.b12.fc25.x86_64), OpenSSL 1.0.2k, a Skylake 6700k CPU.

The results are in req/s:

ab -n 1 -c 20 -f TLS1.2 -Z ECDHE-RSA-AES128-GCM-SHA256
https://localhost:8443/tomcat.gif
NIO OpenSSL: 1900
NIO JSSE: 650
APR: 1900

+ -k (and also a bigger -n to make the test meaningful):
NIO OpenSSL: 53800
NIO JSSE: 24600
APR: 56900

My conclusion is also that the handshake is much faster with JSSE/OpenSSL
compared to vanilla JSSE, despite the code being complex and having a ton
of native calls. Testing localhost probably introduces a heavy bias as the
ab client also uses a lot of CPU, the real performance of vanilla JSSE on
my Fedora platform is actually worse than what it looks like. So on Fedora
25, it could be around 4 times slower for handshaking. The handshake seems
to be marginally slower with APR compared to JSSE/OpenSSL for some reason,
but then the encryption itself is faster. Undoubtedly the SSL engine adds a
bit of overhead to encryption.

Rémy

Re: Tomcat on macOS

[Thad Humphries]

On Wed, May 17, 2017 at 9:25 PM, Israel Timoteo  wrote:

> Hi all,
>
> My environment is Tomcat 8.5.12, Java 1.8.0_112 running on macOS 10.12 and
> planning to update Tomcat to 8.5.15.
>
> I’m wondering if I can get comments from the community for my questions
> below?
>
>
> 1) What tools is the community using for simultaneous applications
> deployment on several servers, let’s say more than 20?
>
> 2) Would having the logs located outside of the Tomcat home directory, if
> possible, affect Tomcat operation?
>
> 3) Are there any recommendations/best practices for installing and running
> Tomcat 8.5.15 on macOS 10.12?
>

On #2 and #3, setup up separate CATALINA_HOME and CATALINA_BASE directories
as described in RUNNING.txt. This will keep logs out of CATALINA_HOME and
make upgrading to new releases of Tomcat fairly easy.

My Macs aren't production, so you may need to adapt this. I unpack Tomcat
releases to /Library/Tomcat. I remove all but ./bin and ./lib, and rename
./conf to ./conf-ORIG. I diff this ./conf-ORIG with the ./conf-ORIG from
the last release, making tweaks to my $CATALINA_BASE/conf files as
required. Then I create a link

$ cd /Library/Tomcat
$ tar zxvf ~/Downloads/apache-tomcat-8.5.11.tar.gz
... // remove subdirectories...
$ rm catalina
$ ln -s /Library/Tomcat/apache-tomcat-8.5.11 catalina

and in ~/.bash_profile `export CATALINA_HOME=/Library/Tomcat/catalina` (I
also set CATALINA_HOME and CATALINA_BASE in my org.apache.tomcat plist).
Now restart Tomcat.


>
> 4) Is JAVA_OPTS required?
>
>
>
> Thanks for your comments.
>
> Israel
>
>
>
>


-- 
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v. 121-24)

Re: TLS handshake performance

[Rémy Maucherat]

2017-05-18 7:04 GMT+02:00 Christopher Schultz 
:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark,
>
> On 5/17/17 5:31 PM, Mark Thomas wrote:
> > I got asked in the corridor at TomcatCon earlier today what the
> > relative performance of the TLS handshake was with 8.5.x, the NIO
> > connector and JSSE vs OpenSSL TLS implementation.
> I'm curious about what exactly "TLS handshake" was intended to mean
> (by the person who asked the question) in this context.
>
> The handshake itself does not perform any bulk transfer of encrypted
> data, so the negotiated cipher suite does not matter. However...
>
> > Tested with: ab -n 1000 -c 2 -f TLS1.2 -Z
> > ECDHE-RSA-AES128-GCM-SHA256 https://localhost:8443/test.txt
>
> Here the cipher suite matters very much, since the client is not only
> performing the TLS handshake but also transferring the client's
> request to the server and the server's response back to the client.
>
> Support for a particular algorithm may dominate the benchmark, here.
>

I only tested JSSE/OpenSSL with -k, and the actual encryption is
ridiculously fast compared to the handshake. So Mark's test gives new data
and, IMO, is a good "handshake performance" test where you are supposed to
negotiate a usable cipher.

Rémy

>
> What happens if you negotiate a NULL cipher for instance? Or, perform
> the TLS handshake but never make an HTTP request after connecting? I
> don't know of a tool that can do that out of the box (e.g. ab makes
> HTTP requests, not just TLS connections) but one could be written in
> Java fairly easily.
>
> > test.txt is a 3 byte text file.
> >
> > The results were: JSSE:17 reqs/sec OpenSSL: 23 reqs/sec
> >
> > So around a 35% increase.
>
> I'd like to see a NULL or very low-overhead cipher under the same
> circumstances.
>
> > YMMV with different versions of TLS and associated ciphers, JREs,
> > OpenSSl versions etc.
>
> Noted. ;)
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkdK1IACgkQHPApP6U8
> pFhfQw/+NGm1CNQcFZ2qVzlCZ36W+TXhaKaBcWeiSCKw60jf/utEFycONRldm5Q3
> cRM7Nbrfx1GcPwAs8ufedOtHgsAfzp6JkpzqwVFqZjUX1GODbJhz1vaNgQgB3mL8
> YlGBoLqQIRKvQNOcTYJx5bP+tbnqARu96uINH16rMT+GQUF9nIzk+ua7ec0Goe+e
> 6yO6euDrkV75uOMPArBWDDToSrQVZ9QKiliqlcYpnG2IPDMu1CGWDHZtwO1pxaLG
> aMbtqea9gAj42rw3NpFjUNxqYdN4EJHhCFjIIdVCAbiqs5BZQQAjcWjaRPniq45M
> ySsuBLNFqPj2sltlhZrdg7CEklvDbVvVgVIWZA21pw0wyfIofZnsiy+KsLo8q/wD
> gHcOF/TkQ4pAYGVoP+wh5AnQHwze2SFTJq0RE7kE0s6cohtfXeNSH/Ga6lzbJW5d
> B+vHpU8+U6X1Lpha8Hg0A1KxbP7hcANfdLTiRqZNIVMQES8p6Zh+fbIX+DlVYIFR
> WLFNmFADdlZ5msxHwRjfdQ8dtL6McwyvM3kmDQeADU/YzN80bhXmr8ZHJJUevTUJ
> cya5zcw5MmPrzdlavXhH0VKspbprPoJxrd9llRU0ra5aNfUmJ4xA79jD5VxQmNL/
> Cglw5DT8QoxG3knjZEQ8YLRj0gq0NrQXQmzowxqekfMcyNc2EGg=
> =+yjT
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>