Re: Number of Web Applications in one Tomcat

[Igal Sapir]

Tarek,

On 10/29/2018 2:04 AM, Leon Rosenberg wrote:
Clearly one webapp per tomcat. Makes everything easier. Also, if your 
apps aren't really tiny, the memory overhead of tomcat is minimal 
compared to the advantages.


+1

On 10/29/2018 6:39 AM, Christopher Schultz wrote:

I usually deploy one webapp per JVM/tomcat instance. I do this so that
a problem in one webapp doesn't take-down the others. It's as simple
as that. The other benefits are being able to service that one JVM
without taking down N webapps -- just one, and also being able to run
under different JVMs, system libraries, etc. without having to test
each application for compatibility.


+1

Also, if you end up with a much larger heap because you put a bunch of 
applications together, then you can run into longer GC cycles (can 
happen even with concurrent garbage collectors).  When you have a Full 
GC, all of your applications' threads stop, and if it takes long enough, 
i.e. more than a fraction of a second, the lack of responsiveness of the 
applications will become noticeable.


The whole is greater than the sum of its parts, just that in this case 
"greater" is a bad thing.


Igal


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

Tomcat 9.0.10 embedded jars cause Bootstrap Glyphicons to not display

[zmacomber]

I'm testing my company's web application using the Tomcat 9.0.10 
embedded jars.  I'm running tests on my Ubuntu 18.04 development 
machine.


We have been successfully using the 8.5.x embedded jars in production.  
When we attempt to use the 9.0.x jars (in our specific case 9.0.10 but 
we have also seen this not work in other 9.0.x versions), Bootstrap 
Glyphicons do not show up correctly.  In Chrome's console, the following 
warnings show up:


Failed to decode downloaded font: 
http://localhost:9020/Infrared360/common/framework/bootstrap/fonts/glyphicons-halflings-regular.woff

OTS parsing error: incorrect file size in WOFF header
OTS parsing error: cmap: misaligned table

These warnings and the Bootstrap Glyphicons not displaying properly show 
up after I ONLY (in other words, NOTHING except...) switch out the 8.5 
embedded jars with the 9.0 jars.


What do I need to do to get the Bootstrap Glyphicons to display properly 
in Tomcat embedded 9.0.x?


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

Re: HTTP/2 SETTINGS Parameters and WINDOW_UPDATE : Tomcat:9.0.11

[Mark Thomas]

Sending a private email to an individual to try and elicit a response is 
not viewed as acceptable behaviour on this list.


Speaking personally, it will not cause me to answer a question any 
faster. At best, I'll answer when I'm ready. Catch me in a bad mood and 
I may choose not to answer at all.


If you want replies to questions provided in specific timescales, you'll 
need to find and pay for commercial support.


Given that Tomcat is open source, have you considered looking at the 
source code?

Hint: org.apache.coyote.http2

Mark


On 29/10/2018 12:36, S Abirami wrote:

Hi Mark,

Thanks for response .

Please confirm whether

Windows_Update has Window Size Increment (31) is configurable in Tomcat.
SETTINGS_MAX_FRAME_SIZE  : Whether this param is configurable in Tomcat and 
what is the default value.

Regards,
Abirami.S

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Monday, October 29, 2018 5:53 PM
To: users@tomcat.apache.org
Subject: Re: HTTP/2 SETTINGS Parameters and WINDOW_UPDATE : Tomcat:9.0.11

On 29/10/18 06:21, S Abirami wrote:

Hi Mark Thomas,

Thanks for response.

Need input on the below param

SETTINGS_MAX_FRAME_SIZE  :
  Windows_Update has Window Size Increment (31) ,please share the default value 
in Tomcat.


16k


Please confirm the below of my assumption for the Setting parameter
and Windows_Update is correct

SETTINGS_MAX_CONCURRENT_STREAMS   :  We can use  " maxConcurrentStreamExecution"


Correct.


SETTINGS_MAX_HEADER_LIST_SIZE  :  maxHeaderSize


Incorrect. Defaults to unlimited. Not configurable. Note that Tomcat will apply 
other limits, not related to the protocol including maxHeaderSize.


SETTINGS_INITIAL_WINDOW_SIZE   :  initialWindowSize


Correct.

Mark





Regards,
Abirami.S
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Saturday, October 27, 2018 11:24 PM
To: users@tomcat.apache.org
Subject: Re: HTTP/2 SETTINGS Parameters and WINDOW_UPDATE :
Tomcat:9.0.11

On 27/10/18 17:27, S Abirami wrote:

Hi All,

 I want your guidance how to set the below Setting Parameters and 
Wndows_Update using  Tomcat.
SETTINGS_HEADER_TABLE_SIZE,


Defaults to 4k. Not configurable.


SETTINGS_ENABLE_PUSH,


Defaults to true. Not configurable.


SETTINGS_INITIAL_WINDOW_SIZE


See http://tomcat.apache.org/tomcat-9.0-doc/config/http2.html


etc which is mentioned 6.5.2 section in RFC 7540

Similarly How to set the Windows_Update using Tomcat which is mentioned in the 
6.9 section in RFC 7540.


You don't. Tomcat handles that.

Mark

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


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




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


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



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

Re: Tomcat embedded with Apache Solr

[Woonsan Ko]

On Sat, Oct 27, 2018 at 1:29 AM Igal Sapir  wrote:
>
> Woonsan,
>
> On Fri, Oct 26, 2018 at 2:54 PM Woonsan Ko  wrote:
>
> > Not sure if it helps, but I've spent some hours to test it out for my
> > curiosity. Embedding tomcat v9 with an example servlet is simple
> > enough, but it's not working yet with fully initialized Solr:
> > - https://github.com/woonsan/solr-tomcat
> >
>
> I noticed that you extend Tomcat [1] in order to avoid initializing the
> default servlets.  You may have already seen that, but I wanted to point
> out that in the next version of Tomcat it can be done by passing false
> to setAddDefaultWebXmlToWebapp()
> [2].

That's a nice improvement. Thanks for the info. I added a TODO comment
above the line.

Best,

Woonsan

>
> Best,
>
> Igal
>
> [1]
> https://github.com/woonsan/solr-tomcat/blob/master/server/src/main/java/com/github/woonsan/solr/server/tomcat/launch/Main.java#L103
> [2] https://github.com/apache/tomcat/commit/0222ce9
>
>
>
>
> > I'm not there yet to understand the reasons and have fixes.
> > Let me know if you have any suggestions.
> >
> > Cheers,
> >
> > Woonsan
> >
> > On Fri, Oct 19, 2018 at 9:09 AM Shawn Heisey  wrote:
> > >
> > > On 10/18/2018 8:55 AM, Christopher Schultz wrote:
> > > > Actually, my goal was to convince the Solr team that switching from
> > > > Jetty to Tomcat was (a) possible and (b) possibly attractive.
> > >
> > > Over on lucene-dev, I had said that I removed jetty from solr's ivy
> > > config and found only two classes with errors in eclipse.
> > >
> > > Turns out this was because I hadn't removed jetty from the *lucene* ivy
> > > config, so most of the jetty jars were actually still referenced in the
> > > eclipse build path.
> > >
> > > When I remove jetty from ALL ivy configs, there are 335 compile errors,
> > > across many more classes.  Some of those are on the Lucene side, where I
> > > have less concern.  The part of Lucene that utilizes Jetty is not used
> > > in Solr.
> > >
> > > As I expected, a lot of the errors are in test code, but some of them
> > > are in code that's not for tests.
> > >
> > > If you really want to see us switch to Tomcat, we'll need help fixing
> > > those errors ... switching the code over to generic APIs (servlet and
> > > native Java) where possible, and to Tomcat where necessary.  I would not
> > > expect the Tomcat community to actually do the work -- just provide
> > > expert guidance.  Although if anyone was interested in volunteering, I
> > > wouldn't turn away the help!
> > >
> > > Thanks,
> > > Shawn
> > >
> > >
> > > -
> > > 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

[OT] Are we allowed to joke and ask when users@tomcat.apache.org will be bought for billions of dollars like GitHub or RedHat?

[Louis Zipes]

: )

---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may 
contain information that is confidential, proprietary or exempt from 
disclosure. If you are not the intended recipient, please contact the sender 
immediately. Unauthorized use or distribution is prohibited and may be unlawful.

Re: tomcat 8.5.29 AJP connector setup

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jose,

On 10/28/18 04:19, Jose Torres wrote:
> I hit enter too soon, but I want to know what other people use
> when configuring tomcat AJP connector, I provided an example of
> what I use. I am running following, tomcat 8.5.29 / apache 2.4.29 /
> mod_jk/1.2.41.
> 
> Thanks
> 
> On Sun, Oct 28, 2018 at 4:14 AM Jose Torres 
> wrote:
> 
>> Hello,
>> 
>> I am running with configuration below, I like to know what
>> parameters can be use with tomcat AJP for a H.A. configuration.
>> 
>> 
>> 
>> 
>>  > port="8009" protocol="AJP/1.3" redirectPort="443" 
>> maxThreads="4096" minSpareThreads="256" enableLookups="false"
>> acceptCount="100" connectionTimeout="2" />
>> 

Are you experiencing any particular problem, or are you just looking
for "general advice"?

Since you are using Tomcat 8.5 and not 6.0 or below, you probably want
to use an explicit  because you will have better control
over resource-allocations -- specifically, threads.

4096 threads is a lot of threads. Have you instrumented your
environment to see how many threads you are actually using?

If you really want "high availability" I might actually set the TCP
backlog (acceptcount) to zero. This will allow a reverse-proxy to send
traffic to a server which isn't full and clients will likely receive a
faster response.

Other than that, there really is no "configuration for H.A.". If there
were some other configuration that was better, Tomcat would ship with
it as the default.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvXEjgACgkQHPApP6U8
pFg/bhAAw/T9opaihXisKjh9cWP4GArjPL4kjmyBTvfe314YU8gxiOsMUX9fRLh2
zCZWwxHE20SNVJhi0rvoyHpUZWfnzc+FIYeF9gHzK4QFTQ3a/3KaltJo4g5jH4x8
wZ5dSWOIXSQXevZ55Z0+nhDEagOB9woLbExq+5IifPPMJxZZAl6HBMb9EEEvp9Mv
rHSc1jNsk4Biwz0CPaAhhbgE/KWxQezGheY8ZVL4JqU+bKKWoHk8gCadicasbCUE
9QV11cLm3LPanOOfn8J/5w0o2eq35GSrxzVLyVC34DF4mCnBiqAs9tJxmrO2d3uO
rln5+UMHtDZUwDd3mfIH9Qzczme7RS8U6slSiTOc0ikK0lSZO0aR851EtwDqzx1j
zaZWPO4ixLAx0M3vRUS0aYmTnjwvLEtYeCswrfTCbKUaijj3JtLYQZmnHTKkdLc0
JUWCCyrnfLFXkEvVepTPlAHS7hlLU2gbQ71yf8LWWXjI2v7eoEXo3dBy5JUGKfP9
zhR30iPpcPDG9yPlaCr6pL2Kz2FeJ7358u3YJRIbNX4RUey+p3lN/109abHphAgN
hMC5hEjr6arEt/jZm8IX3uAbK+FJ05tlxY22Of21c8BZcXjw8SZW64DDvbzwZFlN
QqJystr3dB8063q3fB993aM18j20yHVXu6wymsI0/1DPQTQ4fOU=
=f++s
-END PGP SIGNATURE-

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

Re: Number of Web Applications in one Tomcat

[Mark H. Wood]

On Mon, Oct 29, 2018 at 09:00:27AM +0100, Ahmed, Tarek wrote:
> TLDR? Do you deploy one web application per tomcat instance or several?

We have one production host with several related webapp.s in a single
Tomcat instance, and another production host with three instances of
that same single product (i.e. clumps of related webapp.s) in a single
Tomcat instance.  It works well.

In development I have at times as many as a dozen of those clumps
running in a single Tomcat, alongside various other applications also
in that single Tomcat.  It rarely causes trouble, and in development I
can always bounce it if I need to.

A couple of comments:

o  "loaded classes may not always be unloaded cleanly, threads not
   closed etc."  If I have this, it is either (a) an application bug,
   which I should fix, or (b) a buggy dependency, which I should
   report and complain about until fixed (or replaced).

o  An additional problem with multiple applications per container:
   ill-designed dependencies which are only configurable using system
   properties, when different applications need different
   configurations.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: Number of Web Applications in one Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Tarek,

On 10/29/18 04:00, Ahmed, Tarek wrote:
> Hi all,
> 
> TLDR? Do you deploy one web application per tomcat instance or
> several?

I usually deploy one webapp per JVM/tomcat instance. I do this so that
a problem in one webapp doesn't take-down the others. It's as simple
as that. The other benefits are being able to service that one JVM
without taking down N webapps -- just one, and also being able to run
under different JVMs, system libraries, etc. without having to test
each application for compatibility.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvXDYMACgkQHPApP6U8
pFgNgw/+O790RNVYpFtPKotyUT4ucPJbuVgYRcj/h+xcbw2REZurFzinXv82JSf7
A5m2zDYWLKFNi3x5Wu7rEWZvWc7xTCBz2E2BiwV9jfFX/Los8zuk3xo0xzHOJSFR
bNHnVLLws1Uj44dcsdYS4R6ZqZvJkgWTI9fnDlg0WbKW2zXscxgGO/+5887SrEB7
bgvwibe1tyBLosn+Sfx6O0Pab7w206OT8MHK+eFtXeE68bkfr1re4ykZV/DTTE4n
nEMCbysC7M2CCNElkQZNUe4MEIo9UWXkVnpj7zK3sVa9teawFWrZAx2uxGV/gsQX
PL+PqS6AAcQJh5Tesao/KjE83mjGGF0+CjuN1jl68g7U4rhCVPJSThsA11JxIcv4
jxJtPDbygK+11YBxaQZJY5QaeIvmnFQEaA5Svo/Em6HXOfqZHl9QJERdKQErMM5x
2O/8bwOIvYGShEOn2FwMYTMo1UPv9Yeek1BHXGtGdOhuw0/udVbFdCB6uh416uy3
xHfA2hJEXq/gnqJRWDjTj5lEEKAaXAkTm+FjaOW0VQMKKDNT3DKVs3vIpWfsSNnK
qlk4PFRgDZrp3A8OT+MX39lcMrSdvra9zU5lg1nALVrZDP7I2FTI55QNSqCzpo76
cCybiyWgy4urq5fokprewjHwrQzMiE1lKXS9RfrdVSVwYToyi1E=
=5z9/
-END PGP SIGNATURE-

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

Re: Question regarding CVE-2018-11784

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Yoli,

On 10/29/18 08:18, Mark Thomas wrote:
> On 29/10/18 11:29, Yoli Mana wrote:
>> Hi All,
>> 
>> Looking at the description of the below vulnerability. It is not
>> clear to me if this is only relevant to those who use Tomcat for
>> serving static files (since they are talking about directory
>> redirection). If our Tomcat instance is used only to serve
>> dynamic content, is the vulnerability is relevant to us?
> 
> If your application does not make use of Tomcat's default servlet
> then you will not be affected by this vulnerability. You would need
> to check the servlet mappings for the application to determine if
> Tomcat's default servlet would be used to respond to any requests.

... and it almost certainly would be used for that purpose at some
point. You should expect that your server is indeed vulnerable and you
should upgrade.

- -chris

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvXDLMACgkQHPApP6U8
pFjAgA/+L7hTuE5PLDS0fvntgrqe830DR4+J+I2avfRG5qF+SYGS6Hl436jlOnde
V+cwOzs5fapvbj4XpNsKtP5yUMV/MhVOFsgHUpn6qIvRHJEr0SW38VdAOX9yySFL
WEgYU3n3toIgAuXw02vuvxR+c6A3GxYeeXy3pEK9w4HVZYBDgoeXS0QnM0DMfJtN
V50t9ZdrQtqKLRd9NrQX4s6TWPDvdAggrLSdsBRPYYf7vF4wOyjH7c5qiO2+XsvJ
gAq/0WXiQ7lSyRATtTs/zqy/lXuiIu2JKddx9uenYTk4AgWk2uLGrMdjKg0W38RY
Loq1twuqF9Gmn9pOPoU0Q+UvPxim9RKoZ8RpSmLAfIH2vLChl0ET9+OlsquWyTQt
4AuphfE2W2+lO2N7rCDllytwxLcpuM1U+8ayld2KaDkkUcSI0NW2jV+h1x9ED9G5
MwsL2o/2H9+DuIGW7sZNpijRTUClWVdatAGUOt8BkMFDFKImhrlJQP1wZdBWcZaZ
v/dcFP089bEDOBxPprk+m2qyuwqRIJqzwuHLP4uPMPLnZD/G5RP4UGkUrVweVa8s
b1HXTkIY+c18nO0D/B+Pbe8F5V+AN8au2FV25sXd7uFa+OqnBIVUTYfVxkdoorLm
P4e99q2duTyW/ifm+PVEGMDAnOhVp726J7gZNSpWClbxnTX76rQ=
=hz4z
-END PGP SIGNATURE-

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

RE: HTTP/2 SETTINGS Parameters and WINDOW_UPDATE : Tomcat:9.0.11

[S Abirami]

Hi Mark,

Thanks for response .

Please confirm whether 

Windows_Update has Window Size Increment (31) is configurable in Tomcat.
SETTINGS_MAX_FRAME_SIZE  : Whether this param is configurable in Tomcat and 
what is the default value.

Regards,
Abirami.S

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Monday, October 29, 2018 5:53 PM
To: users@tomcat.apache.org
Subject: Re: HTTP/2 SETTINGS Parameters and WINDOW_UPDATE : Tomcat:9.0.11

On 29/10/18 06:21, S Abirami wrote:
> Hi Mark Thomas,
> 
> Thanks for response.
> 
> Need input on the below param
> 
> SETTINGS_MAX_FRAME_SIZE  :
>  Windows_Update has Window Size Increment (31) ,please share the default 
> value in Tomcat.

16k

> Please confirm the below of my assumption for the Setting parameter 
> and Windows_Update is correct
> 
> SETTINGS_MAX_CONCURRENT_STREAMS   :  We can use  " 
> maxConcurrentStreamExecution"

Correct.

> SETTINGS_MAX_HEADER_LIST_SIZE  :  maxHeaderSize

Incorrect. Defaults to unlimited. Not configurable. Note that Tomcat will apply 
other limits, not related to the protocol including maxHeaderSize.

> SETTINGS_INITIAL_WINDOW_SIZE   :  initialWindowSize

Correct.

Mark


> 
> 
> Regards,
> Abirami.S
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Saturday, October 27, 2018 11:24 PM
> To: users@tomcat.apache.org
> Subject: Re: HTTP/2 SETTINGS Parameters and WINDOW_UPDATE : 
> Tomcat:9.0.11
> 
> On 27/10/18 17:27, S Abirami wrote:
>> Hi All,
>>
>> I want your guidance how to set the below Setting Parameters and 
>> Wndows_Update using  Tomcat.
>> SETTINGS_HEADER_TABLE_SIZE,
> 
> Defaults to 4k. Not configurable.
> 
>> SETTINGS_ENABLE_PUSH,
> 
> Defaults to true. Not configurable.
> 
>> SETTINGS_INITIAL_WINDOW_SIZE
> 
> See http://tomcat.apache.org/tomcat-9.0-doc/config/http2.html
> 
>> etc which is mentioned 6.5.2 section in RFC 7540
>>
>> Similarly How to set the Windows_Update using Tomcat which is mentioned in 
>> the 6.9 section in RFC 7540.
> 
> You don't. Tomcat handles that.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: HTTP/2 SETTINGS Parameters and WINDOW_UPDATE : Tomcat:9.0.11

[Mark Thomas]

On 29/10/18 06:21, S Abirami wrote:
> Hi Mark Thomas,
> 
> Thanks for response.
> 
> Need input on the below param
> 
> SETTINGS_MAX_FRAME_SIZE  :
>  Windows_Update has Window Size Increment (31) ,please share the default 
> value in Tomcat.

16k

> Please confirm the below of my assumption for the Setting parameter and 
> Windows_Update is correct
> 
> SETTINGS_MAX_CONCURRENT_STREAMS   :  We can use  " 
> maxConcurrentStreamExecution"

Correct.

> SETTINGS_MAX_HEADER_LIST_SIZE  :  maxHeaderSize

Incorrect. Defaults to unlimited. Not configurable. Note that Tomcat
will apply other limits, not related to the protocol including
maxHeaderSize.

> SETTINGS_INITIAL_WINDOW_SIZE   :  initialWindowSize

Correct.

Mark


> 
> 
> Regards,
> Abirami.S
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Saturday, October 27, 2018 11:24 PM
> To: users@tomcat.apache.org
> Subject: Re: HTTP/2 SETTINGS Parameters and WINDOW_UPDATE : Tomcat:9.0.11
> 
> On 27/10/18 17:27, S Abirami wrote:
>> Hi All,
>>
>> I want your guidance how to set the below Setting Parameters and 
>> Wndows_Update using  Tomcat.
>> SETTINGS_HEADER_TABLE_SIZE,
> 
> Defaults to 4k. Not configurable.
> 
>> SETTINGS_ENABLE_PUSH,
> 
> Defaults to true. Not configurable.
> 
>> SETTINGS_INITIAL_WINDOW_SIZE
> 
> See http://tomcat.apache.org/tomcat-9.0-doc/config/http2.html
> 
>> etc which is mentioned 6.5.2 section in RFC 7540
>>
>> Similarly How to set the Windows_Update using Tomcat which is mentioned in 
>> the 6.9 section in RFC 7540.
> 
> You don't. Tomcat handles that.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: Question regarding CVE-2018-11784

[Mark Thomas]

On 29/10/18 11:29, Yoli Mana wrote:
> Hi All,
> 
> Looking at the description of the below vulnerability. It is not clear to
> me if this is only relevant to those who use Tomcat for serving static
> files (since they are talking about directory redirection).
> If our Tomcat instance is used only to serve dynamic content, is the
> vulnerability is relevant to us?

If your application does not make use of Tomcat's default servlet then
you will not be affected by this vulnerability. You would need to check
the servlet mappings for the application to determine if Tomcat's
default servlet would be used to respond to any requests.

Mark

> 
> Thanks,
> 
> When the default servlet in Apache Tomcat versions 9.0.0.M1 to 9.0.11,
> 8.5.0 to 8.5.33 and 7.0.23 to 7.0.90 returned a redirect to a directory
> (e.g. redirecting to '/foo/' when the user requested '/foo') a specially
> crafted URL could be used to cause the redirect to be generated to any URI
> of the attackers choice.
> 


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

Re: Number of Web Applications in one Tomcat

[Ahmed, Tarek]

sorry, didn't send this to the list, but to mark's address,
t.

Am 29.10.18 um 10:18 schrieb Mark Thomas:
> On 29/10/18 08:00, Ahmed, Tarek wrote:
>
>> DEV (one webapp per tomcat)
>>
>> - Start-up time of "fat tomcats" multiplies, which leads to worsened
>> availablity (e.g., our fattest tomcat contains 32 web services. It takes
>> 4 minutes to start)
> You can configure Tomcat to load applications in parallel to reduce this
> impact.
Thanks, Mark, this is a really valuable hint. I checked if there was
such a possibility several years ago but either I didn't find it or it
was before v. 7.023. I tried it out now and first tests show that a
speed-up of 200% is possible (have to tweak the optimal number of
threads yet). This is not a solution for a lot of my other issues but it
does  make living with fat tomcats easier.

tarek


-- 
Tarek Ahmed
Softwareentwicklung


DIMDI
Deutsches Institut für
Medizinische Dokumentation und Information
Waisenhausgasse 36-38a
50676 Köln

Tel.: +49 221 4724-268
Fax: +49 221 4724-444
tarek.ah...@dimdi.de 
www.dimdi.de 

tickDas DIMDI unterstützt die Vereinbarkeit von Beruf und Familie und
ist entsprechend zertifiziert.



Das DIMDI ist ein Institut im Geschäftsbereich des Bundesministeriums
für Gesundheit (BMG).

Question regarding CVE-2018-11784

[Yoli Mana]

Hi All,

Looking at the description of the below vulnerability. It is not clear to
me if this is only relevant to those who use Tomcat for serving static
files (since they are talking about directory redirection).
If our Tomcat instance is used only to serve dynamic content, is the
vulnerability is relevant to us?

Thanks,

When the default servlet in Apache Tomcat versions 9.0.0.M1 to 9.0.11,
8.5.0 to 8.5.33 and 7.0.23 to 7.0.90 returned a redirect to a directory
(e.g. redirecting to '/foo/' when the user requested '/foo') a specially
crafted URL could be used to cause the redirect to be generated to any URI
of the attackers choice.

Re: Number of Web Applications in one Tomcat

[Mark Thomas]

On 29/10/18 08:00, Ahmed, Tarek wrote:
> Hi all,
> 
> TLDR? Do you deploy one web application per tomcat instance or several?

No firm opinion one way or the other, just some commentary.

> ---
> 
> The long story:
> 
> I'd like to sound out your opinion regarding the number of web
> applications deployed in one tomcat instance. The reason is, that at my
> place of work the developers prefer one webapp per tomcat, the admins
> would rather have as many webapps as possible in one tomcat instance
> (yeah, that's devops at its finest ;-)  ). As a developer I'm probably
> prejudiced, but the argument goes as follows:
> 
> 
> OPS (one tomcat, many webapps):
> 
> - Saves memory (each tomcat has a memory footprint even without a web
> application running)

The Tomcat overhead is <20MB. Apps are typically a lot more. This
doesn't look like a strong argument to me.

> - Saves extra file systems for each tomcat (logs, tomcat installation,
> temp directory)

The resources in question are small in number and size. Again, this
doesn't look like a strong argument to me.

> - Saves nagios monitoring configuration

This is an interesting one. How well can the monitoring distinguish one
app from another. Given shared memory, shared thread-pools etc., per app
details could be tricky to determine.

> - Saves separate ports (security considerations)

I don't follow the argument here.

> - Saves work distributing security patches

A split CATALINA_HOME / CATALINA_BASE approach can help a lot with this
issue.
https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE


> DEV (one webapp per tomcat)
> 
> - Start-up time of "fat tomcats" multiplies, which leads to worsened
> availablity (e.g., our fattest tomcat contains 32 web services. It takes
> 4 minutes to start)

You can configure Tomcat to load applications in parallel to reduce this
impact.

> - If one webapp goes haywire, it may crash the rest of them (OOM, no
> more threads, etc.)

Fair point.

> - For bug fixes in one application, you may need to restart the complete
> tomcat instance. Auto (re)deploy takes you only so far, since loaded
> classes may not always be unloaded cleanly, threads not closed etc. This
> is not always something that can be solved in your own code, third party
> libraries may cause problems, too (we had some issues with quartz and
> infinispan here).

These issues usually are solvable but you need to know about them in
advance to code the necessary workarounds / protections.

> - If you ever need to profile your application in production, there is
> much less noise when analysing heap, thread dumps, cpu usage etc.

Fair point.

> - I might even think there is some improved security if webapps are
> isolated in several processes vs. being deployed in one VM (security
> arguments always work well with OPS :-)  )

Possibly. The strength of the security argument depends on the
circumstances. I suspect OPS can construct an equally strong security
based argument for single instances.

> So, I want to get away from the one-tomcat-multiple-webapps scenario.
> One thing I started doing to subvert this policy is using spring boot
> with embedded tomcats which is cool in a lot of ways but not always
> feasible.
> 
> What are your practices? Are there further pros and cons for one way or
> the other? Thanks so much for any input,

I've configured Tomcat instances both ways in the past depending on
circumstances. Generally, the more resources an app uses, the more
likely I am to have an app per instance the more business critical the
app is, the more likely I am to use a dedicated instance. Otherwise, I
tend to opt for a single instance for ease of management.

Mark

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

Re: Number of Web Applications in one Tomcat

[Olaf Kock]

On 29.10.18 09:00, Ahmed, Tarek wrote:


TLDR? Do you deploy one web application per tomcat instance or several?

As you list the arguments quite well, I'd add my answer "it depends": 
General rule of thumb, to be executed in that order: If they're too few 
applications to worry about (and if they're stable): Don't worry, One 
server.


If they're completely unrelated and have different stakeholders and/or 
maintenance intervals: That's a good argument for multiple servers


If there are unstable applications (in the sense of actively maintained, 
forcing frequent redeployments): Another good argument for multiple servers.


If there have been problems in the past with load/memory etc: Good 
argument for multiple servers.


This /might/ end up as one app per server, but the number one is not the 
end goal. There are typically some related apps, with the same 
maintenance intervals and stakeholders - unless one of them is 
problematic, I group them together.


I hope that helps.

Olaf


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

Re: Number of Web Applications in one Tomcat

[Leon Rosenberg]

Clearly one webapp per tomcat. Makes everything easier. Also, if your apps
aren't really tiny, the memory overhead of tomcat is minimal compared to
the advantages.

Leon

On Mon, Oct 29, 2018 at 9:00 AM Ahmed, Tarek  wrote:

> Hi all,
>
> TLDR? Do you deploy one web application per tomcat instance or several?
>
> ---
>
> The long story:
>
> I'd like to sound out your opinion regarding the number of web
> applications deployed in one tomcat instance. The reason is, that at my
> place of work the developers prefer one webapp per tomcat, the admins would
> rather have as many webapps as possible in one tomcat instance (yeah,
> that's devops at its finest ;-)  ). As a developer I'm probably prejudiced,
> but the argument goes as follows:
>
>
> OPS (one tomcat, many webapps):
>
> - Saves memory (each tomcat has a memory footprint even without a web
> application running)
>
> - Saves extra file systems for each tomcat (logs, tomcat installation,
> temp directory)
>
> - Saves nagios monitoring configuration
>
> - Saves separate ports (security considerations)
>
> - Saves work distributing security patches
>
>
> DEV (one webapp per tomcat)
>
> - Start-up time of "fat tomcats" multiplies, which leads to worsened
> availablity (e.g., our fattest tomcat contains 32 web services. It takes 4
> minutes to start)
>
> - If one webapp goes haywire, it may crash the rest of them (OOM, no more
> threads, etc.)
>
> - For bug fixes in one application, you may need to restart the complete
> tomcat instance. Auto (re)deploy takes you only so far, since loaded
> classes may not always be unloaded cleanly, threads not closed etc. This is
> not always something that can be solved in your own code, third party
> libraries may cause problems, too (we had some issues with quartz and
> infinispan here).
>
> - If you ever need to profile your application in production, there is
> much less noise when analysing heap, thread dumps, cpu usage etc.
>
> - I might even think there is some improved security if webapps are
> isolated in several processes vs. being deployed in one VM (security
> arguments always work well with OPS :-)  )
>
>
> So, I want to get away from the one-tomcat-multiple-webapps scenario. One
> thing I started doing to subvert this policy is using spring boot with
> embedded tomcats which is cool in a lot of ways but not always feasible.
>
> What are your practices? Are there further pros and cons for one way or
> the other? Thanks so much for any input,
>
> many greetings,
>
> tarek
>
> --
> Tarek Ahmed
> Softwareentwicklung
>
>
> DIMDI
> Deutsches Institut für
> Medizinische Dokumentation und Information
> Waisenhausgasse 36-38a
> 50676 Köln
>
> Tel.: +49 221 4724-268
> Fax: +49 221 4724-444
> tarek.ah...@dimdi.de
> www.dimdi.de
>
> [image: tick] Das DIMDI unterstützt die Vereinbarkeit von Beruf und
> Familie und ist entsprechend zertifiziert.
>
>
> Das DIMDI ist ein Institut im Geschäftsbereich des Bundesministeriums für
> Gesundheit (BMG).
>

RE: Number of Web Applications in one Tomcat

[PURVIS, Robert (NHS DIGITAL)]

We have had a single tomcat with multiple applications (10 or more) for many 
years (since 2002), and are now separating them. The main reason being that 
when one application crashes it can bring down the whole tomcat (e.g. oom 
errors).

Robert Purvis
robert.pur...@nhs.net



From: Ahmed, Tarek 
Sent: 29 October 2018 08:00
To: users@tomcat.apache.org
Subject: Number of Web Applications in one Tomcat


Hi all,

TLDR? Do you deploy one web application per tomcat instance or several?

---

The long story:

I'd like to sound out your opinion regarding the number of web applications 
deployed in one tomcat instance. The reason is, that at my place of work the 
developers prefer one webapp per tomcat, the admins would rather have as many 
webapps as possible in one tomcat instance (yeah, that's devops at its finest 
;-)  ). As a developer I'm probably prejudiced, but the argument goes as 
follows:



OPS (one tomcat, many webapps):

- Saves memory (each tomcat has a memory footprint even without a web 
application running)

- Saves extra file systems for each tomcat (logs, tomcat installation, temp 
directory)

- Saves nagios monitoring configuration

- Saves separate ports (security considerations)

- Saves work distributing security patches



DEV (one webapp per tomcat)

- Start-up time of "fat tomcats" multiplies, which leads to worsened 
availablity (e.g., our fattest tomcat contains 32 web services. It takes 4 
minutes to start)

- If one webapp goes haywire, it may crash the rest of them (OOM, no more 
threads, etc.)

- For bug fixes in one application, you may need to restart the complete tomcat 
instance. Auto (re)deploy takes you only so far, since loaded classes may not 
always be unloaded cleanly, threads not closed etc. This is not always 
something that can be solved in your own code, third party libraries may cause 
problems, too (we had some issues with quartz and infinispan here).

- If you ever need to profile your application in production, there is much 
less noise when analysing heap, thread dumps, cpu usage etc.

- I might even think there is some improved security if webapps are isolated in 
several processes vs. being deployed in one VM (security arguments always work 
well with OPS :-)  )



So, I want to get away from the one-tomcat-multiple-webapps scenario. One thing 
I started doing to subvert this policy is using spring boot with embedded 
tomcats which is cool in a lot of ways but not always feasible.

What are your practices? Are there further pros and cons for one way or the 
other? Thanks so much for any input,

many greetings,

tarek

--
Tarek Ahmed
Softwareentwicklung

DIMDI
Deutsches Institut für
Medizinische Dokumentation und Information
Waisenhausgasse 36-38a
50676 Köln

Tel.: +49 221 4724-268
Fax: +49 221 4724-444
tarek.ah...@dimdi.de
www.dimdi.de

[tick]

Das DIMDI unterstützt die Vereinbarkeit von Beruf und Familie und ist 
entsprechend zertifiziert.


Das DIMDI ist ein Institut im Geschäftsbereich des Bundesministeriums für 
Gesundheit (BMG).




This message may contain confidential information. If you are not the intended 
recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take 
any action in relation to its contents. To do so is strictly prohibited and may 
be unlawful. Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff 
in England and Scotland. NHSmail is approved for exchanging patient data and 
other sensitive information with NHSmail and other accredited email services.

For more information and to find out how you can switch, 
https://portal.nhs.net/help/joiningnhsmail

Number of Web Applications in one Tomcat

[Ahmed, Tarek]

Hi all,

TLDR? Do you deploy one web application per tomcat instance or several?

---

The long story:

I'd like to sound out your opinion regarding the number of web
applications deployed in one tomcat instance. The reason is, that at my
place of work the developers prefer one webapp per tomcat, the admins
would rather have as many webapps as possible in one tomcat instance
(yeah, that's devops at its finest ;-)  ). As a developer I'm probably
prejudiced, but the argument goes as follows:


OPS (one tomcat, many webapps):

- Saves memory (each tomcat has a memory footprint even without a web
application running)

- Saves extra file systems for each tomcat (logs, tomcat installation,
temp directory)

- Saves nagios monitoring configuration

- Saves separate ports (security considerations)

- Saves work distributing security patches


DEV (one webapp per tomcat)

- Start-up time of "fat tomcats" multiplies, which leads to worsened
availablity (e.g., our fattest tomcat contains 32 web services. It takes
4 minutes to start)

- If one webapp goes haywire, it may crash the rest of them (OOM, no
more threads, etc.)

- For bug fixes in one application, you may need to restart the complete
tomcat instance. Auto (re)deploy takes you only so far, since loaded
classes may not always be unloaded cleanly, threads not closed etc. This
is not always something that can be solved in your own code, third party
libraries may cause problems, too (we had some issues with quartz and
infinispan here).

- If you ever need to profile your application in production, there is
much less noise when analysing heap, thread dumps, cpu usage etc.

- I might even think there is some improved security if webapps are
isolated in several processes vs. being deployed in one VM (security
arguments always work well with OPS :-)  )


So, I want to get away from the one-tomcat-multiple-webapps scenario.
One thing I started doing to subvert this policy is using spring boot
with embedded tomcats which is cool in a lot of ways but not always
feasible.

What are your practices? Are there further pros and cons for one way or
the other? Thanks so much for any input,

many greetings,

tarek


-- 
Signatur
Tarek Ahmed
Softwareentwicklung


DIMDI
Deutsches Institut für
Medizinische Dokumentation und Information
Waisenhausgasse 36-38a
50676 Köln

Tel.: +49 221 4724-268
Fax: +49 221 4724-444
tarek.ah...@dimdi.de 
www.dimdi.de 

tickDas DIMDI unterstützt die Vereinbarkeit von Beruf und Familie und
ist entsprechend zertifiziert.



Das DIMDI ist ein Institut im Geschäftsbereich des Bundesministeriums
für Gesundheit (BMG).

RE: HTTP/2 SETTINGS Parameters and WINDOW_UPDATE : Tomcat:9.0.11

[S Abirami]

Hi Mark Thomas,

Thanks for response.

Need input on the below param

SETTINGS_MAX_FRAME_SIZE  :
 Windows_Update has Window Size Increment (31) ,please share the default value 
in Tomcat.

Please confirm the below of my assumption for the Setting parameter and 
Windows_Update is correct

SETTINGS_MAX_CONCURRENT_STREAMS   :  We can use  " maxConcurrentStreamExecution"
SETTINGS_MAX_HEADER_LIST_SIZE  :  maxHeaderSize
SETTINGS_INITIAL_WINDOW_SIZE   :  initialWindowSize


Regards,
Abirami.S
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Saturday, October 27, 2018 11:24 PM
To: users@tomcat.apache.org
Subject: Re: HTTP/2 SETTINGS Parameters and WINDOW_UPDATE : Tomcat:9.0.11

On 27/10/18 17:27, S Abirami wrote:
> Hi All,
> 
> I want your guidance how to set the below Setting Parameters and 
> Wndows_Update using  Tomcat.
> SETTINGS_HEADER_TABLE_SIZE,

Defaults to 4k. Not configurable.

> SETTINGS_ENABLE_PUSH,

Defaults to true. Not configurable.

> SETTINGS_INITIAL_WINDOW_SIZE

See http://tomcat.apache.org/tomcat-9.0-doc/config/http2.html

> etc which is mentioned 6.5.2 section in RFC 7540
> 
> Similarly How to set the Windows_Update using Tomcat which is mentioned in 
> the 6.9 section in RFC 7540.

You don't. Tomcat handles that.

Mark

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


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