Re: SameSite cookies shows as "Unset" but Header shows Correct Value

[M. Manna]

Just to confirm, we know that Chrome will block JSESSIONID it if sent over
unsecure connection and with SameSite=None. But we saw the
previously mentioned issue in Firefox.

Thanks,

On Wed, 11 Mar 2020 at 15:33, M. Manna  wrote:

> Hi All,
>
> Due to the recent issues with Chrome 80, we have had to make some changes
> for our context.xml to have SameSite attribute setup for CookieProcessor
>
> What we've noticed is that even though CookieProcessorBase captures and
> assigns the correct value (e.g. "None" or "Lax"), the Network tab of
> browsers (e.g. Firefox, Chrome) always shows SameSite as "Unset". But if
> you observe the response header, it's actually setting the correct value.
>
> The question is - Would this be expected? Or, do we have to fix something
> here for browsers?
>
> Regards,
> M. MAnna
>

SameSite cookies shows as "Unset" but Header shows Correct Value

[M. Manna]

Hi All,

Due to the recent issues with Chrome 80, we have had to make some changes
for our context.xml to have SameSite attribute setup for CookieProcessor

What we've noticed is that even though CookieProcessorBase captures and
assigns the correct value (e.g. "None" or "Lax"), the Network tab of
browsers (e.g. Firefox, Chrome) always shows SameSite as "Unset". But if
you observe the response header, it's actually setting the correct value.

The question is - Would this be expected? Or, do we have to fix something
here for browsers?

Regards,
M. MAnna

Re: Novice Tomcat Admin Question - Filtering log output

[M. Manna]

Hey Darryl,

On Fri, 21 Feb 2020 at 17:15, Darryl Philip Baker <
darryl.ba...@northwestern.edu> wrote:

> I have taken over the administration of several Tomcat instances. A number
> of these are load balanced using an F5 appliance.  The
> org.apache.catalina.values.AccessLogValve log file is filled with the F5
> polls to see if the application is alive. Under almost all circumstances
> these are useless, I would like to stop logging just these requests. What
> is the best way to stop these entries being written?  I’ve included a
> sample of the log entries.
>
> 10.0.171.163 - - [21/Feb/2020:09:04:11 -0600] "GET /MySite/isAlive.jsp "
> 200 112
> 10.0.171.162 - - [21/Feb/2020:09:04:16 -0600] "GET /MySite/isAlive.jsp "
> 200 112
> 10.0.171.163 - - [21/Feb/2020:09:04:16 -0600] "GET /MySite/isAlive.jsp "
> 200 112
> 10.0.171.162 - - [21/Feb/2020:09:04:21 -0600] "GET /MySite/isAlive.jsp "
> 200 112
> 10.0.171.163 - - [21/Feb/2020:09:04:21 -0600] "GET /MySite/isAlive.jsp "
> 200 112
> 10.0.171.162 - - [21/Feb/2020:09:04:26 -0600] "GET /MySite/isAlive.jsp "
> 200 112
>
> The entry for the log file in server.xml is
>  directory="logs"
>prefix="localhost_access_log" suffix=".txt"
>pattern="%h %l %u %t %r %s %b" />
>
>
> Darryl Baker
> Northwestern University
> darryl.ba...@northwestern.edu
>

 I may be mistaken, but It seems you are probably trying to make the
logging coarser. You can take a look at conf/logging.properties for your
tomcat instances to do the adjustments of log levels.

Regards,

>
>

Re: cloud cluster

[M. Manna]

We are also using redis based option.

On Sun, 16 Feb 2020 at 17:32, Jonathan S. Fisher  wrote:

> We're doing the second: sessions stored in a Redis cluster with
> sticky sessions. This topology is simple and it scales pretty easily until
> it doesn't anymore [couple thousand simultaneous users]. You'll need to
> judiciously use your debugger and unix tools to find bottlenecks, as
> they're often hidden deep within the stack and present themselves in
> non-obvious ways. Important caveat: See the discussion from earlier this
> week on the mailing list about session replication and user authentication
> with the redisson session manager.
>
> On Sun, Feb 16, 2020 at 9:06 AM Jonathan Yom-Tov <
> jonathan.yom...@sysaid.com>
> wrote:
>
> > hi,
> >
> > What kind of configuration do people usually use when deploying on a
> public
> > cloud (e.g. AWS)? An auto-scaling cluster with session replication? A
> > auto-scaling cluster with all sessions stored in an external cache?
> >
> > Jon.
> >
>
>
> --
> Jonathan | exabr...@gmail.com
> Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
> full.
> Engineers, of course, understand the glass is twice as big as it needs to
> be.
>

Re: Cross-session Persistent Object?

[M. Manna]

If database is the answer, you could use memcache/redis to do this too. It
should be able to support multiple servers if you need.

Since it’s only persistent based on tomcat, I was thinking at the servlet
context level only. Provided that database read overhead is acceptable,
it’s a more persistent solution.

Thanks,

On Tue, 11 Feb 2020 at 20:56, Rouse, Ed  wrote:

>
>
> From: Jerry Malcolm 
> Sent: Tuesday, February 11, 2020 3:12 PM
> To: users@tomcat.apache.org
> Subject: Cross-session Persistent Object?
>
> [External email: Use caution! Do not open attachments or click on links
> from unknown senders or unexpected emails.]
> I need some advice.  I need to maintain a set of long-running threads.
> When a request comes in, I need to determine if I have a thread started
> for a particular id found in the request.  So I need to have a hashmap
> of threads keyed by the ids.  That part is simple enough.  But I'm
> struggling with where to keep that hashmap object so that it is
> available to all incoming requests (any session).  This object should
> persistently remain as long as Tomcat is active.  It must be scoped to
> the virtual host and only needs to be available in one webapp context
> within that host. Suggestions on how to proceed will be greatly
> appreciated.
>
> Thx.
>
> Jerry
>
> I would set up a database table to store the values and create a
> class/script depending on your
> environment that would be able to do crud processes on the table. Maybe
> set it up as a web service
> if that would allow easier access for the individual webapps.
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org users-unsubscr...@tomcat.apache.org>
> For additional commands, e-mail: users-h...@tomcat.apache.org users-h...@tomcat.apache.org>
>

Re: Cross-session Persistent Object?

[M. Manna]

Jerry,


On Tue, 11 Feb 2020 at 20:12, Jerry Malcolm  wrote:

> I need some advice.  I need to maintain a set of long-running threads.
> When a request comes in, I need to determine if I have a thread started
> for a particular id found in the request.  So I need to have a hashmap
> of threads keyed by the ids.  That part is simple enough.  But I'm
> struggling with where to keep that hashmap object so that it is
> available to all incoming requests (any session).  This object should
> persistently remain as long as Tomcat is active.  It must be scoped to
> the virtual host and only needs to be available in one webapp context
> within that host. Suggestions on how to proceed will be greatly
> appreciated.
>
> Thx.
>
> Jerry
>
>  Would setting your hashmap as attribute to the Servlet context work?

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

Re: Tomcat 8.5.51/52 release time

[M. Manna]

Brilliant!.. Thanks Mark, helps a lot :)

On Tue, 11 Feb 2020 at 15:51, Mark Thomas  wrote:

> On 11/02/2020 15:44, M. Manna wrote:
> > Hello,
> >
> > Do we have any tentative timeline for next 8.5.x release ?
>
> The release vote for 8.5.51 passed earlier today. The formal
> announcement is expected tomorrow once the release has made it to most
> of the mirrors.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Tomcat 8.5.51/52 release time

[M. Manna]

Hello,

Do we have any tentative timeline for next 8.5.x release ?

Regards,

Question on HttpSession investigation

[M. Manna]

Hello,

I apologise in advance if the answer is obvious for this question. We are
trying to investigate (in an isolated cluster) whether our session
attributes are getting lost somewhere in the process.

The issue is that we are setting it at a JSP Tag Level, however, when we do
an AJAX request back to the same server, the session doesn't have the
attribute set by the tag. Since it's two different servers, we would like
to check using JMX whether this is present somewhere in session. Debugging
has not resulted into a successful outcome.

We appreciate if this is not possible, but just wanted to check if tomcat
currently emits anything related to this.

Regards,

Re: Class loader takes long time after server inactivity - Tomcat Version 9.0.10

[M. Manna]

Hey Niall,

On Tue, 14 Jan 2020 at 13:42, Niall Fitzpatrick 
wrote:

> Hi Folks,
>
>
>
> I have a web application that, after a period of inactivity (1-2hours),
> will stall for 3 – 35 seconds upon the first new session. All subsequent
> sessions will not experience this delay unless another period of inactivity
> occurs.
>
>
>
> I’ve found that the delay occurs when loading jars that live in the
> WEB-INF/lib folder.
>
>
>
> The issue doesn’t occur when the server is first started. Only after a
> period of 1-2 hours approx. will the next session experience the delay when
> loading a jar. This leads me to believe that when the server is started
> ‘knowledge’ of the jars might be cached, however, after a period of
> inactivity this cache may expire. The result of this is that the next
> session after this period causes the lib folder to be searched again which
> seems to take the 5-35 seconds.
>
>
>
> My question: Is this theory above correct, and if so, is there a way to
> configure Tomcat such that this cache doesn’t expire so that it doesn’t
> need to be re-populated when a new session begins?
>
>
>
> Tomcat Version 9.0.10
>
>
>
> Any help appreciated,
>
> Thanks,
>
> Niall
>

 Perhaps others can also correct me if i have missed - Tomcat does have a
resource caching and memory settings aka Resources:

https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html

That said, there is very small possibility (also partly coincidence) that
this is impacted by garbage collection cycles. We have got a production
scenario where garbage collection interfered with busy hour processing due
to having lower memory. But again, that's my own issue.
I think the link above may help you configure some things?

Regards,

Re: Possible release of next 8.5.x in 2020

[M. Manna]

Hey Mark,

On Mon, 13 Jan 2020 at 09:34, Mark Thomas  wrote:

> On 12/01/2020 21:03, M. Manna wrote:
>
> 
>
> > With regards to my enquiry, I’m simply trying to find out whether there
> > would be a new release coming out this January 2020.
>
> I am currently aiming to make 9.0.x and 8.5.x releases (and possibly
> 10.0.0.Mx depending how things go) early in February.


 Thanks a bunch. We will keep an eye out.

Regards,

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

Re: Possible release of next 8.5.x in 2020

[M. Manna]

He Michael,

On Sun, 12 Jan 2020 at 20:55, Michael Osipov  wrote:

> Am 2020-01-12 um 19:26 schrieb M. Manna:
> > Hey All,
> >
> > Just trying to get a timeline (or possible release time) for next 8.5.x.
> > The latest release is 8.5.50 from December 2020. I am assuming there is
> one
> > imminent for January 2020?
> >
> > This is purely for individual interest as my dev cycle requires a tomcat
> > upgrade 4 times a year.
>
> This might be wrong because you could miss important releases with
> security fixes or else.


 We operate under strict SLAs and every tomcat upgrade requires a full
regression cycle for our product due to the nature of integration. And we
only have 4 such slots per year to do it. Also, not all CVEs are relevant
to what/how we use tomcat.

With regards to my enquiry, I’m simply trying to find out whether there
would be a new release coming out this January 2020.

>
>

Possible release of next 8.5.x in 2020

[M. Manna]

Hey All,

Just trying to get a timeline (or possible release time) for next 8.5.x.
The latest release is 8.5.50 from December 2020. I am assuming there is one
imminent for January 2020?

This is purely for individual interest as my dev cycle requires a tomcat
upgrade 4 times a year.

Regards,
M. MAnna

Re: HTTP/2 configuration

[M. Manna]

Hey Mark et. al.,

On Tue, 7 Jan 2020 at 11:20, Mark Thomas  wrote:

> On 12/12/2019 15:23, Christopher Schultz wrote:
> > Arief,
> >
> > On 12/12/19 00:25, Arief Hasani wrote:
> >> IMHO, being able to override form HTTP1.1 conf is all good as user
> >> could easily assume that if not specified in the upgrade than use
> >> http1.1 configs
> > I'm not sure you understand the question.
> >
> > Mark is asking if any users in the community are finding that they
> > need to independently configure specific parts of the HTTP/<2 versus
> > h2 *for the same port*.
> >
> > Thinks like the compression, keepalives, max headers/trailers,
> > timeouts, sendfile config, etc.
> >
> > Does it ever make sense to have sendFile enabled on the HTTP/1.1
> > connector but disable sendFile if the client upgrades to h2?
>
> Exactly.
>
> > The suspicion is that identical configuration is acceptable. Mark is
> > trying to ask if there are any exceptions before we simplify the code
> > which handles the configuration.
> >
> > If you have a specific use-case, please explain.
>
> Just pinging this thread in case there is someone with a specific use case.
>
> At the moment, I'm leaning towards the simplification for Tomcat 10
> onwards.
>

 It's probably better that way. The change here is big and a major release
such as 10.x is more appropriate for GA.


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

Re: Tomcat 9 does not allow to read file in /tmp folder with 777 permission?

[M. Manna]

Hi,

On Sat, 4 Jan 2020 at 14:36, bphamhuu  wrote:

> Hello,
>
> I have a java web application by Tomcat 9 servlet container which tries to
> read a file in /tmp folder with 777 permission on Ubuntu 18.04
>
> ls -ltr /tmp/test.txt
> -rwxrwxrwx 1 vagrant vagrant 10 Jan  3 17:03 /tmp/test.txt
>
> The java code is:
>
> try {
> result = FileUtils.readFileToString(new File("/tmp/test.txt"));
> } catch (IOException ex) {
> log.info("# Cannot read file. Reason: " + ex.getMessage());
> }
>
> But it always show the error
>
> # Cannot read file. Reason: File '/tmp/test.txt' does not exist
>
> This test file can be opened fine by a normal user on a terminal window
> (example user: vagrant).
>
> vagrant@ras:~$ cat /tmp/test.txt
> asdasdsad
>
> Does anybody know about the problem with Tomcat 9? I'll need the java web
> application to read this test file as string.
>
> Thanks,
>
>
>   What is the full stack trace?

>
> --
> Sent from: http://tomcat.10.x6.nabble.com/Tomcat-User-f1968778.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Hide a request header to application

[M. Manna]

Oliver,

On Mon, 16 Dec 2019 at 11:09, Olivier Jaquemet 
wrote:

> Hello all,
>
> I would like to systematically hide a request header to web applications
> hosted by Tomcat.
>
>   "Blanking" or "Unsetting" a header is not the same as "Hiding". By
hiding, you are essentially asking for the Header to be available under
certain elevated privilege or conditions. Unless, you meant Unsetting the
value or removing the header (not "Hiding")?

> - If Apache HTTPD is used in front of Tomcat, you can use the
> RequestHeader directive [0]:
> RequestHeader unset Some-Header-Name
>
> - If NGINX is used in front of Tomcat, you can use the proxy_set_header
> directive [1]:
> proxy_set_header Some-Header-Name "";
>
> - Is there any way to apply a similar configuration (no development [2])
> to Apache Tomcat when there is no front server ?
> I could not find any built-in valve/filter that would allow such
> filtering. I don't think there is any, but I wanted to make sure I had
> not missed something.
>
>  Not to my knowledge. But I don't see why you cannot implement your own
Valve. Of course, any suggestion is welcome unless someone else has any
other suggestions?



> Olivier
>
> [0]
> https://httpd.apache.org/docs/current/mod/mod_headers.html#requestheader
> [1]
> http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header
> [2] I know it is possible to develop a quite simple custom ServletFilter
> to wrap the request with a custom HttpServletRequest wrapper, but I'm
> looking for a zero development possibility. For those of your reading
> this discussion later and looking for a development solution, you can
> find inspiration in the following github repo that you can adapt to
> handle removal
> https://github.com/lonelyplanet/tomcat-request-header-filter
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: HTTP/2 configuration

[M. Manna]

Mark,

On Wed, 11 Dec 2019 at 11:48, Mark Thomas  wrote:

> All,
>
> The Tomcat committers are looking for some user feedback.
>
> Currently, the HTTP/2 protocol configuration [1] duplicates many
> attributes of the HTTP/1.1 protocol [2] it is nested under.
>
> We are considering simplifying this for Tomcat 10 onwards and having the
> HTTP/2 protocol simply inherit the settings from HTTP/1.1. Optionally,
> we could have HTTP/2 inherit from HTTP/1.1 by default but allow an
> HTTP/2 specific override if required. However, this adds quite a few
> edge cases and I can't think of a use case where, for example, you'd
> want to have different maxHeaderCount settings on HTTP/1.1 and HTTP/2.
>
>  Inheritance seems to be an easier choice. Would this mean various
connectors
might then be using a "Factory"-like (insted of specific Http11*Protocol)
to refer to the correct underlying protocol?

> So, users, what do you think?
>
> Mark
>
>
>
> [1] http://tomcat.apache.org/tomcat-9.0-doc/config/http2.html
> [2] http://tomcat.apache.org/tomcat-9.0-doc/config/http.html
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Design Patterns in Tomcat

[M. Manna]

Chris,

On Mon, 9 Dec 2019 at 17:10, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> M,
>
> On 12/8/19 17:10, M. Manna wrote:
> > Hi All,
> >
> > A numpty question as its best, but I was trying to summarise the
> > design patterns used for tomcat. So far I could see the following,
> > but shouldn't be limited to:
> >
> > 1) Mediator 2) Observer 3) Factory 4) Builder 4) Adapter
> >
> > Perhaps I missed any confluence link or something that confirms
> > it?
>
> Don't forget iterator, interceptor, etc.
>
> We don't bother to track which design patterns are in use in Tomcat.
> Some of them are obvious due to their class names or behavior, but
> there is no documentation about what is being used where.
>
> There is also the problem of having a very large number of named
> design patterns, many of which are variations on a theme. You may see
> code that looks like publish/subscribe and others may call that
> observer/observable, etc. Some patterns are so obvious as to not
> require naming at all (e.g. "State").
>
> If you'd like to hunt through the code and find examples of carious
> patterns and document them -- e.g. in the Wiki -- that would be fine,
> but I don't think any committer is currently interested in such a task.

i guess it’s more or less what I was sexpecting. Let me work on the page
and perhaps I wi also provide 1/2 examples to support it. As long as folks
keep it correct, it should be a good source.

Thanks,

>
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3uf/oACgkQHPApP6U8
> pFgieQ/+LSNxlzLoM8XBtE/sNQlM+HXokdAAenakQb7jGHzKYGo7ElBL3+o0FORg
> /4HRQYO7sO9PkWDmBY8oAlxlXPdCwx6KSkK2ZFMi8kW4cOabqLXl0l7KpOI2TGNK
> u7aq7jJxN8k/OmcBdlIutYpKScB//kp9wDei6G2lEGdoQh2qMMgsWN7q9J9IGAO2
> CTB3JMVTy2LQGbXSPBGhNgRhpL4DykoHqpLCflsA9rhPGFVnN+cnCsFmiI3XREHD
> N/ap5ffXA2yOeOIuR5vhBolQJ2/3bGOQdIUrliGXMEv2hefslP+fQYudOAYzapju
> MO5VBVwOhtL0cZlVdOAgMJRL4V/Y91rSIXIS1gw/RKGV5cdEl+6VoyQhEVmRQa6u
> gHQ2HWrT+MyAV72YBulalPJy3c1vlr3Lna5kJFsxWB9rwdGZLv2xWIrWmINecdI1
> GAadRCzI0QOPA1leoq0ZdjtLvuk3W0m9+98V/uy9nrz6eyZ2hm2dFoTRvM2bbLda
> +aSwQssfaiq3QyoOxOmpeb3tWzQMXHeeoq6u5tnCwktNXUV78ZE4q6IiU9wcW8/L
> Z1/0VwhEWTF/cP8MSnqhMquEYoFVnFv2HBRE8eYIshKw2KrnlIzjYwGHCYqjRTNK
> DNSYvvuzf7s5pdzG7EtrrvOVNW7mH5Qtvs2hx1C55BijJRf3Rx0=
> =aczA
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Design Patterns in Tomcat

[M. Manna]

Hi All,

A numpty question as its best, but I was trying to summarise the design
patterns used for tomcat. So far I could see the following, but shouldn't
be limited to:

1) Mediator
2) Observer
3) Factory
4) Builder
4) Adapter

Perhaps I missed any confluence link or something that confirms it?

Thanks,

Re: Unknown protocol: e on Windows

[M. Manna]

Chris,

On Wed, 4 Dec 2019 at 18:34, Konstantin Kolinko 
wrote:

> ср, 4 дек. 2019 г. в 20:28, Christopher Schultz <
> ch...@christopherschultz.net>:
> >
> > All,
> >
> > I feel like I should be able to figure this out on my own, but I'm
> > drawing a blank.
> >
> > I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat
> > 8.5.35 and I'm getting errors on a certain portion of the
> > conf/server.xml configuration.
> >
> > I copy have a perfect copy/paste of the config file here but basically
> > this is configuring a keystore for TLS. Something like this:
> >
> >  > keystoreFile="E:\path\to\keystore.jks"
> > [...]
> > />
> >
> > The error is "unknown protocol: e". Clearly, Tomcat/Java/URL/whatever
> > thinks that "E:" is a protocol. No problem... this has to be a file
> > URL, so let's make it a file URL: [...]
>
> Chris,
>
> 1) Do know where that message is produced? (Stacktrace? What version of
> Tomcat?)
>
> E.g. it may be that the code has several attempts to use the value a)
> as file path, b) as URL,  and you only see the message from the second
> attempt b), but it is a) that fails.
>
> Is your keystoreFile path correct?
>
> 2) Why the settings are specified on a . They will be
> translated into / on the fly, but maybe
> something is broken.
>
>
> http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_Certificate
> It says that certificateKeystoreFile can be an URI.
>
> 3) Does you connector use JSSE or OpenSSL?
>
> There is some code that translates between the two configuration
> flavors on the fly, but maybe something is broken.
>
> > I'm using Oracle Java 1.8.0 build 161.
>
> FYI, an up-to-date version of Java 8 for Windows is available from
> AdoptOpenJDK.
> https://adoptopenjdk.net/
>
> It is 8u232 now.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
I have just launched tomcat 8.5.47 stockpile with the following connector
config (i generated keystore Jeeks before)



And my tomcat cert gen command was:

>keytool -genkeypair -alias tomcat -keyalg RSA -keystore tomcat.jks
-keypass changeit -storepass changeit

It only gave me warning about non-legit cert when I hit
https://localhost:8443 but that's expected. Otherwise, no errors.

I suspect your E:\ drive is a network drive (or virtual) so the mapping may
be causing issues ? Or may be it's the partitioning...?

Re: Unknown protocol: e on Windows

[M. Manna]

Also, with Windows \\ escape often has the tricks.

On Wed, 4 Dec 2019 at 17:43, M. Manna  wrote:

> Chris,
>
> On Wed, 4 Dec 2019 at 17:38, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> All,
>>
>> I should note that I'm using Oracle Java 1.8.0 build 161.
>>
>> I have seen another environment with essentially the same
>> configuration that seems to work. The path is
>> "E:\path\to\keystore.jks" and there are no errors.
>>
>> Thanks,
>> - -chris
>>
>> On 12/4/19 12:27, Christopher Schultz wrote:
>> > All,
>> >
>> > I feel like I should be able to figure this out on my own, but I'm
>> > drawing a blank.
>> >
>> > I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat
>> > 8.5.35 and I'm getting errors on a certain portion of the
>> > conf/server.xml configuration.
>> >
>> > I copy have a perfect copy/paste of the config file here but
>> > basically this is configuring a keystore for TLS. Something like
>> > this:
>> >
>> > 
>> >
>> > The error is "unknown protocol: e". Clearly,
>> > Tomcat/Java/URL/whatever thinks that "E:" is a protocol. No
>> > problem... this has to be a file URL, so let's make it a file URL:
>> >
>> > > > [...] />
>> >
>> > Same error.
>> >
>> > What if I remove the drive letter?
>> >
>> > > > />
>> >
>> > Same error (including the "e"!).
>> >
>> > Okay, maybe e:/ looks like a protocol. How about using
>> > backslashes?
>> >
>> > > > [...] />
>> >
>> > "Illegal character in path" :(
>> >
>> > What's the right way to write a Windows path containing a drive
>> > letter?
>> >
>> > -chris
>> >
>> -BEGIN PGP SIGNATURE-
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>>
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3n7xcACgkQHPApP6U8
>> pFiz3Q/+L85HlQ1s6O+Wz0kmrp3FhsuTQNizoAnEQL7lvXd+AGi2sAIagRyTfme1
>> 9MsWYBLYk0pTnOS+1mAnSt6FNNRKjdoJ0ud/rCXblqIwWX3j3nS1jifx92mQDQWt
>> bHISBL9wORBxaS+ENE1kicSBsVAJvEBA8gAY9p5kYncL9K1tK54XoklujTIHxrfU
>> g0NdprFv1LYZxxQyWmoP5zHSfvBsR2pjLpLSn3G2q32+gALgfu5hAWuJIUq5z4XZ
>> 65sfVEtfV9lntohTNqWqu5tdrg0TyblXMruNMB9ygW2DAbHO93Sjkpj2t/AieQwv
>> GtvJd1XC7shERazFtplE6o5UZaOrg+N/B2BALvqVoVMR+tAGNrbQqZZjDz+zPzGA
>> cL3xNcKN5OqPMFbnge8Ar1v87ywcmvO3arj1lvE6kt97VNeSAOFj7+9i2VWEqu0K
>> HDrLv4Ca2ESu3k/MO/eerC5os2dEoVXQEejyBrMtHPDaD40VxJIrYbRmbS/dqk5F
>> fjSmcWIopl3+z8/6lex2JGNc26liyvseIrnUtCP8CUklDMilS2XOGVvypDmZNEH1
>> rce8IBV3LrRqO/VJ18/VWsc6u6qp9QB6bD8Qvo/dpvX3uIeb4QDDz/9W1UDibG37
>> 0ZBqHkjty8C5wHxf5ep06lSdLbiH2NdY1LXKkz5Ru9cXElifVaE=
>> =gJWI
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>> Have you tried E:/path/to/cert.jks ?
>

Re: Unknown protocol: e on Windows

[M. Manna]

Chris,

On Wed, 4 Dec 2019 at 17:38, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I should note that I'm using Oracle Java 1.8.0 build 161.
>
> I have seen another environment with essentially the same
> configuration that seems to work. The path is
> "E:\path\to\keystore.jks" and there are no errors.
>
> Thanks,
> - -chris
>
> On 12/4/19 12:27, Christopher Schultz wrote:
> > All,
> >
> > I feel like I should be able to figure this out on my own, but I'm
> > drawing a blank.
> >
> > I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat
> > 8.5.35 and I'm getting errors on a certain portion of the
> > conf/server.xml configuration.
> >
> > I copy have a perfect copy/paste of the config file here but
> > basically this is configuring a keystore for TLS. Something like
> > this:
> >
> > 
> >
> > The error is "unknown protocol: e". Clearly,
> > Tomcat/Java/URL/whatever thinks that "E:" is a protocol. No
> > problem... this has to be a file URL, so let's make it a file URL:
> >
> >  > [...] />
> >
> > Same error.
> >
> > What if I remove the drive letter?
> >
> >  > />
> >
> > Same error (including the "e"!).
> >
> > Okay, maybe e:/ looks like a protocol. How about using
> > backslashes?
> >
> >  > [...] />
> >
> > "Illegal character in path" :(
> >
> > What's the right way to write a Windows path containing a drive
> > letter?
> >
> > -chris
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3n7xcACgkQHPApP6U8
> pFiz3Q/+L85HlQ1s6O+Wz0kmrp3FhsuTQNizoAnEQL7lvXd+AGi2sAIagRyTfme1
> 9MsWYBLYk0pTnOS+1mAnSt6FNNRKjdoJ0ud/rCXblqIwWX3j3nS1jifx92mQDQWt
> bHISBL9wORBxaS+ENE1kicSBsVAJvEBA8gAY9p5kYncL9K1tK54XoklujTIHxrfU
> g0NdprFv1LYZxxQyWmoP5zHSfvBsR2pjLpLSn3G2q32+gALgfu5hAWuJIUq5z4XZ
> 65sfVEtfV9lntohTNqWqu5tdrg0TyblXMruNMB9ygW2DAbHO93Sjkpj2t/AieQwv
> GtvJd1XC7shERazFtplE6o5UZaOrg+N/B2BALvqVoVMR+tAGNrbQqZZjDz+zPzGA
> cL3xNcKN5OqPMFbnge8Ar1v87ywcmvO3arj1lvE6kt97VNeSAOFj7+9i2VWEqu0K
> HDrLv4Ca2ESu3k/MO/eerC5os2dEoVXQEejyBrMtHPDaD40VxJIrYbRmbS/dqk5F
> fjSmcWIopl3+z8/6lex2JGNc26liyvseIrnUtCP8CUklDMilS2XOGVvypDmZNEH1
> rce8IBV3LrRqO/VJ18/VWsc6u6qp9QB6bD8Qvo/dpvX3uIeb4QDDz/9W1UDibG37
> 0ZBqHkjty8C5wHxf5ep06lSdLbiH2NdY1LXKkz5Ru9cXElifVaE=
> =gJWI
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> Have you tried E:/path/to/cert.jks ?

Re: SEVERE: A child container failed during start

[M. Manna]

Karen,

On Sat, 30 Nov 2019 at 00:58, Karen Goh 
wrote:

>
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Saturday, November 30, 2019, 6:18 AM, Mark Thomas 
> wrote:
>
> On 29/11/2019 21:28, Karen Goh wrote:
> > I have done so but it is no use. I have deleted the Tomcat and add an
> new instance before run the server again.
> > caused by java.lang.IllegalArgumentException : Filter mapping specifies
> an unknown filter name[SessionValidator]
> > Sorry I am having problem with writing here using Yahoo mail n I have to
> type things out in iPhone so I can’t copy n paste the entire error
> message. Should you need more info in order to help me I hope I can just
> write above the reply message.
>
> You seem to be missing the point. The problematic filter is named:
>
> httpHeaderSecurity
>
> You need to find where that is referenced in your code and/or
> configuration.
> I can’t find this filter at all, even though I am playing with something
> along the line of httpHeaderSecurity (JWT/JSSE etc to be precise) but my
> project is done intermittently cos most of the time I am meshing up the
> code from various sources and use it...
> What do I do in this case?  Re-start a fresh project?
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
>
As I replied before, your best option would be:

1) remove all your custom filters from filter mappings so that there is no
filter (only for this test).
2) Start tomcat and confirm that startup is normal without issues
3) Now put back your filters 1-by-1 and repeat step 1-2 to see what breaks.

It's appears a big effort at first glance, but it's a good way to sift
through the problem.

Thanks,

Re: SEVERE: A child container failed during start

[M. Manna]

Karen,

On Fri, 29 Nov 2019 at 20:51, Karen Goh 
wrote:

>
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Friday, November 29, 2019, 8:39 PM, Karen Goh
>  wrote:
>
>
>
>
>
>
> On Friday, November 29, 2019, 6:59:38 PM GMT+8, Mark Thomas <
> ma...@apache.org> wrote:
>
>
> On 29/11/2019 10:44, Karen Goh wrote:
> > Hi experts,
> >
> >
> > Basically, I have now upgraded my dynamic MVC web app to use openJDK 13
> and running it with Tomcat 9.0.27. Windows OS. Eclipse 2019-09.
> >
> > Have been trying to tackling the problem with no avail.
> >
> > Would appreciate some tips on how to make these error go away.
>
> 
>
> > Caused by: java.lang.IllegalArgumentException: Filter mapping specifies
> an unknown filter name [httpHeaderSecurity]
>
> 
> I am not sure why the error persists even if I change the filter mapping
> to :
>
> SessionValidator/login.jsp
> And here is snippet my Filter :
> @WebFilter(“/SessionValidator”)public class SessionValidator implements
> Filter
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain) throws IOException, ServletException{
> ..HttpSession session = httpRequest.getSession();If(session.isNew())
> {httpResponse.sendRedirect(httpResponse.encodedRedirectURL(httpRequest.getContextPath()
> + “/login.jsp”return;}And then redirect the user to error.html if log in
> user is null.
> Please let me know what’s wrong.
> Thanks
> Where and how is this filter specified as being required?
> Where and how is this filter defined?
>
> Please see below
>
> 
> http://www.w3.org/2001/XMLSchema-instance; xmlns="
> http://xmlns.jcp.org/xml/ns/javaee; xsi:schemaLocation="
> http://xmlns.jcp.org/xml/ns/javaee
> http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd; version="4.0">
>  Archetype Created Web Application
>  
>  
>  Restricted Area
>  /search.jsp
>  
>  
>  
>  SessionValidator
>  Controller.SessionValidator
>  
>  
>  404
>  /error.html
>  
>  
>  403
>  /error.html
>  
>  
>  500
>  /error.html
>  
>  
>  java.lang.Exception
>  /error.html
>  
> 
>
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
>
 I would advise that you remove @WebFilter and try again. Seems like it's
conflicted with processing annotation based and web.xml supplied filter
definitions.
Once you remove the annotation, give it a try and let us know.

Thanks,

Re: Tomcat 9 relaxedQueryChars format

[M. Manna]

To clarify (along with my last reply) - what you are trying to do is not
correct. The tomcat documentation confirms that only the following are
allowed

The HTTP/1.1 specification <https://tools.ietf.org/rfc/rfc7230.txt> requires
> that certain characters are %nn encoded when used in URI query strings.
> Unfortunately, many user agents including all the major browsers are not
> compliant with this specification and use these characters in unencoded
> form. To prevent Tomcat rejecting such requests, this attribute may be used
> to specify the additional characters to allow. If not specified, no
> additional characters will be allowed. The value may be any combination of
> the following characters: " < > [ \ ] ^ ` { | } . Any other characters
> present in the value will be ignored.


On Fri, 29 Nov 2019 at 15:39, M. Manna  wrote:

> Robert,
>
> On Fri, 29 Nov 2019 at 15:28, Robert Hicks  wrote:
>
>> What is the correct format?
>>
>> I see the following used when I do a search:
>>
>> relaxedQueryChars="[,],{,}.|"
>>
>> relaxedQueryChars="[ ] { } |"
>>
>> relaxedQueryChars="[]|{}^"
>>
>> We use that last one. I am running down this error:
>>
>> java.lang.IllegalArgumentException: Invalid character found in the
>> request target. The valid characters are defined in RFC 7230 and RFC
>> 3986
>>
>> Thanks!
>>
>> --
>>
>>
> This is a working version in Http11AprProtocol
>
> relaxedQueryChars="{[,:]|}"
>
>
>
>
>> Bob
>>
>

Re: Tomcat 9 relaxedQueryChars format

[M. Manna]

Robert,

On Fri, 29 Nov 2019 at 15:28, Robert Hicks  wrote:

> What is the correct format?
>
> I see the following used when I do a search:
>
> relaxedQueryChars="[,],{,}.|"
>
> relaxedQueryChars="[ ] { } |"
>
> relaxedQueryChars="[]|{}^"
>
> We use that last one. I am running down this error:
>
> java.lang.IllegalArgumentException: Invalid character found in the
> request target. The valid characters are defined in RFC 7230 and RFC
> 3986
>
> Thanks!
>
> --
>
>
This is a working version in Http11AprProtocol

relaxedQueryChars="{[,:]|}"




> Bob
>

Re: Double Slash Support in Tomcat 9.0.27

[M. Manna]

Kushagra,

On Fri, 29 Nov 2019 at 12:29, Kushagra Bindal 
wrote:

> Hi Mark,
>
> This astrik is because I highlighted it as BOLD. But I guess at your end it
> is being received as plain text. Resending the content in context.xml
>
> 
>
> 
> 
> WEB-INF/web.xml
> WEB-INF/tomcat-web.xml
> ${catalina.base}/conf/web.xml
>
>  type="javax.sql.DataSource"/>
>
>  className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
>
> 
> 
>
> 
> 
> 
>
>
>
> On Fri, Nov 29, 2019 at 5:52 PM M. Manna  wrote:
>
> > Hi
> >
> > On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal  >
> > wrote:
> >
> > > Hi Mark,
> > >
> > > We tried to put the changes as suggested by you. Below are the changes
> > that
> > > we have made in context.xml file.
> > >
> > > 
> >
> >
> > Why this asterisk? *
> >
> > >
> > >
> > > 
> > > 
> > > WEB-INF/web.xml
> > > WEB-INF/tomcat-web.xml
> > > ${catalina.base}/conf/web.xml
> > >
> > >  > > type="javax.sql.DataSource"/>
> > >
> > >  > > className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
> > >
> > > 
> > > 
> > >
> > > 
> > > 
> > > 
> > >
> > > But after restart still I am getting below errors in tomcat's
> > > *localhost_access_log.2019-11-29.txt* file.
> > >
> > > 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > 172.18.0.3 - - [29/Nov/2019:11:27:46 +] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > >
> > > Please help me in correcting the syntax.
> > >
> > > Regards
> > > Kushagra
> > >
> > > On Fri, Nov 29, 2019 at 4:02 PM Kushagra Bindal <
> > bindal.kusha...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi Mark,
> > > >
> > > > Thanks for providing the response.
> > > >
> > > > Yes, you are right that we should design our application to remove //
> > > from
> > > > being used.
> > > >
> > > > I will plan it accordingly, for the provided solution in below. Let
> me
> > > try
> > > > the same and I will revert back to you in case of any further queries
> > and
> > > > concerns.
> > > >
> > > > On Fri, Nov 29, 2019 at 2:56 PM M. Manna  wrote:
> > > >
> > > >> HI,
> > > >>
> > > >>
> > > >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> > > bindal.kusha...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > We are working on upgrading our enterprise application from 8.5.24
> > to
> > > >> > 9.0.27 version.
> > > >> >
> > > >> > What we have observed that in earlier version i.e. 8.5.24 we were
> > able
> > > >> to
> > > >> > process process a REST URI have  double slash ("//") in it.
> > > >> >
> > > >> > But when we are upgrading it to 9.0.27 we found that now the same
> > url
> > > >> which
> > > >> > was working earlier it is now throwing 404 status code.
> > > >> >
> > > >> > Now, the problem is that we can not remove these double slash (//)
> > > >> manually
> > > >> > as it is used widely.
> > > >> >
> > > >> > So, can someone please provide a possible solution of this issue?
> > > >> >
> > > >>
> > > >>  Tomcat processes HTTP query and URL using RFC 7230 standards. But
> > > >> multiple
> > > >> leading forward slash support was disabled by default for good
> > reasons.
> > > >> This was done in 8.5.31 due to issues with Http Redirects involving
> > > >> Servlets.
> > > >>
> > > >> If you must use this, you have to modify your application context to
> > add
> > > >> the override as true - the attribute is called
> > > >> "allowMultipleLeadingForwardSlashInPath".
> > > >>
> > > >> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
> > > >>
> > > >> But I would sincerely recommend that you work on such designs and
> > > correct
> > > >> them in your application. There is always a "way". This is one of
> the
> > > >> reasons web applications become obsolete requires huge maintenance.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> >
> > > >> > --
> > > >> > Regards,
> > > >> > Kushagra Bindal
> > > >> > +91-9013792807
> > > >> >
> > > >>
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Kushagra Bindal
> > > > +91-9013792807
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Kushagra Bindal
> > > +91-9013792807
> > >
> >
>
>
I have just started a tomcat with


in the context.xml file. works just fine. I am not Mark, but he did suggest
that your issue is probably handled better in filtering at Servlet request
level.

If you also provide the below (as Mark suggested earlier in his reply),
that will be great:


>
>
>
> *Can you provide more details such as:- an example request URI- the
>  for the servlet you expect it to match toThanks,Mark  *


Thanks,



> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>

Re: Double Slash Support in Tomcat 9.0.27

[M. Manna]

Hi

On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal 
wrote:

> Hi Mark,
>
> We tried to put the changes as suggested by you. Below are the changes that
> we have made in context.xml file.
>
> 


Why this asterisk? *

>
>
> 
> 
> WEB-INF/web.xml
> WEB-INF/tomcat-web.xml
> ${catalina.base}/conf/web.xml
>
>  type="javax.sql.DataSource"/>
>
>  className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
>
> 
> 
>
> 
> 
> 
>
> But after restart still I am getting below errors in tomcat's
> *localhost_access_log.2019-11-29.txt* file.
>
> 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> 172.18.0.3 - - [29/Nov/2019:11:27:46 +] "GET
> /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
>
> Please help me in correcting the syntax.
>
> Regards
> Kushagra
>
> On Fri, Nov 29, 2019 at 4:02 PM Kushagra Bindal  >
> wrote:
>
> > Hi Mark,
> >
> > Thanks for providing the response.
> >
> > Yes, you are right that we should design our application to remove //
> from
> > being used.
> >
> > I will plan it accordingly, for the provided solution in below. Let me
> try
> > the same and I will revert back to you in case of any further queries and
> > concerns.
> >
> > On Fri, Nov 29, 2019 at 2:56 PM M. Manna  wrote:
> >
> >> HI,
> >>
> >>
> >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> bindal.kusha...@gmail.com>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > We are working on upgrading our enterprise application from 8.5.24 to
> >> > 9.0.27 version.
> >> >
> >> > What we have observed that in earlier version i.e. 8.5.24 we were able
> >> to
> >> > process process a REST URI have  double slash ("//") in it.
> >> >
> >> > But when we are upgrading it to 9.0.27 we found that now the same url
> >> which
> >> > was working earlier it is now throwing 404 status code.
> >> >
> >> > Now, the problem is that we can not remove these double slash (//)
> >> manually
> >> > as it is used widely.
> >> >
> >> > So, can someone please provide a possible solution of this issue?
> >> >
> >>
> >>  Tomcat processes HTTP query and URL using RFC 7230 standards. But
> >> multiple
> >> leading forward slash support was disabled by default for good reasons.
> >> This was done in 8.5.31 due to issues with Http Redirects involving
> >> Servlets.
> >>
> >> If you must use this, you have to modify your application context to add
> >> the override as true - the attribute is called
> >> "allowMultipleLeadingForwardSlashInPath".
> >>
> >> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
> >>
> >> But I would sincerely recommend that you work on such designs and
> correct
> >> them in your application. There is always a "way". This is one of the
> >> reasons web applications become obsolete requires huge maintenance.
> >>
> >> Thanks,
> >>
> >> >
> >> > --
> >> > Regards,
> >> > Kushagra Bindal
> >> > +91-9013792807
> >> >
> >>
> >
> >
> > --
> > Regards,
> > Kushagra Bindal
> > +91-9013792807
> >
>
>
> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>

Re: SEVERE: A child container failed during start

[M. Manna]

Hi,

On Fri, 29 Nov 2019 at 10:45, Karen Goh 
wrote:

> Hi experts,
>
>
> Basically, I have now upgraded my dynamic MVC web app to use openJDK 13
> and running it with Tomcat 9.0.27.  Windows OS. Eclipse 2019-09.
>
> Have been trying to tackling the problem with no avail.
>
> Would appreciate some tips on how to make these error go away.
>
> Here's the error :
>
> Nov 29, 2019 6:25:18 PM org.apache.catalina.core.ContainerBase
> startInternal
> SEVERE: A child container failed during start
> java.util.concurrent.ExecutionException:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webApp-hi5]]
> at
> java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at
> java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
> at
> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
> at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
> at
> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:421)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:633)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:344)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:475)
> Caused by: org.apache.catalina.LifecycleException: Failed to start
> component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webApp-hi5]]
> at
> org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
> at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
> ... 21 more
> Caused by: java.lang.IllegalArgumentException: Filter mapping specifies an
> unknown filter name [httpHeaderSecurity]
> at
> org.apache.catalina.core.StandardContext.validateFilterMap(StandardContext.java:3009)
> at
> org.apache.catalina.core.StandardContext.addFilterMap(StandardContext.java:2971)
> at
> org.apache.catalina.startup.ContextConfig.configureContext(ContextConfig.java:1288)
> at
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1168)
> at
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:774)
> at
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5051)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> ... 27 more
>
> Nov 29, 2019 6:25:18 PM org.apache.catalina.core.ContainerBase
> startInternal
> SEVERE: A child container failed during start
> java.util.concurrent.ExecutionException:
> 

Re: Double Slash Support in Tomcat 9.0.27

[M. Manna]

HI,


On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal 
wrote:

> Hi,
>
> We are working on upgrading our enterprise application from 8.5.24 to
> 9.0.27 version.
>
> What we have observed that in earlier version i.e. 8.5.24 we were able to
> process process a REST URI have  double slash ("//") in it.
>
> But when we are upgrading it to 9.0.27 we found that now the same url which
> was working earlier it is now throwing 404 status code.
>
> Now, the problem is that we can not remove these double slash (//) manually
> as it is used widely.
>
> So, can someone please provide a possible solution of this issue?
>

 Tomcat processes HTTP query and URL using RFC 7230 standards. But multiple
leading forward slash support was disabled by default for good reasons.
This was done in 8.5.31 due to issues with Http Redirects involving
Servlets.

If you must use this, you have to modify your application context to add
the override as true - the attribute is called
"allowMultipleLeadingForwardSlashInPath".

https://tomcat.apache.org/tomcat-8.5-doc/config/context.html

But I would sincerely recommend that you work on such designs and correct
them in your application. There is always a "way". This is one of the
reasons web applications become obsolete requires huge maintenance.

Thanks,

>
> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>

Re: CPU high usage, the reason org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run

[M. Manna]

I’m suspecting it’s the same issue that we found out for 8.5.45 where the
commit didn’t get reverted out in Poll.java

Or maybe not.

Thanks,

On Sun, 24 Nov 2019 at 10:36, Mark Thomas  wrote:

> Tomcat version?
>
> Operating system?
>
> Java version?
>
> Mark
>
>
> On 24/11/2019 09:57, Mladen Adamović wrote:
> > I couldn't find the explanation of this in other threads, I've tried to
> > search the archive.
> >
> > I have a high load average on a server and the reason for that is kernel
> > function futex_wait invoked by java thread.
> >
> > By doing jstack, I see a lot of BLOCKED threads like these:
> > Thread 1725: (state = BLOCKED)
> >  - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame;
> information
> > may be imprecise)
> >  - java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object,
> long)
> > @bci=20, line=215 (Compiled frame)
> >  -
> >
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(long)
> > @bci=78, line=2078 (Compiled frame)
> >  - java.util.concurrent.LinkedBlockingQueue.poll(long,
> > java.util.concurrent.TimeUnit) @bci=62, line=467 (Compiled frame)
> >  - org.apache.tomcat.util.threads.TaskQueue.poll(long,
> > java.util.concurrent.TimeUnit) @bci=3, line=85 (Compiled frame)
> >  - org.apache.tomcat.util.threads.TaskQueue.poll(long,
> > java.util.concurrent.TimeUnit) @bci=3, line=31 (Compiled frame)
> >  - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=134, line=1066
> > (Compiled frame)
> >  -
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
> > @bci=26, line=1127 (Compiled frame)
> >  - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617
> > (Compiled frame)
> >  - org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run()
> @bci=4,
> > line=61 (Compiled frame)
> >  - java.lang.Thread.run() @bci=11, line=745 (Compiled frame)
> >
> >
> >
> > What does this
> > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run() actually
> > does when BLOCKED?
> >
> > Should I perhaps lower some tomcat config values or just forget about
> > measuring system resources if the server works? My tomcat is configured
> as
> > follows:
> >
> >
> > my Tomcat is configured as follows:
> >> protocol="org.apache.coyote.http11.Http11AprProtocol"
> >   SSLCertificateFile="/etc/letsencrypt/live/
> numbeo.com/cert.pem"
> >   SSLCertificateKeyFile="/etc/letsencrypt/live/
> > numbeo.com/privkey.pem"
> >   SSLCertificateChainFile="/etc/letsencrypt/live/
> > numbeo.com/chain.pem"
> >   SSLVerifyClient="optional"
> SSLProtocol="TLSv1+TLSv1.1+TLSv1.2"
> >   connectionTimeout="2" acceptCount="3"
> >   acceptorThreadCount="2"
> >   compression="on" maxConnections="5" maxThreads="500"
> >
> >
> compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,image/svg+xml,image/svg,image/png,image/jpeg"
> >
> >   useSendfile="false"
> >   maxHttpHeaderSize="16392" SSLEnabled="true"
> >   enableLookups="false"
> >   scheme="https" secure="true"   clientAuth="false"
> >  useBodyEncodingForURI="true"
> >   URIEncoding="UTF-8"
> >   />
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: tomcat thread incurring CPU load

[M. Manna]

Sorry Dumb question earlier - It is in Coyote jar.

We are currently in a rollback state in our prod, but what you reported
above sounds promising. If revert the Coyote jar resolves issues, which is
the earliest/latest version we can revert to?

Thanks,
MAnna

On Tue, 19 Nov 2019 at 10:32, M. Manna  wrote:

> Mark,
>
> On Mon, 18 Nov 2019 at 19:28, Mark Thomas  wrote:
>
>> On 18/11/2019 14:14, Mark Thomas wrote:
>> > On 18/11/2019 12:06, M. Manna wrote:
>> >> Mark and others,
>> >>
>> >> On Mon, 18 Nov 2019 at 12:01, Mark Thomas  wrote:
>> >>
>> >>> OK, it looks like I can reproduce this.
>> >>>
>> >>> Steps to reproduce:
>> >>>
>> >>> - Windows 2016 Server fully patched
>> >>> - Java 1.8.0u144
>> >>> - Install Tomcat 8.5.45 from windows installer
>> >>> - Add tcnative-1.dll (64-bit) from Tomcat Native 1.2.23
>> >>> - Modify server.xml to use Http11AprProtocol on port 8080
>> >>> - Make a single request
>> >>>
>> >>> I then see 1 core running at 100% until the connection times out after
>> >>> 20s. Make another request and a core goes back up to 100% for 20s (the
>> >>> default keep-alive time out).
>> >>>
>> >>
>> >>  I have also successfully reproduced this with making a single request
>> >> (sorry for not replying in the weekend). Not sure how your graph looked
>> >> like, but the Jvisualvm showed me a Sinusoidal modulation curve as
>> soon as
>> >> the request hit the server. and it didn't go down at all.
>> >
>> > I see similar behaviour on Windows 7 but the the CPU usage drops after
>> ~5s.
>> >
>> > A binary search indicates that the issue was introduced with this
>> commit:
>> >
>> >
>> https://github.com/apache/tomcat/commit/fffb08790e642e03f00c5f96a3a61ee09a2c8342
>> >
>> > (this is for 9.0.x - 8.5.x and 7.0.x had similar commits)
>> >
>> > However, that code was removed when APR was switched to a single poll
>> > set.
>>
>> Ah ha. It was removed in 9.0.x but not in 8.5.x (only 9.0.x switched to
>> a single Poller) so it does look like this change is responsible.
>>
>>  Thanks for Debugging this. Are you saying that we will have a patch for
> this? If so, which jar could we replace in 8.5.45 until
> we move to new tomcat?
>
> Thanks,
>
>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

Re: tomcat thread incurring CPU load

[M. Manna]

Mark,

On Mon, 18 Nov 2019 at 19:28, Mark Thomas  wrote:

> On 18/11/2019 14:14, Mark Thomas wrote:
> > On 18/11/2019 12:06, M. Manna wrote:
> >> Mark and others,
> >>
> >> On Mon, 18 Nov 2019 at 12:01, Mark Thomas  wrote:
> >>
> >>> OK, it looks like I can reproduce this.
> >>>
> >>> Steps to reproduce:
> >>>
> >>> - Windows 2016 Server fully patched
> >>> - Java 1.8.0u144
> >>> - Install Tomcat 8.5.45 from windows installer
> >>> - Add tcnative-1.dll (64-bit) from Tomcat Native 1.2.23
> >>> - Modify server.xml to use Http11AprProtocol on port 8080
> >>> - Make a single request
> >>>
> >>> I then see 1 core running at 100% until the connection times out after
> >>> 20s. Make another request and a core goes back up to 100% for 20s (the
> >>> default keep-alive time out).
> >>>
> >>
> >>  I have also successfully reproduced this with making a single request
> >> (sorry for not replying in the weekend). Not sure how your graph looked
> >> like, but the Jvisualvm showed me a Sinusoidal modulation curve as soon
> as
> >> the request hit the server. and it didn't go down at all.
> >
> > I see similar behaviour on Windows 7 but the the CPU usage drops after
> ~5s.
> >
> > A binary search indicates that the issue was introduced with this commit:
> >
> >
> https://github.com/apache/tomcat/commit/fffb08790e642e03f00c5f96a3a61ee09a2c8342
> >
> > (this is for 9.0.x - 8.5.x and 7.0.x had similar commits)
> >
> > However, that code was removed when APR was switched to a single poll
> > set.
>
> Ah ha. It was removed in 9.0.x but not in 8.5.x (only 9.0.x switched to
> a single Poller) so it does look like this change is responsible.
>
>  Thanks for Debugging this. Are you saying that we will have a patch for
this? If so, which jar could we replace in 8.5.45 until
we move to new tomcat?

Thanks,


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

Re: tomcat thread incurring CPU load

[M. Manna]

Mark and others,

On Mon, 18 Nov 2019 at 12:01, Mark Thomas  wrote:

> OK, it looks like I can reproduce this.
>
> Steps to reproduce:
>
> - Windows 2016 Server fully patched
> - Java 1.8.0u144
> - Install Tomcat 8.5.45 from windows installer
> - Add tcnative-1.dll (64-bit) from Tomcat Native 1.2.23
> - Modify server.xml to use Http11AprProtocol on port 8080
> - Make a single request
>
> I then see 1 core running at 100% until the connection times out after
> 20s. Make another request and a core goes back up to 100% for 20s (the
> default keep-alive time out).
>

 I have also successfully reproduced this with making a single request
(sorry for not replying in the weekend). Not sure how your graph looked
like, but the Jvisualvm showed me a Sinusoidal modulation curve as soon as
the request hit the server. and it didn't go down at all.

Thanks,

>
> Next steps are to try and track down the root cause.
>
> Mark
>
>
>
> > Mark and M,
> >
> > On 11/13/19 19:31, Mark Thomas wrote:
> >> On November 13, 2019 11:42:34 PM UTC, "M. Manna"
> >>  wrote:
> >>> I see this update on Windows which may have been responsible
> >>> (suspicion only, haven’t rolled it back yet)
> >>>
> >>>
> >>> https://support.microsoft.com/en-gb/help/4494175/kb4494175-intel-micr
> > ocode-updates
> >>>
> >>>
> >>>
> > Was 8.5.45 built on Windows 10 in presence of this update ?
> >
> >> No. Tomcat 8.5.45 and Tomcat Native 1.2.23 were built on a fully
> >> patched at the time of the build Windows 7 64-bit VM.
> > Also it doesn't matter because binaries don't include CPU microcode.
> >
> > It's more likely that the target system has microcode updates such as
> > these that may negatively impact performance.
> >
> > -chris
> >
> >>>
> >>> Thanks,
> >>>
> >>> On Wed, 13 Nov 2019 at 17:55, M. Manna 
> >>> wrote:
> >>>
> >>>> Hi Chris,
> >>>>
> >>>> On Wed, 13 Nov 2019 at 16:27, Christopher Schultz <
> >>>> ch...@christopherschultz.net> wrote:
> >>>>
> >> On 11/13/19 11:20, M. Manna wrote:
> >>>>>>> HI Mark,
> >>>>>>>
> >>>>>>> On Wed, 13 Nov 2019 at 15:38, Mark Thomas
> >>>>>>>  wrote:
> >>>>>>>
> >>>>>>>> On 12/11/2019 19:11, M. Manna wrote:
> >>>>>>>>> HI Mark,
> >>>>>>>>>
> >>>>>>>>> following my previous reply, we have now confirmed
> >>>>>>>>> that it's indeed
> >>>>>>>> 8.5.45
> >>>>>>>>> with APR 1.2.23 that's causing such high JVM CPU
> >>>>>>>>> usage. We used took out 2 out of 50 servers from the
> >>>>>>>>> load balancer config, reverted tomcat, and
> >>>>>>>>> redeployed. With near to identical user traffic, the
> >>>>>>>>> two servers are responding normally without/without
> >>>>>>>>> traffic with 8.5.41. The JVM dump looks a lot better
> >>>>>>>>> with 8.5.41.
> >>>>>>>>>
> >>>>>>>>> We do think that the recent changes in APR and some
> >>>>>>>>> other tomcat jar may have caused compatibility issue
> >>>>>>>>> on Windows server 2016 (64-bit) platform. But
> >>>>>>>>> unfortunately, we cannot pinpoint exactly what change
> >>>>>>>>> may have caused this (i.e. actual OS vs Security
> >>>>>>>>> Updates). With this in mind, we are also being wary
> >>>>>>>>> to move to 8.5.47 as we don't know if the same issue
> >>>>>>>>> will
> >>>>>>>> occur
> >>>>>>>>> again. Since 8.5.41 has been packaged with previously
> >>>>>>>>> accepted
> >>>>>>>> application
> >>>>>>>>> installer, we are more comfortable rolling back.
> >>>>>>>>
> >>>>>>>> Just to confirm, you see this high CPU usage with a
> >>>>>>>> clean install (no additional web applications deployed,
> >>>>>>>> no configuration changes) on

Re: tomcat thread incurring CPU load

[M. Manna]

I see this update on Windows which may have been responsible (suspicion
only, haven’t rolled it back yet)


https://support.microsoft.com/en-gb/help/4494175/kb4494175-intel-microcode-updates

Was 8.5.45 built on Windows 10 in presence of this update ?

Thanks,

On Wed, 13 Nov 2019 at 17:55, M. Manna  wrote:

> Hi Chris,
>
> On Wed, 13 Nov 2019 at 16:27, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 11/13/19 11:20, M. Manna wrote:
>> > HI Mark,
>> >
>> > On Wed, 13 Nov 2019 at 15:38, Mark Thomas 
>> > wrote:
>> >
>> >> On 12/11/2019 19:11, M. Manna wrote:
>> >>> HI Mark,
>> >>>
>> >>> following my previous reply, we have now confirmed that it's
>> >>> indeed
>> >> 8.5.45
>> >>> with APR 1.2.23 that's causing such high JVM CPU usage. We used
>> >>> took out 2 out of 50 servers from the load balancer config,
>> >>> reverted tomcat, and redeployed. With near to identical user
>> >>> traffic, the two servers are responding normally
>> >>> without/without traffic with 8.5.41. The JVM dump looks a lot
>> >>> better with 8.5.41.
>> >>>
>> >>> We do think that the recent changes in APR and some other
>> >>> tomcat jar may have caused compatibility issue on Windows
>> >>> server 2016 (64-bit) platform. But unfortunately, we cannot
>> >>> pinpoint exactly what change may have caused this (i.e. actual
>> >>> OS vs Security Updates). With this in mind, we are also being
>> >>> wary to move to 8.5.47 as we don't know if the same issue will
>> >> occur
>> >>> again. Since 8.5.41 has been packaged with previously accepted
>> >> application
>> >>> installer, we are more comfortable rolling back.
>> >>
>> >> Just to confirm, you see this high CPU usage with a clean install
>> >> (no additional web applications deployed, no configuration
>> >> changes) on Windows 2016 DataCenter (64-bit)?
>> >>
>> >> If this is the case, it should be fairly easy to reproduce.
>> >>
>> >> Mark
>> >>
>> >> We do not deploy multiple applications. In fact, Under tomcat
>> > webapps/ROOT we only have one application (ours). Each tomcat
>> > instance is hosted on a VM (total 50) and all of them are
>> > identically configured (server.xml, web.xml, logging, CPU/RAM). We
>> > have not made any other configuration change between 8.5.41 and
>> > 8.5.45. And yes, I agree with you that it's fairly easy to
>> > reproduce.
>>
>> I think the question is whether or not your application is required to
>> be deployed. Can you reproduce this issue with just the stock
>> applications bundled with Tomcat?
>>
>
> My apologies, but our application needs to be deployed. We have not (or
> didn't try in the past) to simply deploy tomcat with stock application (in
> other words, simply starting the tomcat OOB) on our prod servers.
> This is the first time it has hit us with such disparity. I’ll try to
> investigate and get a stock application data. But we may not be able to do
> that quite easily as it’s in our production.
>
> What I can see is that 3 Windows updates may have been responsible for
> this, but we aren’t sure about that. I’ll let you know if we can get
> anything with the stock application instance.
>
> Thanks,
>
> - -chris
>
>> -BEGIN PGP SIGNATURE-
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>>
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3MLscACgkQHPApP6U8
>> pFip5A/+KOg4ZvATDli8zG9ZxniMoPdkOC9LQgVKscjeLZHL/A1gzVLP8UPZSiU7
>> 1+p44WwJ5WGgwe8Ne0NZTFlh7/DZQAGIQZv++Ii9+NRkY5KVP3dYykdoyg1UdUMB
>> Fdu2KNDcsCERYpPqrE/kVk+TQZNI60vY8iTBntc+Og5LsukULZTbX3UO9BzDaqeO
>> WsjVuP6q7hUDBntd+5YqeFKDJ07zEIm5V6vmHAbCOWm3g2B8IXiYkMTXM+ZLld9h
>> 6Th8f+na79taUrxT9TwI1WoR/ZJguJW1c8eRPbykv9/riDrtTQsv0BZy0ZeMhnjv
>> kEwurNMaYjtSSCGOD0e8/chy1rU0/gng99pkmGe0Wiwoob6/6AU0HhE/2RvLKzDY
>> mR4hu+aDaxtog4CD9DQrGenId+pwbJteqhXVCye6V0A3JtobbR+D56cxcUbth1pP
>> skMdXrTWTvVlmsyLfKjPmMiALzOqg0bqvfYH5bEitW1Y8HvCQN5vcht2+EOpchmp
>> zZ0f0LQpXEyr3DJ/GSbPTRKHghMAnrB4yz9jlMvzdWoPX2/JyT3+IQOoe8eRtlD8
>> e6uoQzXoguXFr9J5OLGR5TXdBLx5/obCUWUM2wS/w5TQ3MvV3C5haSKYWTVIcetp
>> XuAzKmK6fKFBHn37pMLd4VELy9Ay+zQmtTrpDJzB9pPwX/gr6JQ=
>> =VqkL
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

Re: tomcat thread incurring CPU load

[M. Manna]

Hi Chris,

On Wed, 13 Nov 2019 at 16:27, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 11/13/19 11:20, M. Manna wrote:
> > HI Mark,
> >
> > On Wed, 13 Nov 2019 at 15:38, Mark Thomas 
> > wrote:
> >
> >> On 12/11/2019 19:11, M. Manna wrote:
> >>> HI Mark,
> >>>
> >>> following my previous reply, we have now confirmed that it's
> >>> indeed
> >> 8.5.45
> >>> with APR 1.2.23 that's causing such high JVM CPU usage. We used
> >>> took out 2 out of 50 servers from the load balancer config,
> >>> reverted tomcat, and redeployed. With near to identical user
> >>> traffic, the two servers are responding normally
> >>> without/without traffic with 8.5.41. The JVM dump looks a lot
> >>> better with 8.5.41.
> >>>
> >>> We do think that the recent changes in APR and some other
> >>> tomcat jar may have caused compatibility issue on Windows
> >>> server 2016 (64-bit) platform. But unfortunately, we cannot
> >>> pinpoint exactly what change may have caused this (i.e. actual
> >>> OS vs Security Updates). With this in mind, we are also being
> >>> wary to move to 8.5.47 as we don't know if the same issue will
> >> occur
> >>> again. Since 8.5.41 has been packaged with previously accepted
> >> application
> >>> installer, we are more comfortable rolling back.
> >>
> >> Just to confirm, you see this high CPU usage with a clean install
> >> (no additional web applications deployed, no configuration
> >> changes) on Windows 2016 DataCenter (64-bit)?
> >>
> >> If this is the case, it should be fairly easy to reproduce.
> >>
> >> Mark
> >>
> >> We do not deploy multiple applications. In fact, Under tomcat
> > webapps/ROOT we only have one application (ours). Each tomcat
> > instance is hosted on a VM (total 50) and all of them are
> > identically configured (server.xml, web.xml, logging, CPU/RAM). We
> > have not made any other configuration change between 8.5.41 and
> > 8.5.45. And yes, I agree with you that it's fairly easy to
> > reproduce.
>
> I think the question is whether or not your application is required to
> be deployed. Can you reproduce this issue with just the stock
> applications bundled with Tomcat?
>

My apologies, but our application needs to be deployed. We have not (or
didn't try in the past) to simply deploy tomcat with stock application (in
other words, simply starting the tomcat OOB) on our prod servers.
This is the first time it has hit us with such disparity. I’ll try to
investigate and get a stock application data. But we may not be able to do
that quite easily as it’s in our production.

What I can see is that 3 Windows updates may have been responsible for
this, but we aren’t sure about that. I’ll let you know if we can get
anything with the stock application instance.

Thanks,

- -chris

> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3MLscACgkQHPApP6U8
> pFip5A/+KOg4ZvATDli8zG9ZxniMoPdkOC9LQgVKscjeLZHL/A1gzVLP8UPZSiU7
> 1+p44WwJ5WGgwe8Ne0NZTFlh7/DZQAGIQZv++Ii9+NRkY5KVP3dYykdoyg1UdUMB
> Fdu2KNDcsCERYpPqrE/kVk+TQZNI60vY8iTBntc+Og5LsukULZTbX3UO9BzDaqeO
> WsjVuP6q7hUDBntd+5YqeFKDJ07zEIm5V6vmHAbCOWm3g2B8IXiYkMTXM+ZLld9h
> 6Th8f+na79taUrxT9TwI1WoR/ZJguJW1c8eRPbykv9/riDrtTQsv0BZy0ZeMhnjv
> kEwurNMaYjtSSCGOD0e8/chy1rU0/gng99pkmGe0Wiwoob6/6AU0HhE/2RvLKzDY
> mR4hu+aDaxtog4CD9DQrGenId+pwbJteqhXVCye6V0A3JtobbR+D56cxcUbth1pP
> skMdXrTWTvVlmsyLfKjPmMiALzOqg0bqvfYH5bEitW1Y8HvCQN5vcht2+EOpchmp
> zZ0f0LQpXEyr3DJ/GSbPTRKHghMAnrB4yz9jlMvzdWoPX2/JyT3+IQOoe8eRtlD8
> e6uoQzXoguXFr9J5OLGR5TXdBLx5/obCUWUM2wS/w5TQ3MvV3C5haSKYWTVIcetp
> XuAzKmK6fKFBHn37pMLd4VELy9Ay+zQmtTrpDJzB9pPwX/gr6JQ=
> =VqkL
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: tomcat thread incurring CPU load

[M. Manna]

HI Mark,

On Wed, 13 Nov 2019 at 15:38, Mark Thomas  wrote:

> On 12/11/2019 19:11, M. Manna wrote:
> > HI Mark,
> >
> > following my previous reply, we have now confirmed that it's indeed
> 8.5.45
> > with APR 1.2.23 that's causing such high JVM CPU usage.
> > We used took out 2 out of 50 servers from the load balancer config,
> > reverted tomcat, and redeployed. With near to identical user traffic, the
> > two servers are responding normally without/without traffic with 8.5.41.
> > The JVM dump looks a lot better with 8.5.41.
> >
> > We do think that the recent changes in APR and some other tomcat jar may
> > have caused compatibility issue on Windows server 2016 (64-bit) platform.
> > But unfortunately, we cannot pinpoint exactly what change may have caused
> > this (i.e. actual OS vs Security Updates). With this in mind, we are also
> > being wary to move to 8.5.47 as we don't know if the same issue will
> occur
> > again. Since 8.5.41 has been packaged with previously accepted
> application
> > installer, we are more comfortable rolling back.
>
> Just to confirm, you see this high CPU usage with a clean install (no
> additional web applications deployed, no configuration changes) on
> Windows 2016 DataCenter (64-bit)?
>
> If this is the case, it should be fairly easy to reproduce.
>
> Mark
>
>  We do not deploy multiple applications. In fact, Under tomcat
webapps/ROOT we only have one application (ours). Each tomcat instance is
hosted on a VM (total 50) and all of them are identically configured
(server.xml, web.xml, logging, CPU/RAM).
 We have not made any other configuration change between 8.5.41 and 8.5.45.
And yes, I agree with you that it's fairly easy to reproduce.


Thanks,


>
> >
> > I would appreciate if this can be looked into.
> >
> > On Tue, 12 Nov 2019 at 11:27, M. Manna  wrote:
> >
> >> Hey Mark (appreciate your response in US holiday time)
> >>
> >> On Tue, 12 Nov 2019 at 07:51, Mark Thomas  wrote:
> >>
> >>> On November 12, 2019 12:54:53 AM UTC, "M. Manna" 
> >>> wrote:
> >>>> Just to give an update again:
> >>>>
> >>>> 1) We reverted the APR to 1.2.21 - but observed no difference.
> >>>> 2) We took 3 thread dumps over 1 min interval (without any user
> >>>> sessions) -
> >>>> All threads are tomcat's internal pool threads.
> >>>>
> >>>> When we checked the thread details (using fasthread.io) - we didn't
> see
> >>>> any
> >>>> of our application stack. Since there is no user traffic, this is
> >>>> coming
> >>> >from tomcat internally. At this stage, we cannot really figure out
> >>>> what's
> >>>> the root cause.
> >>>>
> >>>> Any help is appreciated.
> >>>
> >>> Migrated from what (full version info please)?
> >>>
> >>  from 8.5.41 to 8.5.45 (we migrate 3 times a year, last was in June)
> >>
> >>>
> >>> Operating system exact version?
> >>>
> >>  Microsoft Windows Server 2016 DataCentre (64-bit)
> >>
> >>>
> >>> JRE vendor and exact version?
> >>>
> >>  C:\jdk1.8.0\bin>java.exe -version
> >> java version "1.8.0_162"
> >> Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
> >> Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)
> >>
> >>
> >>> Do you see the same behavior with the latest 8.5.x and latest Tomcat
> >>> Native?
> >>>
> >>   We are using APR 1.2.23 which I can also see in latest tomcat. Due to
> >> production due diligence we cannot roll to a different version that
> easily.
> >> Normally, we lag behind by 2 monthly releases of tomcat. We also
> reverted
> >> the APR to 1.2.21 (but no difference).
> >>
> >>>
> >>> What triggers this behaviour?
> >>>
> >>  That is quite strange. Due to US holidays, we had a low traffic on our
> >> servers, and nothing has crept in to suggest that it's
> application-driven.
> >> We took one tomcat instance out of 50 instances and removed all user
> >> sessions (i.e. no application activities or threads). Upon restart of
> >> tomcat, the CPU spike lingered past the initial servlet startup period.
> We
> >> monitored that over 1-2 hours but there was no difference.
> >>
> >>>
> >>> How often do you see this behaviour?
> >&g

Re: tomcat thread incurring CPU load

[M. Manna]

HI Mark,

following my previous reply, we have now confirmed that it's indeed 8.5.45
with APR 1.2.23 that's causing such high JVM CPU usage.
We used took out 2 out of 50 servers from the load balancer config,
reverted tomcat, and redeployed. With near to identical user traffic, the
two servers are responding normally without/without traffic with 8.5.41.
The JVM dump looks a lot better with 8.5.41.

We do think that the recent changes in APR and some other tomcat jar may
have caused compatibility issue on Windows server 2016 (64-bit) platform.
But unfortunately, we cannot pinpoint exactly what change may have caused
this (i.e. actual OS vs Security Updates). With this in mind, we are also
being wary to move to 8.5.47 as we don't know if the same issue will occur
again. Since 8.5.41 has been packaged with previously accepted application
installer, we are more comfortable rolling back.

I would appreciate if this can be looked into.

On Tue, 12 Nov 2019 at 11:27, M. Manna  wrote:

> Hey Mark (appreciate your response in US holiday time)
>
> On Tue, 12 Nov 2019 at 07:51, Mark Thomas  wrote:
>
>> On November 12, 2019 12:54:53 AM UTC, "M. Manna" 
>> wrote:
>> >Just to give an update again:
>> >
>> >1) We reverted the APR to 1.2.21 - but observed no difference.
>> >2) We took 3 thread dumps over 1 min interval (without any user
>> >sessions) -
>> >All threads are tomcat's internal pool threads.
>> >
>> >When we checked the thread details (using fasthread.io) - we didn't see
>> >any
>> >of our application stack. Since there is no user traffic, this is
>> >coming
>> >from tomcat internally. At this stage, we cannot really figure out
>> >what's
>> >the root cause.
>> >
>> >Any help is appreciated.
>>
>> Migrated from what (full version info please)?
>>
>  from 8.5.41 to 8.5.45 (we migrate 3 times a year, last was in June)
>
>>
>> Operating system exact version?
>>
>  Microsoft Windows Server 2016 DataCentre (64-bit)
>
>>
>> JRE vendor and exact version?
>>
>  C:\jdk1.8.0\bin>java.exe -version
> java version "1.8.0_162"
> Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)
>
>
>> Do you see the same behavior with the latest 8.5.x and latest Tomcat
>> Native?
>>
>   We are using APR 1.2.23 which I can also see in latest tomcat. Due to
> production due diligence we cannot roll to a different version that easily.
> Normally, we lag behind by 2 monthly releases of tomcat. We also reverted
> the APR to 1.2.21 (but no difference).
>
>>
>> What triggers this behaviour?
>>
>  That is quite strange. Due to US holidays, we had a low traffic on our
> servers, and nothing has crept in to suggest that it's application-driven.
> We took one tomcat instance out of 50 instances and removed all user
> sessions (i.e. no application activities or threads). Upon restart of
> tomcat, the CPU spike lingered past the initial servlet startup period. We
> monitored that over 1-2 hours but there was no difference.
>
>>
>> How often do you see this behaviour?
>>
> We took 2 sets of data
> 1) 3 Jstack dump based on 10 seconds interval.
> 2) 3 jstack dump based on 1 min interval.
>
> Both the above reveals that all background threads (http, pool etc.) were
> from tomcat. We didn't have any application threads lingered in those 3
> samples. So yes we see this almost all the time if we take samples.
> However, when we compared with pre-production instances (with Windows
> server R2 x64 bit), we don't see such abnormal spike. In fact, the
> application instance doesn't incur such a big CPU spike. Whilst composing
> this email, I am now thinking if the APR is indeed incompatible with
> WIndows Server R2 (or the presence of any Windows Updates) which blocks the
> native poll() call longer than usual.
>
> An example is that on Windows Server 2012 - APR poll() call takes about
> 30% CPU time - but with Windows Server 2016 it's almost always 95%.
>
>
>>
>> And anything else you think might be relevant.
>>
>
> We are using end-2-end encryption using APR (with Certificate and
> SSLConfig resource setup in server.xml). But it's survived past 3 tomcat
> upgrades without any issue.
> Except OS we don't have any obvious culprit identified at the moment.
>
> Thanks,
>
>>
>> Mark
>>
>> >
>> >Thanks,
>> >
>> >On Mon, 11 Nov 2019 at 20:57, M. Manna  wrote:
>> >
>> >> Hello All,
>> >>
>> >> Any thoughts regarding this? Slightly clueless at thi

Re: tomcat thread incurring CPU load

[M. Manna]

Hey Mark (appreciate your response in US holiday time)

On Tue, 12 Nov 2019 at 07:51, Mark Thomas  wrote:

> On November 12, 2019 12:54:53 AM UTC, "M. Manna" 
> wrote:
> >Just to give an update again:
> >
> >1) We reverted the APR to 1.2.21 - but observed no difference.
> >2) We took 3 thread dumps over 1 min interval (without any user
> >sessions) -
> >All threads are tomcat's internal pool threads.
> >
> >When we checked the thread details (using fasthread.io) - we didn't see
> >any
> >of our application stack. Since there is no user traffic, this is
> >coming
> >from tomcat internally. At this stage, we cannot really figure out
> >what's
> >the root cause.
> >
> >Any help is appreciated.
>
> Migrated from what (full version info please)?
>
 from 8.5.41 to 8.5.45 (we migrate 3 times a year, last was in June)

>
> Operating system exact version?
>
 Microsoft Windows Server 2016 DataCentre (64-bit)

>
> JRE vendor and exact version?
>
 C:\jdk1.8.0\bin>java.exe -version
java version "1.8.0_162"
Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)


> Do you see the same behavior with the latest 8.5.x and latest Tomcat
> Native?
>
  We are using APR 1.2.23 which I can also see in latest tomcat. Due to
production due diligence we cannot roll to a different version that easily.
Normally, we lag behind by 2 monthly releases of tomcat. We also reverted
the APR to 1.2.21 (but no difference).

>
> What triggers this behaviour?
>
 That is quite strange. Due to US holidays, we had a low traffic on our
servers, and nothing has crept in to suggest that it's application-driven.
We took one tomcat instance out of 50 instances and removed all user
sessions (i.e. no application activities or threads). Upon restart of
tomcat, the CPU spike lingered past the initial servlet startup period. We
monitored that over 1-2 hours but there was no difference.

>
> How often do you see this behaviour?
>
We took 2 sets of data
1) 3 Jstack dump based on 10 seconds interval.
2) 3 jstack dump based on 1 min interval.

Both the above reveals that all background threads (http, pool etc.) were
from tomcat. We didn't have any application threads lingered in those 3
samples. So yes we see this almost all the time if we take samples.
However, when we compared with pre-production instances (with Windows
server R2 x64 bit), we don't see such abnormal spike. In fact, the
application instance doesn't incur such a big CPU spike. Whilst composing
this email, I am now thinking if the APR is indeed incompatible with
WIndows Server R2 (or the presence of any Windows Updates) which blocks the
native poll() call longer than usual.

An example is that on Windows Server 2012 - APR poll() call takes about 30%
CPU time - but with Windows Server 2016 it's almost always 95%.


>
> And anything else you think might be relevant.
>

We are using end-2-end encryption using APR (with Certificate and SSLConfig
resource setup in server.xml). But it's survived past 3 tomcat upgrades
without any issue.
Except OS we don't have any obvious culprit identified at the moment.

Thanks,

>
> Mark
>
> >
> >Thanks,
> >
> >On Mon, 11 Nov 2019 at 20:57, M. Manna  wrote:
> >
> >> Hello All,
> >>
> >> Any thoughts regarding this? Slightly clueless at this point, so any
> >> direction will be appreciated.
> >>
> >> We are seeing the poll taking all the CPU time. We are using
> >> OperatingSystemMXBean.getProcessCpuLoad() and
> >> OperatingSystemMXBean.getSystemCpuLoad() to get our metrics (then
> >x100 to
> >> get the pct).
> >>
> >> Thanks,
> >>
> >>
> >> On Mon, 11 Nov 2019 at 17:46, M. Manna  wrote:
> >>
> >>> Hello,
> >>>
> >>> after migrating to 8.5.45, we are seeing a lot of cpu load by
> >following
> >>> JVM thread dump:
> >>>
> >>> "https-openssl-apr-0.0.0.0-8443-Poller" : 102 : RUNNABLE :
> >>> cpu=172902703125000 : cpuLoad= 74.181015
> >>>
> >>> BlockedCount:8464 BlockedTime:0 LockName:null LockOwnerID:-1
> >>> LockOwnerName:null
> >>>
> >>> WaitedCount:5397 WaitedTime:0 InNative:false IsSuspended:false at
> >>> org.apache.tomcat.jni.Poll.poll(Poll.java:-2)
> >>>
> >>> at
> >>>
> >org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1547)
> >>>
> >>> at java.lang.Thread.run(Thread.java:748)
> >>>
> >>>
> >>> These are coming after 2-3 successful jvm dump. Is this something
> >>> familiar to anybody?
> >>>
> >>> Thanks,
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: tomcat thread incurring CPU load

[M. Manna]

Just to give an update again:

1) We reverted the APR to 1.2.21 - but observed no difference.
2) We took 3 thread dumps over 1 min interval (without any user sessions) -
All threads are tomcat's internal pool threads.

When we checked the thread details (using fasthread.io) - we didn't see any
of our application stack. Since there is no user traffic, this is coming
from tomcat internally. At this stage, we cannot really figure out what's
the root cause.

Any help is appreciated.

Thanks,

On Mon, 11 Nov 2019 at 20:57, M. Manna  wrote:

> Hello All,
>
> Any thoughts regarding this? Slightly clueless at this point, so any
> direction will be appreciated.
>
> We are seeing the poll taking all the CPU time. We are using
> OperatingSystemMXBean.getProcessCpuLoad() and
> OperatingSystemMXBean.getSystemCpuLoad() to get our metrics (then x100 to
> get the pct).
>
> Thanks,
>
>
> On Mon, 11 Nov 2019 at 17:46, M. Manna  wrote:
>
>> Hello,
>>
>> after migrating to 8.5.45, we are seeing a lot of cpu load by following
>> JVM thread dump:
>>
>> "https-openssl-apr-0.0.0.0-8443-Poller" : 102 : RUNNABLE :
>> cpu=172902703125000 : cpuLoad= 74.181015
>>
>> BlockedCount:8464 BlockedTime:0 LockName:null LockOwnerID:-1
>> LockOwnerName:null
>>
>> WaitedCount:5397 WaitedTime:0 InNative:false IsSuspended:false at
>> org.apache.tomcat.jni.Poll.poll(Poll.java:-2)
>>
>> at
>> org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1547)
>>
>> at java.lang.Thread.run(Thread.java:748)
>>
>>
>> These are coming after 2-3 successful jvm dump. Is this something
>> familiar to anybody?
>>
>> Thanks,
>>
>

Re: tomcat thread incurring CPU load

[M. Manna]

Hello All,

Any thoughts regarding this? Slightly clueless at this point, so any
direction will be appreciated.

We are seeing the poll taking all the CPU time. We are using
OperatingSystemMXBean.getProcessCpuLoad() and
OperatingSystemMXBean.getSystemCpuLoad() to get our metrics (then x100 to
get the pct).

Thanks,


On Mon, 11 Nov 2019 at 17:46, M. Manna  wrote:

> Hello,
>
> after migrating to 8.5.45, we are seeing a lot of cpu load by following
> JVM thread dump:
>
> "https-openssl-apr-0.0.0.0-8443-Poller" : 102 : RUNNABLE :
> cpu=172902703125000 : cpuLoad= 74.181015
>
> BlockedCount:8464 BlockedTime:0 LockName:null LockOwnerID:-1
> LockOwnerName:null
>
> WaitedCount:5397 WaitedTime:0 InNative:false IsSuspended:false at
> org.apache.tomcat.jni.Poll.poll(Poll.java:-2)
>
> at
> org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1547)
>
> at java.lang.Thread.run(Thread.java:748)
>
>
> These are coming after 2-3 successful jvm dump. Is this something familiar
> to anybody?
>
> Thanks,
>

tomcat thread incurring CPU load

[M. Manna]

Hello,

after migrating to 8.5.45, we are seeing a lot of cpu load by following JVM
thread dump:

"https-openssl-apr-0.0.0.0-8443-Poller" : 102 : RUNNABLE :
cpu=172902703125000 : cpuLoad= 74.181015

BlockedCount:8464 BlockedTime:0 LockName:null LockOwnerID:-1
LockOwnerName:null

WaitedCount:5397 WaitedTime:0 InNative:false IsSuspended:false at
org.apache.tomcat.jni.Poll.poll(Poll.java:-2)

at
org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1547)

at java.lang.Thread.run(Thread.java:748)


These are coming after 2-3 successful jvm dump. Is this something familiar
to anybody?

Thanks,

Re: SameSite cookies

[M. Manna]

Hey Chris,

Interesting question.

samesite attribute is also to protect cookies from possible cross-site
attacks. Even if you have super domain cookies, using strict/lax shouldn't
make any difference for you, or does it?

Thanks,

On Fri, 8 Nov 2019 at 15:04, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I'm looking at using "samesite" cookies within my application. It
> looks as simple as setting the "sameSite" attribute appropriately on
> the CookieProcessor for the , which isn't there in a default
> configuration. So you just have to add it:
>
> 
>
>
>
> 
>
> Cool, now my JSESSIONID cookies are coming back with the SameSite=Lax
> parameter.
>
> But it also applies to all the other cookies my application creates.
> It looks like there is no way to set/reset this parameter on an
> individual-cookie basis. That would require a change to the Servlet
> API, right?
>
> I'm okay with SameSite being applied to ALL my cookies, but maybe not
> everybody is. Are there any workarounds for this?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3Fg/kACgkQHPApP6U8
> pFjfYg/+LSQ1WHvr/Ds7yskd3C7AFF5jBZaNPO4+I3M+5urpQqvy0Gk2use136rA
> rEoct2iTauj2PY9oIplMUqFuaeiOiO5e0VE5//jp7FhnBe4yRxI0mUGzkvX/d/3j
> e37Hm257iiteJ7q19b0uCTd867ZD2dyxupZYHaNQpeviiV+kyGwsv9KupHeIDpyk
> E2AvZ/lIsRQ6tJ0jkNWiHBlpNgXVhIdabJ9WJHFbaqQ4oHPhcKZaMvthoDFnUKGS
> JpyZjmP9TbNjIWE2I2zhwkKC4lTsiHkpeyccR/UC1V4SQs63rUxpGRCGjQ/Jk4p9
> o6nCfI9zJuH3nsAV/sGasXuoPwzDpszsZT8Q8feun9jmfLz6aHynDR2b65Xq1dwc
> OjPX/5QSk6TrlgXQ0jnqlfIhWp1A9e8OF2HUEKW1XgmNFu5CWlsUSYdHlsMBNEF2
> gaciDa1IvYDnfmawJPgXxSUu6csBboiqRsr4RvCcjCSm4mERkcIm8UsYUHJG+c7Z
> IhWc3pszJ5e/IV/w1iVZK34JL+qZcTImR9gThViNJnECW7Y7E5xbYBTOqxkjUUFR
> 6AUvtaW9vMZe1ArsZKKWdpb1f/DjK70KeQsyVcK8zhYbQb8uSI818vo6LV7andpU
> bfifGiSSWuT1ZHdwMOaCrIf++ew1xc45yPb4qsZqTQ95jkuHhng=
> =QbXx
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Intermittent JSP Caching/Compiling Issue while under load

[M. Manna]

I’m just trying to understand, is there really a plausible solution here ?
Unless we have loadbalanced tomcat instances, can we truly ever stop such
behaviour (or more importantly, does it make sense to do so)?

For my use case, We do it in production almost every other day for
patching, but we do it on our 60 servers over a duration of 15-20 minutes
(and by rolling 1-by-1). That said, this may not be an acceptable
delay/solution for others. Also, if it happens to be a critical piece
(index.jsp or something more client-faces), you may not be able to wait
that long.

It’s be good to know what others think.

Regards,


On Mon, 4 Nov 2019 at 22:55, Alex O'Ree  wrote:

> Sounds a lot like the issue I reported a few months ago
>
> On Mon, Nov 4, 2019, 3:12 PM Tim K  wrote:
>
> > On Mon, Nov 4, 2019, 10:30 AM Mark Thomas  wrote:
> >
> > >
> > > Thanks. That helps as it means the issue should be reproducible on a
> > > single, stand-alone instance.
> > >
> > > Mark
> > >
> >
> > I was able to reproduce this behavior with a single server running a
> > vanilla 9.0.21 using the example hello.jsp file...  I was hitting the url
> > every 0.5 seconds.
> >
> > >
> >
>

Re: SameSite Cookie Setup Not Working

[M. Manna]

Apologies, but got this resolved. the httpOly attribute was missing from
one of the apps. I have now set it globally for all my apps.

Thanks,

On Tue, 22 Oct 2019 at 15:34, M. Manna  wrote:

> Hello,
>
> As per the official documentation, I setup my same site cookie using
> Rfc62665CookieProcessor and set everything in "strict" mode.
>
> However, when I restarted my server, I only see httpOnly, secure - but not
> SameSite checked under browser's developer console.
>
> Could someone please help me understand whether something has been missed
> at my side? And yes, I am using tomcat 8.5.45 (as I read that it's been
> since 8.5.42). Otherwise, cataina bootstrapping would simply say that
> there's no samesitecookies attribute.
>
> Regards,
>

SameSite Cookie Setup Not Working

[M. Manna]

Hello,

As per the official documentation, I setup my same site cookie using
Rfc62665CookieProcessor and set everything in "strict" mode.

However, when I restarted my server, I only see httpOnly, secure - but not
SameSite checked under browser's developer console.

Could someone please help me understand whether something has been missed
at my side? And yes, I am using tomcat 8.5.45 (as I read that it's been
since 8.5.42). Otherwise, cataina bootstrapping would simply say that
there's no samesitecookies attribute.

Regards,

Re: Session Size Calculation Question

[M. Manna]

Amazing! That's what I love about Tomcat :)

Thank you Luis.

On Sun, 20 Oct 2019 at 12:21, Luis Rodríguez Fernández 
wrote:

> Hello M.Manna,
>
> Yes, probably SESSIONS.ser can give you an idea. Maybe if you want to get
> more accurate results perhaps you can
>
> 1. Do it yourself via JMX [1]
> 2. Give a try to psi-probe [2], it seems that it has everything that you
> need
>
> Hope it helps,
>
> Luis
>
> [1]
>
> https://stackoverflow.com/questions/19827650/java-monitor-active-web-sessions
> [2]
>
> https://cwiki.apache.org/confluence/display/tomcat/AddOns#AddOns-WebApplications
>
>
>
>
>
>
> El sáb., 19 oct. 2019 a las 2:51, M. Manna ()
> escribió:
>
> > Hello,
> >
> > We are trying to do some calculation for our user session size (or near
> > estimate of it).
> >
> > What we understand is that upon a "Graceful" shutdown, Catalina Host will
> > write out the serializable values of all session into a SESSIONS.ser file
> > in the main servlet's work directory. If this is correct, then the size
> of
> > the the SESSIONS.ser file (assuming 1 user has logged in) would probably
> > (and approximately) equal to a user's session size?
> >
> > We do understand that not all the info in the serializable session may
> not
> > be required. However, given that StandardManager does the privileged load
> > based on reading the entire SESSIONS.ser file, we thought it would be a
> > more appropriate way of calculating the session size.
> >
> > Any guidance or help is appreciated, and apologies for making any
> incorrect
> > assumption.
> >
> > Thanks,
> >
>
>
> --
>
> "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
>
> - Samuel Beckett
>

Session Size Calculation Question

[M. Manna]

Hello,

We are trying to do some calculation for our user session size (or near
estimate of it).

What we understand is that upon a "Graceful" shutdown, Catalina Host will
write out the serializable values of all session into a SESSIONS.ser file
in the main servlet's work directory. If this is correct, then the size of
the the SESSIONS.ser file (assuming 1 user has logged in) would probably
(and approximately) equal to a user's session size?

We do understand that not all the info in the serializable session may not
be required. However, given that StandardManager does the privileged load
based on reading the entire SESSIONS.ser file, we thought it would be a
more appropriate way of calculating the session size.

Any guidance or help is appreciated, and apologies for making any incorrect
assumption.

Thanks,

Question regarding changelog in 8.5.46

[M. Manna]

Hello,

http://tomcat.apache.org/tomcat-8.5-doc/changelog.html#Tomcat_8.5.46_(markt)


I am just trying to understand if these changes have any impact on 8.5.45
with CPU usage. It seems to be some potential NPE and (HTTP/2 only) hanging
issues.

We are seeing some CPU spikes with 8.5.45 and these changes don't seem to
be directly responsible for fixing the issues. So, just trying to eliminate
the need for jumping to another upgrade.

Sorry again for any unintentional spam.

Thanks,

Re: 8.5.46 and 9.0.26 Downloads

[M. Manna]

Hi,

As MarkT mentioned, have you actually checked the Virus Total score against
50+ vendors ? Is your virus scanner listed on virus total?

Thanks,

On Fri, 20 Sep 2019 at 22:20,  wrote:

> I am also getting the same thing with the other mirrors.
>
>
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Asst Vice President
>
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
>
> 8080 Cobblestone Rd | Urbandale, IA 50322
> 
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
>
> jonmcalexan...@wellsfargo.com
>
>
> This message may contain confidential and/or privileged information. If
> you are not the addressee or authorized to receive this for the addressee,
> you must not use, copy, disclose, or take any action based on this message
> or any information herein. If you have received this message in error,
> please advise the sender immediately by reply e-mail and delete this
> message. Thank you for your cooperation.
>
>
> -Original Message-
> From: jonmcalexan...@wellsfargo.com.INVALID
> 
> Sent: Friday, September 20, 2019 4:18 PM
> To: users@tomcat.apache.org
> Subject: RE: 8.5.46 and 9.0.26 Downloads
>
> Getting this from https://www-eu.apache.org/dist/ and
> https://www-us.apache.org/dist/
>
> Tar.gz, 32 bit windows zip and 64 bit windows zip.
>
> Wells Fargo Logo Virus was detected in the content (virus_detected)
> Content contained "Predictive Analysis blocked file" virus The virus was
> blocked and was not downloaded to your system.
>
> Details
> Score: ; File: /data/bluecoat/avenger/tmp/icap[0].tmp; Engine version:
> 5.0.1.79; Pattern version: 20190920.019; For further assistance, visit the
> Web Proxy help page or contact your network support team.
>
>
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Asst Vice President
>
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
>
> 8080 Cobblestone Rd | Urbandale, IA 50322
> 
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
>
> jonmcalexan...@wellsfargo.com
>
>
> This message may contain confidential and/or privileged information. If
> you are not the addressee or authorized to receive this for the addressee,
> you must not use, copy, disclose, or take any action based on this message
> or any information herein. If you have received this message in error,
> please advise the sender immediately by reply e-mail and delete this
> message. Thank you for your cooperation.
>
>
> -Original Message-
> From: Mark Thomas 
> Sent: Friday, September 20, 2019 3:45 PM
> To: users@tomcat.apache.org
> Subject: Re: 8.5.46 and 9.0.26 Downloads
>
> On 20/09/2019 20:56, Mark Thomas wrote:
> > On September 20, 2019 3:44:34 PM UTC, jonmcalexan...@wellsfargo.com.INVALID
> wrote:
> >> Is anyone else having troubles downloading from tomcat.apache.org?
> >> I'm getting virus notifications on the distributions.
> >
> > Which Tomcat files?
> > Which virus checker?
> > Which signature version?
> > Which viruses?
> > Which operating system?
> >
> > Past experience suggests this will be a false positive. Meanwhile, until
> we have some hard information on the issue, I'll run some additional checks.
>
> Virus total says the 9.0.26 binary distribution is clean.
>
> Windows defender says the VM used to build the distributions is clean.
>
> All the indications are that this is a false positive.
>
> Mark
>
>
>
> >
> > Mark
> >
> >
> >>
> >> Thanks,
> >>
> >>
> >> Dream * Excel * Explore * Inspire
> >> Jon McAlexander
> >> Asst Vice President
> >>
> >> Middleware Product Engineering
> >> Enterprise CIO | Platform Services | Middleware | Infrastructure
> >> Solutions
> >>
> >> 8080 Cobblestone Rd | Urbandale, IA 50322
> >> MAC: F4469-010
> >> Tel 515-988-2508 | Cell 515-988-2508
> >>
> >> jonmcalexan...@wellsfargo.com
> >>
> >>
> >> This message may contain confidential and/or privileged information.
> >> If you are not the addressee or authorized to receive this for the
> >> addressee, you must not use, copy, disclose, or take any action based
> >> on this message or any information herein. If you have received this
> >> message in error, please advise the sender immediately by reply
> >> e-mail and delete this message. Thank you for your cooperation.
> >
> >
> > -
> > 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: Secure Communication Between Tomcat Servers

[M. Manna]

Why not use JWT cookies/tokens? You sign your claims and only you can
validate the claims and ensure that it’s coming from the right place/user.

Thanks,

On Mon, 9 Sep 2019 at 19:26, Michael Duffy  wrote:

> I need to communicate securely between two Tomcat servers running in two
> different environments.  I have control of both servers.
>
> I would like to do this through a simple REST call from Server-B to
> Server-A.
>
> On the server I am communicating to, Server-A, I can easily set up HTTPS
> with a self-signed certificate.  If I import this certificate into the Java
> Keystore on Server-B, I can make a trusted HTTPS Rest call from my Java
> code on Server-B.
>
> Good instructions for doing this can be found here:
>
> https://blog.10pines.com/2017/09/25/how-to-communicate-via-https-between-two-tomcat-servers-using-a-self-signed-certificate/
>
>
> I would also like to add a confirmation that the Rest call to Server-A is
> certainly coming from Server-B and the message has integrity.
>
> My plan is to generate a self-signed certificate on Server-B and  import
> this certificate into the Java Keystore on Server-A.  Then for any REST
> call from Server-B I will first generate an SHA-512 hash of the message and
> sign the hash with the private key associated with the Server-B
> certificate.   When Server-A receives the message, the SHA-512 hash will be
> recalculated and checked for accuracy of the hash (no message tampering).
> I will then check the signature of the Hash against the public key of the
> certificate from Server-B.
>
> For a little bit of extra paranoia I may encrypt the REST message with the
> public key of the certificate from Server-A; for short messages this should
> be fine (no need for Symmetric encryption).
>
> Does this seem like a good plan?
>
> Thx in advance for any suggestions.
>
> Mike
>

Re: Release Schedule

[M. Manna]

Release is roughly every 30-40 days. I guess markt can confirm that. He’s
the release manager.

You can see the release logs for the past 2-3 releases to see how
frequently they’ve been coming out.


Regards,

On Wed, 14 Aug 2019 at 19:39, Bush, Clinton R (CGI Federal) <
clinton.b...@cgifederal.com> wrote:

> I have searched your website, wiki, and the web, in general, to locate a
> release schedule or roadmap for Tomcat. Does the Apache Tomcat community
> have a future release schedule?
>
> Working with the government, we must anticipate (loosely) when we will
> need to update servers, APIs, etc. to satisfy cybersecurity requirements.
> As part of that, I am trying to gather release schedules for the software
> we use.
>
> Thanks!
>
> Clinton R. Bush
>
> Senior Software Developer
> CGI Federal, Inc.
> (229)889-6551
> (229)308-2820
> clinton.b...@cgifederal.com
>
> Proprietary/confidential information belonging to CGI Federal Inc. or its
> affiliates may be contained in this message. If you are not a recipient
> indicated or intended in this message (or responsible for the delivery of
> this message to such person), or if you think for any reason that this
> message may have been addressed to you in error, you may not use or copy or
> deliver this message to anyone else. In such case, you should destroy this
> message and are asked to notify the sender by reply email.
>

Re: confusions with conf/tomcat-users.xml setup

[M. Manna]

I would recommend reading the role settings from here first:

https://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html

Also, if everything is okay for you try using comma-separated roles e.g.
roles=“manager-gui,admin”. Even better, try to create new roles and assign
them correctly.

See if that works for you.

Thanks,


On Thu, 25 Jul 2019 at 12:35, Hu, Zhiliang [AN S]  wrote:

> I have Apache Tomcat/7.0.94 installed and running.  However I had a hard
> time to get to the ManagerApp and Host Manager to work properly.  Briefly:
>
> If I set up "conf/tomcat-users.xml" as in:
> 
> 
> 
> 
> -- The "/manager/html/" can get connected and "/host-manager/html" gets
> "404 Access Denied";
>
> If I set up "conf/tomcat-users.xml" as in:
> 
> 
> 
> 
> -- The "/manager/html/" gets "404 Access Denied" and "/host-manager/html"
> can get connected;
>
> If I set up "conf/tomcat-users.xml" as in:
> 
> 
> 
>
> 
> 
> 
> -- The "/manager/html/" can get connected and "/host-manager/html" gets
> "404 Access Denied" -- obviously the second "rolename" overrides the first
> one.
>
> How can I get both to work?
>
> Thanks in advance,
>
> ZL
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: why is ContextListener.attributeAdded means?

[M. Manna]

Hi Goh,

It’s part of standard tomcat logging for servlet ctx init audit.

Check logging.properties file in your conf/ directory. You should be able
to change the level and tune how much logging is needed.

And btw, it’s an INFO, not ERROR/FATAL/SEVERE.

Thanks,

On Wed, 24 Jul 2019 at 11:42, Karen Goh 
wrote:

> Dear experts,
>
> I need some help again.
>
> I am trying to get a html page out on my browser, I changed my Tomcat
> server as the previous one has some Ant script 'creeping in when I
> downloaded an example'.  However, I do not know why am I receiving an error
> message ?
>
> Background :-
> -
> Netbean IDE
> Windows OS
> Tomcat 9.0.12
> JEE
>
> Error Message :
>
> 24-Jul-2019 10:03:27.271 INFO [main]
> org.apache.catalina.core.ApplicationContext.log ContextListener:
> contextInitialized()
> 24-Jul-2019 10:03:27.271 INFO [main]
> org.apache.catalina.core.ApplicationContext.log SessionListener:
> contextInitialized()
> 24-Jul-2019 10:03:27.292 INFO [main]
> org.apache.catalina.core.ApplicationContext.log ContextListener:
> attributeAdded('StockTicker', 'async.Stockticker@4fa4f485')
>
> Can I know why there is a ContextListner:attributeAdded('StockTicer',
> 'async.Stockticker@4fa4f485') as appeared in the log ?
>
> How do I make it go away so that I can run my webApp ?
>
> Thank you for your help.
> Karen
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Forced session expiry after certain period

[M. Manna]

Hello,

Is it possible to evict all sessions after certain period of time ? This is
not the same as idle session-timeout (web.xml).

We are trying to research into whether there’s an absolute maximum limit
for a session in tomcat. After which _any_ session should be expired.

We are currently using default session manager.

Thanks,

Re: Maximum connections and thread notifications

[M. Manna]

After a few more checks, we have identified a mismatch (our side) where
1.2.18 APR (tcnative-1.dll) was being used instead of 1.2.19 (packaged with
8.5.37.

Usually, we get an error with tomcat startup if the APR version isn't
meeting the minimum version requirements. But for 8.5.37 when started with
*1.2.18*, we didn't get this error.

Could someone confirm whether 1.2.19 was the minimum version requirement
for 8.5.37?

Thanks,

On Fri, 5 Apr 2019 at 01:39, M. Manna  wrote:

> Hello all,
>
> Since yesterday all of our loadbalanced tomcat servers have been refusing
> further connection intermittently. During our internal stress testing,
> we’ve managed to reproduce  the issue where maximum number of
> threads/connections to Catalina were reached for one server, but then the
> rest were loadbalanced to others. Eventually, everyone starts failing
> health checks the Citrix network health monitor on port 80 and 8443.
> Because all of them were eventually running out.
>
> We wanted to pinpoint the time of the first hit observers  with Catalina
> logs to see when max connections are reached or maxThreads are used. Is
> there any log level for Catalina/localhost logs which we can use to see
> this message ? If so which level should we be using ?
>
> Also, we are using 8.5.37 with our own TSL cipher suites etc. this started
> happening only since last few days. We would need to find out whether any
> application threads are doubling up and exhausting the APR connectors
> capacity for max threads/connections by holding them indefinitely.
>
> Any suggestion/help you can give here would be appreciated.
>
> Thanks,
>

Maximum connections and thread notifications

[M. Manna]

Hello all,

Since yesterday all of our loadbalanced tomcat servers have been refusing
further connection intermittently. During our internal stress testing,
we’ve managed to reproduce  the issue where maximum number of
threads/connections to Catalina were reached for one server, but then the
rest were loadbalanced to others. Eventually, everyone starts failing
health checks the Citrix network health monitor on port 80 and 8443.
Because all of them were eventually running out.

We wanted to pinpoint the time of the first hit observers  with Catalina
logs to see when max connections are reached or maxThreads are used. Is
there any log level for Catalina/localhost logs which we can use to see
this message ? If so which level should we be using ?

Also, we are using 8.5.37 with our own TSL cipher suites etc. this started
happening only since last few days. We would need to find out whether any
application threads are doubling up and exhausting the APR connectors
capacity for max threads/connections by holding them indefinitely.

Any suggestion/help you can give here would be appreciated.

Thanks,

APR 1.2.21 with Apache Tomcat 8.5.37

[M. Manna]

Hello,

Is it okay to replace 1.2.19 (packed with Tomcat 8.5.37 Windows 64 bit)
with the newly released version 1.2.21? I know that tomcat checks some
mandatory version compatibility during Bootstrap, but not sure if this is
the only check.

I am referring to the windows download here.

http://mirror.ox.ac.uk/sites/rsync.apache.org/tomcat/tomcat-connectors/native/1.2.21/binaries/tomcat-native-1.2.21-openssl-1.0.2q-win32-bin.zip

Thanks,

Re: Tomcat 9 does not work with Java 11

[M. Manna]

if you are moving away from Java 8, I would recommmend you install java 11
first. Oracle JDK or openJDK doesn’t matter here.

Once you do that, confirm that your JAVA_HOME env var is setup correctly (
google it if you’re not sure). The go ahead with your tomcat installation
(service or standalone). See how it works for you.

Thanks,

On Mon, 26 Nov 2018 at 20:08, Andi Meister
 wrote:

> Tomorrow I will try it on an other machine with no previous Tomcat
> installed.
> But my problem is that I have to get it to run on this machine. What could
> I do? First uninstall all jdks and Tomcats and then install jdk11 and
> newest Tomcat?
>
> Ralf
>
> Am Mo., 26. Nov. 2018, 20:59 hat Andi Meister 
> geschrieben:
>
> > Thank you.
> > Dies this mean that I'm doing anything correctly but it just doesn't work
> > on this machine maybe?
> >
> > Ralf
> >
> >
> > Am Mo., 26. Nov. 2018, 20:32 hat Mark Thomas 
> > geschrieben:
> >
> >> On 26/11/2018 18:51, Andi Meister wrote:
> >> > I guess the JDK that I used is not OpenJDK but Oracle JDK? That's not
> >> the
> >> > same isn't it?
> >>
> >> They aren't identical but the differences aren't in any areas that would
> >> impact this issue. Tomcat works happily with both.
> >>
> >> Mark
> >>
> >>
> >> >
> >> > There is a pre-story to that. Maybe there is the reason?!
> >> > On this server there was installed: JRE 1.6 and Tomcat 7 - running for
> >> > years.
> >> > Now there is an update planned to Java 11 and I have to check if it
> >> runs.
> >> >
> >> > First, I installed the JDK 11 additionally and pointed the
> >> Java-location in
> >> > Tomcat 7 configuration app to the new /bin/server/jvm.dll.
> >> >
> >> > Same error as now.
> >> >
> >> > Then I uninstalled Tomcat 7 and JRE 6. Then installed Tomcat 9.
> >> > Error...
> >> >
> >> > Ralf
> >> >
> >> >
> >> > Am Mo., 26. Nov. 2018 um 18:34 Uhr schrieb Mark Thomas <
> >> ma...@apache.org>:
> >> >
> >> >> Tomcat 9.0.13 windows installer, Open JDK 11.0.1 and Window server
> 2008
> >> >> R2 work first time for me on a clean install.
> >> >>
> >> >> This doesn't look like a Tomcat issue at this point.
> >> >>
> >> >> Mark
> >> >>
> >> >>
> >> >>
> >> >> On 26/11/2018 17:04, Andi Meister wrote:
> >> >>> more detailled:
> >> >>> 9.0.13 Core:
> >> >>>
> >> >>>- zip
> >> >>><
> >> >>
> >>
> https://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.zip
> >> >>>
> >> >>>(pgp
> >> >>><
> >> >>
> >>
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.zip.asc
> >> >>> ,
> >> >>>sha512
> >> >>><
> >> >>
> >>
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.zip.sha512
> >> >>> )
> >> >>>
> >> >>>- tar.gz
> >> >>><
> >> >>
> >>
> https://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.tar.gz
> >> >>>
> >> >>>(pgp
> >> >>><
> >> >>
> >>
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.tar.gz.asc
> >> >>> ,
> >> >>>sha512
> >> >>><
> >> >>
> >>
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.tar.gz.sha512
> >> >>> )
> >> >>>
> >> >>>- 32-bit Windows zip
> >> >>><
> >> >>
> >>
> https://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13-windows-x86.zip
> >> >>>
> >> >>>(pgp
> >> >>><
> >> >>
> >>
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13-windows-x86.zip.asc
> >> >>> ,
> >> >>>sha512
> >> >>><
> >> >>
> >>
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13-windows-x86.zip.sha512
> >> >>> )
> >> >>>
> >> >>>- 64-bit Windows zip
> >> >>><
> >> >>
> >>
> https://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13-windows-x64.zip
> >> >>>
> >> >>>(pgp
> >> >>><
> >> >>
> >>
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13-windows-x64.zip.asc
> >> >>> ,
> >> >>>sha512
> >> >>><
> >> >>
> >>
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13-windows-x64.zip.sha512
> >> >>> )
> >> >>>
> >> >>>- 32-bit/64-bit Windows Service Installer
> >> >>><
> >> >>
> >>
> https://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.exe
> >> >>>
> >> >>>(pgp
> >> >>><
> >> >>
> >>
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.exe.asc
> >> >>> ,
> >> >>>sha512
> >> >>><
> >> >>
> >>
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.exe.sha512
> >> >>> )
> >> >>> this one
> >> >>>
> >> >>>
> >> >>> Am Mo., 26. Nov. 2018 um 18:02 Uhr schrieb Andi Meister <
> >> >>> blackpum...@googlemail.com>:
> >> >>>
> >>  Hi Chris,
> >> 
> >>  this one:
> >>  32-bit/64-bit Windows Service Installer
> >>  <
> >> >>
> >>
> https://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.exe
> >> >>>
> >> 
> >> 

Re: Tomcat 9 does not work with Java 11

[M. Manna]

Tomcat 9 doesn’t use any module that’s restricted by OOB openJDK.

It seems like a path issue to me.



On Mon, 26 Nov 2018 at 17:34, Mark Thomas  wrote:

> Tomcat 9.0.13 windows installer, Open JDK 11.0.1 and Window server 2008
> R2 work first time for me on a clean install.
>
> This doesn't look like a Tomcat issue at this point.
>
> Mark
>
>
>
> On 26/11/2018 17:04, Andi Meister wrote:
> > more detailled:
> > 9.0.13 Core:
> >
> >- zip
> ><
> https://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.zip
> >
> >(pgp
> ><
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.zip.asc
> >,
> >sha512
> ><
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.zip.sha512
> >)
> >
> >- tar.gz
> ><
> https://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.tar.gz
> >
> >(pgp
> ><
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.tar.gz.asc
> >,
> >sha512
> ><
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.tar.gz.sha512
> >)
> >
> >- 32-bit Windows zip
> ><
> https://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13-windows-x86.zip
> >
> >(pgp
> ><
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13-windows-x86.zip.asc
> >,
> >sha512
> ><
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13-windows-x86.zip.sha512
> >)
> >
> >- 64-bit Windows zip
> ><
> https://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13-windows-x64.zip
> >
> >(pgp
> ><
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13-windows-x64.zip.asc
> >,
> >sha512
> ><
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13-windows-x64.zip.sha512
> >)
> >
> >- 32-bit/64-bit Windows Service Installer
> ><
> https://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.exe
> >
> >(pgp
> ><
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.exe.asc
> >,
> >sha512
> ><
> https://www.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.exe.sha512
> >)
> > this one
> >
> >
> > Am Mo., 26. Nov. 2018 um 18:02 Uhr schrieb Andi Meister <
> > blackpum...@googlemail.com>:
> >
> >> Hi Chris,
> >>
> >> this one:
> >> 32-bit/64-bit Windows Service Installer
> >> <
> https://www-us.apache.org/dist/tomcat/tomcat-9/v9.0.13/bin/apache-tomcat-9.0.13.exe
> >
> >>
> >> Ralf
> >>
> >>
> >> Am Mo., 26. Nov. 2018 um 16:52 Uhr schrieb Christopher Schultz <
> >> ch...@christopherschultz.net>:
> >>
> > Ralf,
> >
> > On 11/26/18 10:39, Andi Meister wrote:
> > Hi,
> >
> >
> > I downloaded and installed Java 11 from here:
> >
> >
> https://www.oracle.com/technetwork/java/javase/downloads/jdk11-downloa
> > ds-5066655.html
> > <
> https://www.oracle.com/technetwork/java/javase/downloads/jdk11-downloads-5066655.html
> >
> >
> >
> >
> > Then I downloaded and installed Tomcat 9 Windows service
> > executable.
> >
> >
> > During installation I was asked for the path to JRE.
> >
> > Java 11 does not contain a JRE anymore, so I pointed to the Java 11
> > root directory.
> >
> > The installer was fine with that.
> >
> >
> > But when I finally start Tomcat service, it does NOT run.
> >
> > In commons_deamon.log I see this error message:
> >
> >
> > [2018-11-26 13:36:39] [info]  [ 3732] Running 'Tomcat9' Service...
> >
> > [2018-11-26 13:36:39] [info]  [ 4776] Starting service...
> >
> > [2018-11-26 13:36:39] [error] [ 4776] The specified procedure could
> > not be found.
> >
> > [2018-11-26 13:36:39] [error] [ 4776] Failed creating Java
> > C:\Program Files\Java\jdk-11.0.1\bin\server\jvm.dll
> >
> > [2018-11-26 13:36:39] [error] [ 4776] The specified procedure could
> > not be found.
> >
> > [2018-11-26 13:36:39] [error] [ 4776] ServiceStart returned 1
> >
> > [2018-11-26 13:36:39] [error] [ 4776] The specified procedure could
> > not be found.
> >
> > [2018-11-26 13:36:39] [info]  [ 3732] Run service finished.
> >
> >
> >
> > What can I do to get this run?
> >
> >
> > Operating System:
> >
> > Windows Server 2008 R2
> >
> > Which Tomcat installer package did you download?
> >
> > -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: 

Re: [EXTERNAL] Re: Hostnames with underscores

[M. Manna]

Read the description on RFC 7230 and 3986 - just to be sure. You might be
right after all.



On Fri, 26 Oct 2018 at 18:25, Amit Pande  wrote:

> Yes, I did check the description, but did not find reference to underscore.
>
> From the documentation:
> “The value may be any combination of the following characters: " < > [ \ ]
> ^ ` { | } . “
>
> But I admit that I did not actually verify it and will see if these
> attributes work for underscore too.
>
> Thanks,
> Amit
>
> On Oct 26, 2018, at 12:02 PM, M. Manna  manme...@gmail.com>> wrote:
>
> Have you checked the connector config doc for relaxedPathChars and
> relaxedQueryChars?
>
>
>
> On Fri, 26 Oct 2018 at 18:00, Amit Pande  amit.pa...@veritas.com>> wrote:
>
> Hello all,
>
> Recent Tomcat versions (8.5.32 I think) has made a stricter validation for
> hostnames with underscores in it. (
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62371)
>
> This is understandably for addressing security issues (
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6816) and
> enforcing RFC compliance, in some way.
>
> Our recent upgrade to Tomcat (8.5.34), we observed:
>
> Note: further occurrences of request parsing errors will be logged at
> DEBUG level.
> java.lang.IllegalArgumentException: The character [_] is never valid in a
> domain name.
>at
>
> org.apache.tomcat.util.http.parser.HttpParser$DomainParseState.next(HttpParser.java:946)
>at
>
> org.apache.tomcat.util.http.parser.HttpParser.readHostDomainName(HttpParser.java:842)
>at org.apache.tomcat.util.http.parser.Host.parse(Host.java:66)
>at org.apache.tomcat.util.http.parser.Host.parse(Host.java:40)
>at
> org.apache.coyote.AbstractProcessor.parseHost(AbstractProcessor.java:286)
>at
>
> org.apache.coyote.http11.Http11Processor.prepareRequest(Http11Processor.java:1203)
>at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:776)
>at
>
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
>at
>
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
>at org.apache.tomcat.util.net<http://org.apache.tomcat.util.net>
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
>at org.apache.tomcat.util.net<http://org.apache.tomcat.util.net>
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
>at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>at
>
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>at java.lang.Thread.run(Thread.java:748)
>
>
> The main issue for us now is that, since we ship Tomcat with our product
> (IOW Tomcat runs in customer environments), this will break our product
> functionality if customers have hostnames with underscore. Ideally, they
> should correct the host names (to be RFC compliant) but customers would be
> really averse to change hostname as it might a widespread change in their
> environments.
>
> With Spring also, we ran into same issue but in later releases of Spring
> this was fixed. I
>
> Would it be a good idea to make this strict check configurable so that we
> can continue to cater to our customers without breaking the functionality?
>
> Are there any other alternates to help solve this issue?
>
> Thanks,
> Amit
>
>
>
>
>
>
>

Re: Hostnames with underscores

[M. Manna]

Have you checked the connector config doc for relaxedPathChars and
relaxedQueryChars?



On Fri, 26 Oct 2018 at 18:00, Amit Pande  wrote:

> Hello all,
>
> Recent Tomcat versions (8.5.32 I think) has made a stricter validation for
> hostnames with underscores in it. (
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62371)
>
> This is understandably for addressing security issues (
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6816) and
> enforcing RFC compliance, in some way.
>
> Our recent upgrade to Tomcat (8.5.34), we observed:
>
> Note: further occurrences of request parsing errors will be logged at
> DEBUG level.
> java.lang.IllegalArgumentException: The character [_] is never valid in a
> domain name.
> at
> org.apache.tomcat.util.http.parser.HttpParser$DomainParseState.next(HttpParser.java:946)
> at
> org.apache.tomcat.util.http.parser.HttpParser.readHostDomainName(HttpParser.java:842)
> at org.apache.tomcat.util.http.parser.Host.parse(Host.java:66)
> at org.apache.tomcat.util.http.parser.Host.parse(Host.java:40)
> at
> org.apache.coyote.AbstractProcessor.parseHost(AbstractProcessor.java:286)
> at
> org.apache.coyote.http11.Http11Processor.prepareRequest(Http11Processor.java:1203)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:776)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
> at org.apache.tomcat.util.net
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
> at org.apache.tomcat.util.net
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
>
>
> The main issue for us now is that, since we ship Tomcat with our product
> (IOW Tomcat runs in customer environments), this will break our product
> functionality if customers have hostnames with underscore. Ideally, they
> should correct the host names (to be RFC compliant) but customers would be
> really averse to change hostname as it might a widespread change in their
> environments.
>
> With Spring also, we ran into same issue but in later releases of Spring
> this was fixed. I
>
> Would it be a good idea to make this strict check configurable so that we
> can continue to cater to our customers without breaking the functionality?
>
> Are there any other alternates to help solve this issue?
>
> Thanks,
> Amit
>
>
>
>
>
>

Re: Error Regarding RFC 7230 and RC 3986

[M. Manna]

We already know that the parameter is the issue. Having to change all the
parameter i.e. refactoring code is always the answer.
The question was more about the recommended way of handling this issue
without exposing application to any specific vulnerability. I believe Mark
T has answered this already.

Thanks,


On Thu, 18 Oct 2018 at 14:09, Mark H. Wood  wrote:

> On Thu, Oct 18, 2018 at 11:55:24AM +0100, M. Manna wrote:
> > Thanks a bunch Mark.
> >
> > "The correct fix is to ensure that the user agents are sending
> > specification compliant requests." - Do you mean at browser level ? If
> so,
> > is there any specific browser/update we can use? We've checked a few
> > browsers so far (Firefox, Edge, Chrome) and none of them seem to have
> this
> > option (or we might've missed it).
>
> [snip]
>
> > > > The URI we have for this problem has the following param (did work
> with
> > > > 8.5.28)
> > > >
> > > > defaultMessageType=true=en_US=[key:label.edit]
>
> The browser did not actually *compose* that parameter, did it?
>
> If I had this problem, given only what I know from this thread, I
> would suppose that the page which contained an href having such a
> parameter is the source of the problem.  Some link is improperly
> encoded.
>
> I would say it is debatable whether browsers should be "correcting"
> hrefs which are handed to them by some site.
>
> --
> 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
>

Re: Error Regarding RFC 7230 and RC 3986

[M. Manna]

I understand. We will use the connector patch for now. But thanks again for
sharing your thoughts. And the link to apache Confluence is really helpful!

Thanks,

On Thu, 18 Oct 2018 at 12:12, Mark Thomas  wrote:

> On 18/10/18 11:55, M. Manna wrote:
> > Thanks a bunch Mark.
> >
> > "The correct fix is to ensure that the user agents are sending
> > specification compliant requests." - Do you mean at browser level ? If
> so,
> > is there any specific browser/update we can use? We've checked a few
> > browsers so far (Firefox, Edge, Chrome) and none of them seem to have
> this
> > option (or we might've missed it).
>
> The browsers should fix it but I doubt they will. I've seen at least one
> browser vendor refuse to accept the current behaviour is a bug and claim
> that the browsers are working to their own, different spec.
>
> Investigations show that each browser has slightly different behaviour.
>
> https://cwiki.apache.org/confluence/display/TOMCAT/Encoding+and+URIs
>
> So even if the browsers are following a different spec, they aren't
> implementing that one correctly either.
>
> Sigh.
>
> Mark
>
> >
> > We are using relaxedQueryChars for now - but would like to understand the
> > fix you've proposed above.
> >
> > On Thu, 18 Oct 2018 at 10:39, Mark Thomas  wrote:
> >
> >> On 18/10/18 09:52, M. Manna wrote:
> >>> Hello,
> >>>
> >>> We received in error in our application after we have upgraded to
> 8.5.34
> >>>
> >>> INFO: Error parsing HTTP request header
> >>> Note: further occurrences of HTTP header parsing errors will be logged
> at
> >>> DEBUG level.
> >>> java.lang.IllegalArgumentException: Invalid character found in the
> >> request
> >>> target. The valid characters are defined in RFC 7230 and RFC 3986
> >>>
> >>>
> >>> The URI we have for this problem has the following param (did work with
> >>> 8.5.28)
> >>>
> >>> defaultMessageType=true=en_US=[key:label.edit]
> >>>
> >>> The issue is the action parameter value. Could someone help me
> understand
> >>> the following?
> >>>
> >>> 1) Since the issue didn't happen for 8.5.28 - this means some CVE has
> >>> triggered this change to be in place. I am just trying to confirm if
> this
> >>> is CVE-2016-681 ? If not, could you please let me know which one that
> is?
> >>
> >> The change in request parsing was prompted by CVE-2016-6816. There
> >> wasn't a specific attack that prompted this particular change.
> >> CVE-2016-6816 was caused by not parsing the request line as per the
> >> spec. Therefore, to reduce the risk of future vulnerabilities, we have
> >> been tightening up the parsing of the request line.
> >>
> >>> 2) Apart from refactoring code, is there any recommended corrective
> >> action?
> >>
> >> The correct fix is to ensure that the user agents are sending
> >> specification compliant requests.
> >>
> >> The work-around is to use relaxedPathChars and/or relaxedQueryChars on
> >> the Connector.
> >>
> >> 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
>
>

Re: Error Regarding RFC 7230 and RC 3986

[M. Manna]

Thanks a bunch Mark.

"The correct fix is to ensure that the user agents are sending
specification compliant requests." - Do you mean at browser level ? If so,
is there any specific browser/update we can use? We've checked a few
browsers so far (Firefox, Edge, Chrome) and none of them seem to have this
option (or we might've missed it).

We are using relaxedQueryChars for now - but would like to understand the
fix you've proposed above.

On Thu, 18 Oct 2018 at 10:39, Mark Thomas  wrote:

> On 18/10/18 09:52, M. Manna wrote:
> > Hello,
> >
> > We received in error in our application after we have upgraded to 8.5.34
> >
> > INFO: Error parsing HTTP request header
> > Note: further occurrences of HTTP header parsing errors will be logged at
> > DEBUG level.
> > java.lang.IllegalArgumentException: Invalid character found in the
> request
> > target. The valid characters are defined in RFC 7230 and RFC 3986
> >
> >
> > The URI we have for this problem has the following param (did work with
> > 8.5.28)
> >
> > defaultMessageType=true=en_US=[key:label.edit]
> >
> > The issue is the action parameter value. Could someone help me understand
> > the following?
> >
> > 1) Since the issue didn't happen for 8.5.28 - this means some CVE has
> > triggered this change to be in place. I am just trying to confirm if this
> > is CVE-2016-681 ? If not, could you please let me know which one that is?
>
> The change in request parsing was prompted by CVE-2016-6816. There
> wasn't a specific attack that prompted this particular change.
> CVE-2016-6816 was caused by not parsing the request line as per the
> spec. Therefore, to reduce the risk of future vulnerabilities, we have
> been tightening up the parsing of the request line.
>
> > 2) Apart from refactoring code, is there any recommended corrective
> action?
>
> The correct fix is to ensure that the user agents are sending
> specification compliant requests.
>
> The work-around is to use relaxedPathChars and/or relaxedQueryChars on
> the Connector.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Error Regarding RFC 7230 and RC 3986

[M. Manna]

Hello,

We received in error in our application after we have upgraded to 8.5.34

INFO: Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at
DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request
target. The valid characters are defined in RFC 7230 and RFC 3986


The URI we have for this problem has the following param (did work with
8.5.28)

defaultMessageType=true=en_US=[key:label.edit]

The issue is the action parameter value. Could someone help me understand
the following?

1) Since the issue didn't happen for 8.5.28 - this means some CVE has
triggered this change to be in place. I am just trying to confirm if this
is CVE-2016-681 ? If not, could you please let me know which one that is?

2) Apart from refactoring code, is there any recommended corrective action?

Thanks,

Re: Apache failed to initialize connector

[M. Manna]

it looks like you've bound your port 8009 and 8080 with something else
temporarily during windows startup.It may be some port scanning service or
some firewall/ prevention service is blocking all the ports until some
checks are done. And that is why you have this issue intermittently.

As a verification, you can disable auto startup of tomcat service upon
window start. Upon startup, you can start tomcat manually (repeat it 2-3
times) to confirm that there is no problem.


On Wed, 3 Oct 2018 at 15:57, Gael REYNOARD  wrote:

> Sorry for my previous answer, I did not give enough details.
>
> So, yes Tomcat start automatically when the OS starts and I only installed
> one instance of the Tomcat service.
>
> I thought about this idea of the service that starts twice, but I did not
> see anything in the log (commons-daemon.2018-10-02.log) that would indicate
> several start of the service.
>
> I just checked the Windows events and I only have one Tomcat service run
> every time Windows starts.
> This problem does not seem to happen very often because with 102 Windows
> starts I only had the problem 3 times.
>
> Best regards,
> --
> *  Gaël REYNOARD* - Ingénieur Recherche & Développement
>   Service *Bureau d'étude informatique*
>   44 avenue Victor Meunier - 33530 BASSENS
>   Fixe 05.57.80.80.80 - Fax 05.56.31.61.21 - Poste interne 100 235
>   gael.reyno...@lafon.fr - www.lafon.fr
>
>
> Le mer. 3 oct. 2018 à 16:17, Mark Thomas  a écrit :
>
>> On 03/10/18 14:54, Gael REYNOARD wrote:
>> > Tomcat is installed as a service in Windows with a dependency with the
>> SQL
>> > Server service.
>> >
>> > I can also add when I have this problem, if I manually restart the
>> Tomcat8
>> > service, it restarts correctly.
>>
>> How are you *starting* Tomcat? Manually starting the service?
>> Automatically when the OS starts?
>>
>> Also, what are the contents of the service wrapper logs?
>>
>> It looks like the service is being started twice and failing (as
>> expected) the second time. Or you have two Tomcat services trying to use
>> the same ports. Or ...
>>
>> Mark
>>
>>
>> >
>> > Best regards,
>> > --
>> > *  Gaël REYNOARD* - Ingénieur Recherche & Développement
>> >   Service *Bureau d'étude informatique*
>> >   44 avenue Victor Meunier - 33530 BASSENS
>> >   Fixe 05.57.80.80.80 - Fax 05.56.31.61.21 - Poste interne 100 235
>> >   gael.reyno...@lafon.fr - www.lafon.fr
>> >
>> >
>> > Le mer. 3 oct. 2018 à 15:40, Mark Thomas  a écrit :
>> >
>> >> On 03/10/18 12:28, Gael REYNOARD wrote:
>> >>> Hello everybody,
>> >>>
>> >>> OS : Windows 7 Pro x64
>> >>> Tomcat : 8.5.31
>> >>>
>> >>> On a test bench, I reboot Windows to test one of our C# applications.
>> >>> Sometimes after starting the OS, my Tomcat server fails to initialize
>> >>> because the 8080 or 8009 port would be already used.
>> >>
>> >> How are you starting Tomcat?
>> >>
>> >> Mark
>> >>
>> >>
>> >>> I changed the default port 8080 by  and I had the same error after
>> >>> several reboots of my OS.
>> >>>
>> >>> I check with the NETSTAT -atonb -p TCP command and I have Tomcat that
>> is
>> >>> listening to port 8080 (or ) and port 8009.
>> >>>
>> >>> Attached file catalina log
>> >>>
>> >>> In the log the problem occurred on:
>> >>> - 02-Oct-2018 03:16:41.364 (port 8080 and 8009)
>> >>> NETSTAT Result:
>> >>>
>> >>> TCP 0.0.0.0:8009  0.0.0.0:0 <
>> http://0.0.0.0:0>
>> >>> LISTENING 2640
>> >>> [Tomcat8.exe]
>> >>> TCP 0.0.0.0:8080  0.0.0.0:0 <
>> http://0.0.0.0:0>
>> >>> LISTENING 2640
>> >>> [Tomcat8.exe]
>> >>>
>> >>> - 02-Oct-2018 10:27:16.722 (port 8080)
>> >>> NETSTAT Result:
>> >>>
>> >>> TCP 0.0.0.0:8009  0.0.0.0:0 <
>> http://0.0.0.0:0>
>> >>> LISTENING 2828
>> >>> [Tomcat8.exe]
>> >>> TCP 0.0.0.0:8080  0.0.0.0:0 <
>> http://0.0.0.0:0>
>> >>> LISTENING 2828
>> >>> [Tomcat8.exe]
>> >>>
>> >>> - 02-Oct-2018 12:20:38.289 (port )
>> >>> NETSTAT Result:
>> >>>
>> >>> TCP 0.0.0.0:8009  0.0.0.0:0 <
>> http://0.0.0.0:0>
>> >>> LISTENING 2780
>> >>> [Tomcat8.exe]
>> >>> TCP 0.0.0.0:  0.0.0.0:0 <
>> http://0.0.0.0:0>
>> >>> LISTENING 2780
>> >>> [Tomcat8.exe]
>> >>>
>> >>>
>> >>> Thank you in advance for your help.
>> >>>
>> >>> Best regards,
>> >>>
>> 
>> >>> *  Gaël REYNOARD* - Ingénieur Recherche & Développement
>> >>>   Service *Bureau d'étude informatique*
>> >>>   44 avenue Victor Meunier - 33530 BASSENS
>> >>>   Fixe 05.57.80.80.80 - Fax 05.56.31.61.21 - Poste interne 100 235
>> >>>   gael.reyno...@lafon.fr  -
>> www.lafon.fr
>> >>> 
>> >>>
>> >>>
>> >>>
>> >>> -
>> >>> To unsubscribe, e-mail: 

Tuning parameters in APR/Standard connectors

[M. Manna]

Hello,

We have a some SQL statements (Insert, Update) which comes to a few MBs in
size. We are currently using APR 1.2.16. What we observed that sometimes,
the connection hangs out because of extremely large SQL text blocks being
sent to SQL Server.

Is there any parameter in APR or Standard Connectors that we can tweak to
monitor the performance?

Regards,

Re: Tomcat Vs Windows Versions

[M. Manna]

Is there any specific reason you are after platform versions ?

On Mon, 24 Sep 2018 at 19:03, André Luís Scandolara <
andre.luis.scandol...@gmail.com> wrote:

> Does anyone know the Windows versions supported by Apache Tomcat 7, 8 and
> 9?
>
> I could not find out this information on Apache website.
>
> Thanks
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Possible Discrepancy in ClassLoading order when running in Linux

[M. Manna]

Please ignore my question.

Seems like someone decided to try out a "Special" classloader - didn't have
the information before.

Thanks for responding anyway.

Regards,

On Wed, 29 Aug 2018 at 20:20, M. Manna  wrote:

> Thanks mark. We aren’t using delegation, but even with delegation classes
> directory are looked up first in the order.
>
> Tomcat version 8.5.32.
>
> Thanks,
>
> On Wed, 29 Aug 2018 at 19:31, Mark Thomas  wrote:
>
>> On 29/08/18 19:09, M. Manna wrote:
>> > Hello,
>> >
>> > I am not sure if this is a bug or something specific to our
>> implementation,
>> > so wanted to share that with others. Please forgive my idiocy.
>> >
>> > We took a verbose classloading on Windows and it loaded two classes from
>> > two different locations.
>> >
>> > 1) *SomeUtils*.class from *com.my.package.name <
>> http://com.my.package.name>*
>> > - placed in WEB-INF/classes
>> > 2) *SomeOtherUtils*.class from *com.my.package.name
>> > <http://com.my.package.name>* - placed in myjar.jar in WEB-INF/lib
>> >
>> > In Windows, we can load the SomeUtils.class from the "classes" directory
>> > (correct) and SomeOtherUtils.class from jar (in lib directory, also
>> > correct). The class *SomeUtils *exist in *both **lib *and *classes*.
>> but as
>> > per documentation, webapp loader will load things from classes dir
>> first,
>> > and then lib. And it won't load the same class from *lib *if found in
>> *classes
>> > *first. And it also honours the contract "Child loader must not load
>> same
>> > class loaded by parent". So identical package name isn't a problem.
>> >
>> > When we deployed in Linux, it didn't quite happen. We saw that "lib" was
>> > always looked up first. We understand that SomeUtils.class duplicated in
>> > both lib and classes is not a "Good" practice. But what we don't
>> understand
>> > is why webapp classloader isn't searching classes directory and finding
>> it
>> > first? Is there something fundamentally different when it comes to Linux
>> > e.g. ordering/searching which is out of tomcat's control?
>> >
>> > We don't have the verbose log from Linux yet, but meanwhile any info is
>> > helpful.
>>
>> Tomcat version?
>>
>> WEB-INF/classes should always be searched before WEB-INF/lib by default
>> but there are ways to configure the resources implementation to modify
>> the search order.
>>
>> Mark
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

Re: Possible Discrepancy in ClassLoading order when running in Linux

[M. Manna]

Thanks mark. We aren’t using delegation, but even with delegation classes
directory are looked up first in the order.

Tomcat version 8.5.32.

Thanks,

On Wed, 29 Aug 2018 at 19:31, Mark Thomas  wrote:

> On 29/08/18 19:09, M. Manna wrote:
> > Hello,
> >
> > I am not sure if this is a bug or something specific to our
> implementation,
> > so wanted to share that with others. Please forgive my idiocy.
> >
> > We took a verbose classloading on Windows and it loaded two classes from
> > two different locations.
> >
> > 1) *SomeUtils*.class from *com.my.package.name <
> http://com.my.package.name>*
> > - placed in WEB-INF/classes
> > 2) *SomeOtherUtils*.class from *com.my.package.name
> > <http://com.my.package.name>* - placed in myjar.jar in WEB-INF/lib
> >
> > In Windows, we can load the SomeUtils.class from the "classes" directory
> > (correct) and SomeOtherUtils.class from jar (in lib directory, also
> > correct). The class *SomeUtils *exist in *both **lib *and *classes*. but
> as
> > per documentation, webapp loader will load things from classes dir first,
> > and then lib. And it won't load the same class from *lib *if found in
> *classes
> > *first. And it also honours the contract "Child loader must not load same
> > class loaded by parent". So identical package name isn't a problem.
> >
> > When we deployed in Linux, it didn't quite happen. We saw that "lib" was
> > always looked up first. We understand that SomeUtils.class duplicated in
> > both lib and classes is not a "Good" practice. But what we don't
> understand
> > is why webapp classloader isn't searching classes directory and finding
> it
> > first? Is there something fundamentally different when it comes to Linux
> > e.g. ordering/searching which is out of tomcat's control?
> >
> > We don't have the verbose log from Linux yet, but meanwhile any info is
> > helpful.
>
> Tomcat version?
>
> WEB-INF/classes should always be searched before WEB-INF/lib by default
> but there are ways to configure the resources implementation to modify
> the search order.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Possible Discrepancy in ClassLoading order when running in Linux

[M. Manna]

Hello,

I am not sure if this is a bug or something specific to our implementation,
so wanted to share that with others. Please forgive my idiocy.

We took a verbose classloading on Windows and it loaded two classes from
two different locations.

1) *SomeUtils*.class from *com.my.package.name *
- placed in WEB-INF/classes
2) *SomeOtherUtils*.class from *com.my.package.name
* - placed in myjar.jar in WEB-INF/lib

In Windows, we can load the SomeUtils.class from the "classes" directory
(correct) and SomeOtherUtils.class from jar (in lib directory, also
correct). The class *SomeUtils *exist in *both **lib *and *classes*. but as
per documentation, webapp loader will load things from classes dir first,
and then lib. And it won't load the same class from *lib *if found in *classes
*first. And it also honours the contract "Child loader must not load same
class loaded by parent". So identical package name isn't a problem.

When we deployed in Linux, it didn't quite happen. We saw that "lib" was
always looked up first. We understand that SomeUtils.class duplicated in
both lib and classes is not a "Good" practice. But what we don't understand
is why webapp classloader isn't searching classes directory and finding it
first? Is there something fundamentally different when it comes to Linux
e.g. ordering/searching which is out of tomcat's control?

We don't have the verbose log from Linux yet, but meanwhile any info is
helpful.

Thanks,

Re: Why move to tomcat9 (UNCLASSIFIED)

[M. Manna]

The key benefit is - You get all recent CVE patches which protects your
product more from known vulnerabilities.

You can see a comparison table here -
http://tomcat.apache.org/whichversion.html

I would recommend that you review Servlet, Connector, and Java version
related changes carefully (if you have hard dependency on them). it would
be better to move to 8.5 first in my opinion, but no harm going to 9.x
directly if your product is okay.

Regards,

On Wed, 29 Aug 2018 at 15:52, Lueders, Paul T CIV USARMY NGIC (US) <
paul.t.lueders@mail.mil> wrote:

> CLASSIFICATION: UNCLASSIFIED
>
> I would like to migrate from tomcat 7.0.90 to the latest version of
> tomcat9.  Is there a document that lists the benefits of tomcat9 and the
> differences between tomcat7 and tomcat9
>
> Thanks
> Paul
> CLASSIFICATION: UNCLASSIFIED
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: App fails to completely startup on a Tomcat restart

[M. Manna]

What is your full context.xml file? Also, is there any reason why you have
named your application as ROOT.war?

Regards,

On 9 August 2018 at 15:48, Donald J  wrote:

> We are running a Tomcat application where the login always fails after a
> tomcat restart
> with an error about unable to load the configuration context.
> The app has a context file defined in 
> /usr/share/tomcat/webapps/ROOT/META-INF/context.xml
>
> which contains :
> 
> 
>
> After a Tomcat manager "reload", the application login will always succeed.
> A Tomcat manager app stop/start will also let the login succeed.
> A Tomcat manager undeploy/deploy will also let the login succeed.
> Tomcat version is 7.0.69.
>
> This appears to be an application programming issue to me, but vendor
> seems to be trying
> hard to blame it on our customer configuration.   As example, they are
> saying they did
> not test with a ROOT deployment, so we should not use a ROOT deployment.
>
> catalina log just shows:
>
> Aug 09, 2018 9:26:23 AM org.apache.catalina.startup.HostConfig deployWAR
> INFO: Deployment of web application archive /var/lib/tomcat/webapps/ROOT.war
> has finished in 4,825 ms
> ...
> Aug 09, 2018 9:26:24 AM org.apache.coyote.AbstractProtocol start
> INFO: Starting ProtocolHandler ["http-apr-8443"]
> Aug 09, 2018 9:26:24 AM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 6031 ms
>
> I realize the above is not sufficient info for anyone to identify the
> problem, but
> I am asking if there might be any parameter tweeks in Tomcat that might
> get the
> application to totally start up on a Tomcat restart?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Release Roadmap for H2 2018

[M. Manna]

I simply meant email distribution list - tomcat users.

On 2 August 2018 at 16:15, Christopher Schultz  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> To whom it may concern,
>
> On 8/2/18 7:12 AM, M. Manna wrote:
> > Nice one! Thanks Mark. will keep an eye on the distro.
>
> Which distro? Do you mean a package from an OS package-manager? Which on
> e?
>
> - -chris
>
> > On 2 August 2018 at 12:11, Mark Thomas  wrote:
> >
> >> On 02/08/18 12:01, M. Manna wrote:
> >>> Hello,
> >>>
> >>> Is there any release roadmap or community wiki where release
> >>> plans are currently being published?
> >>>
> >>> We wanted to do an upgrade but wondering if it's better to wait
> >>> as there might be a new release coming for 8.5.x or 9.0.x
> >>
> >> Releases for 8.5.x and 9.0.x are made on a (roughly) monthly
> >> basis.
> >>
> >> Mark
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltjH/UACgkQHPApP6U8
> pFjQ3BAAxwkeyEGS/ZmNh3vbtpPSz5Fgh/nrIf6Ms7RGIJQHlKmeJcrLfqBdkFAH
> OL1HFVug5JZMxiEncka6FYU4jYm8fooXzR0BNS/CpctRqTlACk5vL1l7JMeb7RYl
> i697TAhmvWoFF1AodLVJrBOqXW7MYt7jW68ovqTvGAJttpnArW9TzGGVIXbuDx67
> spP9qQZeN5W+8CslHamL58E/ROHLuxuG/UF6IXbr4hw0GIkncLxPsvuWEZEpiWMf
> jDU9/bTUdTwgggDH4C4SLrU5oIKava9/2dnqLEcQ4o15bBpgpLeD9R4rAVxg6E30
> 2M/V7Abg44IaYQiLTEmSpX5x8NmehqooxAo+8g3POitpC0JzzWOAKCt/q9MeaTOu
> j41rdgtst8xURlh1HhVVB0y1EeRQZmD7YXs5AJx4UIVKuFn3URdV+LleEqfUwHny
> Up3RVLVxH5b8tFTFBBZmcBC2lDL3cXAi3OIuk/vY08wpuMS+BHO0hWZCdXgADE9Q
> LE6oi18ghSPYz1rSNYTNEhV1wcwUh9kNKFbnZWwlah64wCwnw58csL+ZaetVTcdn
> buu0HT+bmoHd+TWnVNfid87kqmECozic4Dreq2OnrZufFMoLW4B9/0qkUA29UMhF
> FAfnRKQtwFC2OKpYGUoppMIjOHI3LmPMedyxA0pMZrLw9waTklQ=
> =D+aa
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Release Roadmap for H2 2018

[M. Manna]

Nice one! Thanks Mark.
will keep an eye on the distro.

On 2 August 2018 at 12:11, Mark Thomas  wrote:

> On 02/08/18 12:01, M. Manna wrote:
> > Hello,
> >
> > Is there any release roadmap or community wiki where release plans are
> > currently being published?
> >
> > We wanted to do an upgrade but wondering if it's better to wait as there
> > might be a new release coming for 8.5.x or 9.0.x
>
> Releases for 8.5.x and 9.0.x are made on a (roughly) monthly basis.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Release Roadmap for H2 2018

[M. Manna]

Hello,

Is there any release roadmap or community wiki where release plans are
currently being published?

We wanted to do an upgrade but wondering if it's better to wait as there
might be a new release coming for 8.5.x or 9.0.x

Regards,

No Official Info on CVE Mitre - CVE-2018-1336

[M. Manna]

Hello,

Does anyone know if this is fully official yet? NIST and CVE Mitre say that
the ticket is reserved, but tomcat website says that this has been fixed in
newer versions.

I was simply looking for an official explanation on how this has been
identified as a problem.

Regards,

Re: Need information

[M. Manna]

This is not relevant to tomcat. you have to read how to configure spring
application environment variables and classpath.
Below are some examples, which you can read and configure yourself.

https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config-application-property-files
https://stackoverflow.com/questions/41461786/how-to-externalize-application-properties-in-tomcat-webserver-for-spring

Thanks,

On Mon, 23 Jul 2018, 21:58 Francesco Viscomi,  wrote:

> Because I need to add a folder (properties) under the tomcat installation
> in order to read the properties in a file with the following annotation
> (using spring)
> @PropertySource("classpath:properties/application.properties");
>
>
>
>
>
> 2018-07-23 22:21 GMT+02:00 M. Manna :
>
> > You should never modify them, unless you know precisely what you're doing
> > it, and why.
> >
> > What ia your reason to modify them? What would you like to do?
> >
> > On Mon, 23 Jul 2018, 20:30 Francesco Viscomi, 
> wrote:
> >
> > > Sir Manna you're right, but at the moment I cannot go through debug;
> > > So if there is an explanation and why i should modify them, it will be
> > very
> > > important to me.
> > >
> > > thanks
> > >
> > > 2018-07-23 18:06 GMT+02:00 M. Manna :
> > >
> > > > http://tomcat.apache.org/tomcat-8.5-doc/class-loader-
> > > > howto.html#Class_Loader_Definitions
> > > >
> > > > Also, you should try and pay attention to Bootstrap.java file and
> debug
> > > > through the execution to understand how it's working.
> > > >
> > > >
> > > > On 23 July 2018 at 17:03, Francesco Viscomi 
> > wrote:
> > > >
> > > > > hi all
> > > > > In catalina.properties i find :
> > > > > common.loaders
> > > > > serverr.loaders
> > > > > shared.loaders
> > > > >
> > > > > And i wasn t able to find out the meaning of that variables, some
> one
> > > can
> > > > > tell to me and if possibile also a link to the documentation in
> wich
> > > > these
> > > > > variable are treated
> > > > >
> > > > >
> > > > > Thanks
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Ing. Viscomi Francesco
> > >
> >
>
>
>
> --
> Ing. Viscomi Francesco
>

Re: Need information

[M. Manna]

You should never modify them, unless you know precisely what you're doing
it, and why.

What ia your reason to modify them? What would you like to do?

On Mon, 23 Jul 2018, 20:30 Francesco Viscomi,  wrote:

> Sir Manna you're right, but at the moment I cannot go through debug;
> So if there is an explanation and why i should modify them, it will be very
> important to me.
>
> thanks
>
> 2018-07-23 18:06 GMT+02:00 M. Manna :
>
> > http://tomcat.apache.org/tomcat-8.5-doc/class-loader-
> > howto.html#Class_Loader_Definitions
> >
> > Also, you should try and pay attention to Bootstrap.java file and debug
> > through the execution to understand how it's working.
> >
> >
> > On 23 July 2018 at 17:03, Francesco Viscomi  wrote:
> >
> > > hi all
> > > In catalina.properties i find :
> > > common.loaders
> > > serverr.loaders
> > > shared.loaders
> > >
> > > And i wasn t able to find out the meaning of that variables, some one
> can
> > > tell to me and if possibile also a link to the documentation in wich
> > these
> > > variable are treated
> > >
> > >
> > > Thanks
> > >
> >
>
>
>
> --
> Ing. Viscomi Francesco
>

Re: Changing Sever.xml without restarting Tomcat 8.5

[M. Manna]

I am not sure if it's possible, and probably for a valid reasons.
Server.xml is the mother of server container config and messing things up
there means your servlet context/listeners etc. may need to be
reconfigured. Without a heavily customised/rewritten version of tomcat
config change listener, you cannot do it.

Also check this - conf/server.xml file cannot be reloaded without
restarting Tomcat.


By all means, confirm this by your research.

On 23 July 2018 at 17:25, Laurie Miller-Cook <
laurie.miller-c...@larmerbrown.com> wrote:

> Hi there,
>
> I have an issue where we have multiple virtual hosts in separate base
> directory's on a single Tomcat installation.  If I need to change something
> within server.xml I need to restart Tomcat which means I need to do this
> within an outage window as it affects all of the Websites, is there a way
> of reloading the server.xml without restarting Tomcat?
>
> As a bit of background we have a wildcard domain, so
> ..com so we have created multiple webapp directories
> with their own Manage and have multiple entries in the server.xml file for
> the different hosts.
>
> What need to be able to do is, for example, is add another host to the xml
> site and get that to take effect automatically without the need to
> restarting Tomcat as this restarts all the other websites and hence gives
> outages to our customers.
>
> Any help would be greatly appreciated.
>
> All the best
>
> Laurie
>

Re: Need information

[M. Manna]

http://tomcat.apache.org/tomcat-8.5-doc/class-loader-howto.html#Class_Loader_Definitions

Also, you should try and pay attention to Bootstrap.java file and debug
through the execution to understand how it's working.


On 23 July 2018 at 17:03, Francesco Viscomi  wrote:

> hi all
> In catalina.properties i find :
> common.loaders
> serverr.loaders
> shared.loaders
>
> And i wasn t able to find out the meaning of that variables, some one can
> tell to me and if possibile also a link to the documentation in wich these
> variable are treated
>
>
> Thanks
>

Re: Getting the Manager app running on localhost.. Please help

[M. Manna]

have you enabled all user roles with passwords?

in CATALINA_HOME/conf/tomcat-users.xml file? Also, don't forget to change
the passwords noted as "" with something "interesting".

By default, it can only run on localhost, and it's configured to listen to
127.0.0.1 via the valve. If you uncomment the user role part and change the
password, you should be able to log in. i was able to start it by doing
above.

Also, when you get 403, pay attention to what user roles you need to have
for certain pages to be visible on localhost.

Regards,

On 12 July 2018 at 16:24, Désilets, Alain 
wrote:

> > Where 132.246.129.58 is my IP address. Note that I tried also with
> “132.0.0.0” and with “^.*$” to no avail.
>
> I should be more precise…
>
> When I try with “^.*$”, I get same behavior as when I didn’t have a
> manager.xml file, ie:
>
>   *   Server Status: works
>   *   Manager: opens page but deploying war causes ‘This site can’t be
> reached’
>   *   Host Manager: ‘403 Access Denied’
>
> And by “132.0.0.0.”, I actually meant “127.0.0.1”. When I try that from
> ‘localhost:8080’, all buttons result in ‘403 Access Denied’. But when I
> access the buttons from “127.0.0.1:8080”, I get the same behavior as above
>
>
> Alain Désilets
> National Research Council of Canada
>

Re: log4j

[M. Manna]

Hi Chris,

How r u planning to use Log4j (or log4j2, which solves a lot of performance
issues for 1.2.x)?

Are you bridging with SLF4J or or using directly?

All log4j configuration are automatically discovered and configured
provided that you have set up your appplication log4j properties file
correctly.

Tomcat doesn't do anything specific to log4j-related setup. There is a
logging properties file in /conf/ which are for JULI logging, as a bare
minimum OOB setup for catalina.

If you can perhaps clarify your use case, others can advise better.

regards,

On 18 May 2018 at 14:49, Cheltenham, Chris 
wrote:

> Hello,
>
>
>
> How do I configure Tomcat 8.5.x to use log4j?
>
>
>
> Is there a good document to follow?
>
>
>
> I am not very familiar with java but it looks like you configure to logs
> to accept java logging for Tomcat.
>
>
>
>
>
> ===
>
> Thank You;
>
> Chris Cheltenham
> Technology Services
> The School District of Philadelphia
>
> Work # 215-400-5025
> Cell # 215-301-6571
>

Re: Jsp pages with scriptlet and javadoc comments loaded in char[]

[M. Manna]

Hi Mark,

Basically, our application has quite a lot of large objects which are
singletons. When we checked the list of char[] objects loaded in the
memory, some of them showed JspServlet related Strings and had commented
code loaded into char[].
we have quite a lot of Strings loaded in memory (using maps) which are
necessary. heap-dump will always report this as a memleak but it's not - So
trying to understand whether we can utilise anything from tomcat side to
remove
I understand it sounds odd, but at that point it appeared to be something
we can just strip out. But from your comments, it doesn't seem to be an
option.

Thanks,

On 2 May 2018 at 10:39, Mark Thomas <ma...@apache.org> wrote:

> On 02/05/18 10:31, M. Manna wrote:
> > Hi All,
> >
> > I had a specific question regarding JSPs loaded in web-application
> > container for jasper to compilation. If I have a JSP page which has
> > scriptlet and javadoc comments/code comments, aren't those loaded into
> the
> > char[] of JSP pages too?
>
> No.
>
> > I understand that Jasper compiles the JSPs but
> > those comments aren't stripped out (apologies if I have missed something
> in
> > source code). I am using tomcat 8.5.28.
>
> Yes, they are. HTML comments (which are essentially template text) are not.
>
> > In other words, by cutting down all javadoc comments/commented code from
> > JSP scriptlets, can I assume some savings will be made in terms of char[]
> > memory size when my servers are very busy? I have about ~3k JSP pages
> with
> > a mixture of nice clean JSPs and really messy scriptlets. And I am trying
> > to find some options to tune GC and see if reducing char[] sizes can help
> > me in any way.
>
> Seems like an odd way to tune GC. What problem are you trying to solve?
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Jsp pages with scriptlet and javadoc comments loaded in char[]

[M. Manna]

Hi All,

I had a specific question regarding JSPs loaded in web-application
container for jasper to compilation. If I have a JSP page which has
scriptlet and javadoc comments/code comments, aren't those loaded into the
char[] of JSP pages too? I understand that Jasper compiles the JSPs but
those comments aren't stripped out (apologies if I have missed something in
source code). I am using tomcat 8.5.28.

In other words, by cutting down all javadoc comments/commented code from
JSP scriptlets, can I assume some savings will be made in terms of char[]
memory size when my servers are very busy? I have about ~3k JSP pages with
a mixture of nice clean JSPs and really messy scriptlets. And I am trying
to find some options to tune GC and see if reducing char[] sizes can help
me in any way.

Regards,

Re: APR/native error on tomcat 8.5.16

[M. Manna]

   | jvm 1| 2018/04/25 05:37:38 | at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799)
INFO   | jvm 1| 2018/04/25 05:37:38 | at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
INFO   | jvm 1| 2018/04/25 05:37:38 | at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
INFO   | jvm 1| 2018/04/25 05:37:38 | at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2298)
INFO   | jvm 1| 2018/04/25 05:37:38 | at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
INFO   | jvm 1| 2018/04/25 05:37:38 | at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
INFO   | jvm 1| 2018/04/25 05:37:38 | at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
INFO   | jvm 1| 2018/04/25 05:37:38 | at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
INFO   | jvm 1| 2018/04/25 05:37:38 | at
java.lang.Thread.run(Thread.java:745)

Please let me know if this helps.

Regards,


On 25 April 2018 at 12:55, Mark Thomas <ma...@apache.org> wrote:

> On 25/04/18 11:18, M. Manna wrote:
> > Hello,
>
> 
>
> > But from the above stack track it seems as though the
> > socket cannot handle the size of the data being transferred.
>
> That is not correct. What you are seeing is an I/O exception as a result
> of the client dropping the connection.
>
> > We did a controlled restart of individual servers to remove any
> possibility
> > for IO contention, but that didn't result into anything better.
> >
> > Has anyone seen this behaviour or remediated it ? Also, will this issue
> > occur with Tomcat 8.5.28 and APR 1.2.16 ?
>
> You should upgrade regardless.
>
> A later version may not log this exception by default but since you did
> not provide the full stack trace, we can't tell.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

APR/native error on tomcat 8.5.16

[M. Manna]

Hello,

We have been getting the error stack on our production servers quite
frequently over the past few days:

java.io.IOException: Unexpected error [730,054] writing data to the
APR/native socket [950,585,024] with wrapper
[org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@c5f5747:950585024].
org.apache.catalina.connector.ClientAbortException:
java.io.IOException: Unexpected error [730,054] writing data to the
APR/native socket [950,585,024] with wrapper
[org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@c5f5747:950585024].
at 
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:356)
at 
org.apache.catalina.connector.OutputBuffer.appendByteArray(OutputBuffer.java:785)
at 
org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:714)
at 
org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:391)
at 
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:369)
at 
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:96)
at asposewobfuscated.?78.?Z(Unknown Source)
at com.aspose.words.Document.save(Unknown Source)


I did some Googling and it turns out to be a intermittent connection
termination/swap issue where user is using mobile device or swapping from
Ethernet to Wi-Fi. But from the above stack track it seems as though the
socket cannot handle the size of the data being transferred.

We did a controlled restart of individual servers to remove any possibility
for IO contention, but that didn't result into anything better.

Has anyone seen this behaviour or remediated it ? Also, will this issue
occur with Tomcat 8.5.28 and APR 1.2.16 ?

Regards,

Re: TCP6

[M. Manna]

In your server.xml add address="0.0.0.0" for connector.

On 18 Mar 2018 1:04 pm, "Loai Abdallatif"  wrote:

> Dear Friends
>
> *root@appserver01:~# netstat -antp*
> I have started  three tomcat instances on one debian server and I got the
> following netstat output:
> how I force the tomcat to bind to tcp instead of tcp6
>
>
> tcp6   0  0 10.160.180.99:8005  :::*
> LISTEN  742/java
> tcp6   0  0 10.160.180.99:8105  :::*
> LISTEN  804/java
> tcp6   0  0 10.160.180.99:8009  :::*
> LISTEN  742/java
> tcp6   0  0 10.160.180.99:8109  :::*
> LISTEN  804/java
> tcp6   0  0 :::111  :::*
> LISTEN  416/rpcbind
> tcp6   0  0 10.160.180.99:8080  :::*
> LISTEN  742/java
> tcp6   0  0 10.160.180.99:8081  :::*
> LISTEN  804/java
> tcp6   0  0 :::22   :::*
> LISTEN  496/sshd
> tcp6   0  0 ::1:25  :::*
> LISTEN  709/exim4
> tcp6   0  0 :::39098:::*
> LISTEN  425/rpc.statd
> tcp6   0  0 10.160.180.99:4000  :::*
> LISTEN  742/java
> tcp6   0  0 10.160.180.99:4001  :::*
> LISTEN  804/java
>

Re: WebApp Caching Broken

[M. Manna]

Kenneth,

As MarkT suggested earlier, there is no such "Cache". If you are using
Tag/Cotext Pooling - it's a separate issue and you need to check tomcat's
documentation to check what options you need/don't need.

"The “-XX:+DisableAttachMechanism” JVM option does not work with Tomcat" -
what do you mean? Did it work before, but doesn't work now? or it has
"Never" worked?  or "Ignored"? Please be precise.

Regards,


On 6 March 2018 at 14:09, Kenneth Taylor 
wrote:

> More troubleshooting revealed that our root context xml had been copied
> from another installation and had a wrong path in it.  However, I don’t
> think this was the problem since it was only a path to a Log4J config.  We
> re-installed Tomcat from scratch and it seems to have resolved it, but this
> is not good.  Why is Tomcat caching webapps?
>
>
>
> Also determined that Tomcat was not shutting down properly.  Our
> installation is deployed as a Windows Service.  Stopping the service did
> not stop Tomcat.  But the Service Console thinks it did stop, so when you
> restart it, another instance of Tomcat starts.  We are using a Java Service
> Wrapper if that makes any difference.
>
>
>
> Also found another problem.  The “-XX:+DisableAttachMechanism” JVM option
> does not work with Tomcat.  This is a security flaw.
>
>
>
> Thanks.
>
> Ken
>
> Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC, or
> the personnel associated with either entity (collectively "*DMB*") and
> attachments, contain *CONFIDENTIAL, PRIVILEGED AND PROPRIETARY *information
> for exclusive use of the addressee individual(s) or entity. Unauthorized
> viewing, copying, disclosure, distribution or use of this e-mail or
> attachments may be subject to legal restriction or sanction. If received in
> error, notify sender immediately by return e-mail and delete original
> message and attachments. Nothing contained in this e-mail or attachments
> shall satisfy the requirements for a writing unless specifically stated.
> Nothing contained herein shall constitute a contract or electronic
> signature under the Electronic Signatures in Global and National Commerce
> Act, any version of the Uniform Electronic Transactions Act or any other
> statute governing electronic transactions. Opinions and statements
> expressed in this e-mail and any attachments are those of the individual
> sender and not necessarily of DMB. DMB does not guarantee this e-mail
> transmission is secured, error or virus-free. Neither DMB nor the sender of
> this e-mail accepts liability for errors or omissions in the contents of
> this e-mail, which arise as a result of e-mail transmission. .
>

Re: jasper ant task classpath

[M. Manna]

You can create an Ant directory variable which gets added to your job and
can be looked up for additional dependency. Check path,fileset from Ant
docs to see how you can add it to ant task




On 26 Feb 2018 9:52 pm, "Mark Thomas"  wrote:

On 26/02/18 20:22, Juan Florez wrote:
> Hello,
>
> I'm trying to precompile the JSPs in a project, and so far I almost got
> it working, but I'm getting this error:
>
> BUILD FAILED
> .../iTrust/build.xml:10: org.apache.jasper.JasperException:
> file:.../iTrust/WebRoot/auth/hcp/editRepresentatives.jsp (line: 123,
> column: 0) Unable to load tag handler class
> "edu.ncsu.csc.itrust.tags.PatientNavigation" for tag "itrust:patientNav"
>
> I'm guessing it is because this project is structured in a weird way.
> This is my ant target:
>
>
>   validateXml="false"
>  uriroot="${webapp.path}/WebRoot"
> webXmlFragment="${webapp.path}/WebRoot/WEB-INF/generated_web.xml"
>  outputDir="${webapp.path}/WEB-INF/src" >
> 
>
>   
>
> I have the compiled classes at "${webapp.path}/build", so if there is a
> way to set the classpath or put the classes in a place where jasper will
> find them, I think it would work. I don't need to run the project, I
> just need the JSPs precompiled to run some static analysis on the code.
>
> Thank you.

It looks like you need the JAR with the external tag library on Jasper's
class path. The jasper task has a class path attribute and I think
you'll need to set this to point to the JAR file(s). It should be
structured the same way you'd specify a class path on the command line.
I don't think is supports Ant's .

Mark


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

Re: problems with tomcat 8.5.5

[M. Manna]

Can you please check the changelog for 8.5.x and see if this was fixed?

Regards,

On Thu, 22 Feb 2018 at 23:11, Lou DeGenaro  wrote:

> From catalina.out, NPE seems bad.  Other log files have NPEs too.  Need a
> never version of tomcat?
>
> Thanks.
>
> Lou.
>
> -
>
> 22-Feb-2018 16:37:28.599 SEVERE [http-nio-8080-exec-29]
> org.apache.coyote.http11.Http11Processor.endRequest Error finishing
> response
>  java.lang.NullPointerException
>
> 22-Feb-2018 16:41:22.340 SEVERE [http-nio-8080-exec-34]
> org.apache.coyote.http11.Http11Processor.service Error processing request
>  java.lang.NullPointerException
>
> 22-Feb-2018 16:41:22.340 SEVERE [http-nio-8080-exec-34]
> org.apache.coyote.http11.Http11Processor.endRequest Error finishing
> response
>  java.lang.NullPointerException
>
> 22-Feb-2018 16:41:22.341 SEVERE [http-nio-8080-exec-33]
> org.apache.coyote.http11.Http11Processor.endRequest Error finishing
> response
>  java.lang.NullPointerException
> at
>
> org.apache.coyote.http11.Http11OutputBuffer.commit(Http11OutputBuffer.java:332)
> at
>
> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1288)
> at
> org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:261)
> at
>
> org.apache.coyote.http11.Http11Processor.endRequest(Http11Processor.java:1457)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:823)
> at
>
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at
>
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:802)
> at
> org.apache.tomcat.util.net
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1410)
> at
> org.apache.tomcat.util.net
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
>
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> 22-Feb-2018 17:45:20.128 SEVERE [http-nio-8080-exec-41]
> org.apache.coyote.http11.Http11Processor.service Error processing request
>  java.lang.NullPointerException
> at
>
> org.apache.coyote.http11.Http11OutputBuffer.commit(Http11OutputBuffer.java:332)
> at
>
> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1288)
> at
> org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:261)
> at org.apache.coyote.Response.action(Response.java:169)
> at org.apache.coyote.Response.sendHeaders(Response.java:351)
> at
> org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:322)
> at
> org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:281)
> at
> org.apache.catalina.connector.Response.finishResponse(Response.java:484)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:379)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:784)
> at
>
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at
>
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:802)
> at
> org.apache.tomcat.util.net
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1410)
> at
> org.apache.tomcat.util.net
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
>
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> 22-Feb-2018 17:45:20.130 SEVERE [http-nio-8080-exec-41]
> org.apache.coyote.http11.Http11Processor.endRequest Error finishing
> response
>  java.lang.NullPointerException
>

Re: Tomcat throwing 404 error after modifying context.xml

[M. Manna]

Have you read what resource definitions mean from -
https://tomcat.apache.org/tomcat-8.5-doc/config/context.html ?

On 22 February 2018 at 08:32, Howlader, Aakash [GTSUS Non-J] <
ahowl...@its.jnj.com> wrote:

> Hello,
>
> The jdbc url  "url="jdbc:postgresql://itsusralsp06829:5432/spectra"
> points to a postgre db in another host.
> We tried to modify the maxActive parameter. The other parameters were left
> untouched.
>
>
> This is what the property was in the original context.xml
>
> >  > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
>  > maxWait="1" username="saevdcep" password="xx"
>  > driverClassName="org.postgresql.Driver"
>  > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
>  >
>  >   > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
>  > maxWait="1" username="saevdcep" password="xxx"
>  > driverClassName="org.postgresql.Driver"
>  > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
>
>
> This is the change we made.
>
> >  > type="javax.sql.DataSource" maxActive="2" maxIdle="30"
>  > maxWait="1" username="saevdcep" password="xx"
>  > driverClassName="org.postgresql.Driver"
>  > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
>  >
>  >   > type="javax.sql.DataSource" maxActive="2" maxIdle="30"
>  > maxWait="1" username="saevdcep" password="xxx"
>  > driverClassName="org.postgresql.Driver"
>  > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
>
>
> Not sure why the jdbc url should change. Could you shed some light on this?
>
>
> -Original Message-
> From: M. Manna [mailto:manme...@gmail.com]
> Sent: Thursday, February 22, 2018 4:09 AM
> To: Tomcat Users List <users@tomcat.apache.org>
> Cc: DL-MD-R <DL-HCSUS-MD-R@its.jnj.com>
> Subject: [EXTERNAL] Re: Tomcat throwing 404 error after modifying
> context.xml
>
> Your jdbc url and context path have changed. Have you updated how and
> where you are requesting it? 404 means Not Found. So your requesting for
> something non-existent.
> Please chill and confirm.
>
> On Wed, 21 Feb 2018 at 22:32, Howlader, Aakash [GTSUS Non-J] <
> ahowl...@its.jnj.com> wrote:
>
> > Hello,
> >
> > We were facing a "pool error timeout waiting for idle object" issue.
> > To replicate that in lower environments and perform tests, we tried to
> > make changes to the contex.xml file located under the conf directory
> > of tomcat.
> > The path is /apps/apache-tomcat-7.0.67/conf/context.xml
> >
> > The properties we were modifying are given below .
> >
> > >  > > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > > maxWait="1" username="saevdcep" password="xx"
> > > driverClassName="org.postgresql.Driver"
> > > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
> > >
> > >  > > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > > maxWait="1" username="saevdcep" password="xxx"
> > > driverClassName="org.postgresql.Driver"
> > > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
> >
> > However, on restarting the tomcat server after making changes to
> > values in these, the application is throwing a 404: Resource not Found
> > error. The tomcat server is up and running but on hitting the
> > application URL, we are getting the 404 error.
> >
> > We even tried restoring the context.xml file to its original values
> > but that did not seem to  make a difference.
> >
> > Can you  please let us know what steps we need to follow in order to
> > be able to make modifications to the file and perform our tests?
> >
> > Best Regards,
> > Aakash
> >
> >
>

Re: Tomcat throwing 404 error after modifying context.xml

[M. Manna]

Your jdbc url and context path have changed. Have you updated how and where
you are requesting it? 404 means Not Found. So your requesting for
something non-existent.
Please chill and confirm.

On Wed, 21 Feb 2018 at 22:32, Howlader, Aakash [GTSUS Non-J] <
ahowl...@its.jnj.com> wrote:

> Hello,
>
> We were facing a "pool error timeout waiting for idle object" issue.
> To replicate that in lower environments and perform tests, we tried to
> make changes to the contex.xml file located under the conf directory of
> tomcat.
> The path is /apps/apache-tomcat-7.0.67/conf/context.xml
>
> The properties we were modifying are given below .
>
> >  > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > maxWait="1" username="saevdcep" password="xx"
> > driverClassName="org.postgresql.Driver"
> > url="jdbc:postgresql://itsusralsp06829:5432/spectra"/>
> >
> >  > type="javax.sql.DataSource" maxActive="50" maxIdle="30"
> > maxWait="1" username="saevdcep" password="xxx"
> > driverClassName="org.postgresql.Driver"
> > url="jdbc:postgresql://itsusralsp06829:5432/evidencesearch"/>
>
> However, on restarting the tomcat server after making changes to values in
> these, the application is throwing a 404: Resource not Found error. The
> tomcat server is up and running but on hitting the application URL, we are
> getting the 404 error.
>
> We even tried restoring the context.xml file to its original values but
> that did not seem to  make a difference.
>
> Can you  please let us know what steps we need to follow in order to be
> able to make modifications to the file and perform our tests?
>
> Best Regards,
> Aakash
>
>

Re: _jspService is exceeding the 65535 bytes limit

[M. Manna]

If this doesn’t cause pain, I would do the following:

1) Replace all in-body  scriptlets and use JSTL core tags in offending
JSPs. Most of the codebloats are caused by using intermediate scriptlets
e.g.

<% if (foo.bar() == jack.jill() ) { %>
// lots of jsp code
<%} else <%{ %>

2) use all your code in a stand-alone java class or lambda
Function/BiFunction. And call that using a single line to do all processing.

3) if you’re using ant for building, you can write a task utilising bcel
library to weigh the precompiled jsp sizes (65536b). But this is just a
recommendation.

I know I am asking for a refactor here. But this will help you a lot with
all the other option provided earlier. From 8.0.39 about 100 jsps in our
application broke because of The size. Just sharing our approach.

And BTW, don’t disable pooling, it won’t help that much.

Regards,

On Wed, 7 Feb 2018 at 22:08, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Jan,
>
> On 2/7/18 3:13 PM, Mark Thomas wrote:
> > On 07/02/18 19:19, Jan Tosovsky wrote:
> >> Dear All,
> >>
> >> I've updated ancient tomcat to 8.0.49 and deployed app now throws
> >> '65535 bytes limit' exception for certain JSPs.
> >>
> >> Following this (older) thread
> >> https://stackoverflow.com/questions/5484253/jspservice-is-exceeding-t
> he-6553
> 
> >>
> >>
> 5-bytes-limit I changed that mappedfile parameter, but it didn't help.
> >>
> >> So I downgraded tomcat to 8.0.30 and it works fine again.
> >>
> >> Should that mappedfile settings fix the issue so my observation
> >> seems to be a regression in recent versions? Nobody complains
> >> this solution doesn't work in that older thread.
> >
> > It will help but it isn't a guaranteed fix. There are other
> > options.
> >
> > You could try compilation with javac.
> >
> > You could also try these settings: trimSpaces - true enablePooling
> > - false
> >
> > Note the disabling pooling may impact performance. It depends on
> > lot on the complexity of the tags.
>
> Also using jsp:include to split pages into separate parts should help.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlp7eM8dHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgyVxAAqa1kWSJKv39DoR84
> mZ+mW13VrNB/ruFdAAW/KF6QNVzSB7k0aFmesCpeX01ABKM1LVa6zK4HJa2Bng1+
> bx5cNM4hZti/jvaIE7sfVRi6vtD15ArQ8gHWtH6Xa8GcC1+tehphyj0Ew6GIK+Xn
> cvGe3V05Jl8gqYQiscJ33Jq9Xuseaslbvd0g6fJhStdB7i1TiDUvecd0TZqN9U2h
> +OqAShvRBZvua/MnYfSF5T5Nl+UW7oSjfuVZWY0dPb7L1e9J4zHtwVP0QDdUzp6V
> V6+CRrwbtKXZPYDmxtX5Vq9TVh6fqXfjiIi46AhQU3Ive5mc3UsuU1et/Mr4dRCu
> x1fEhahrZuoKACCF5kAfJ12Ngbe6EeuXAjocBHzgyK6v9ZqkS+X1x9GNQtYU0bv0
> PONoW4x34mLwtPd56pyAbyw2wkoq9fmM8Wi+3KcYG885bnDUG7Ud5+hop3MiExYe
> J/cvip6CFsgdnJ1/xYcSk4b425ZucX2x2qPEVXOnQXbiJUxGTe7lpTtiwFAbotCI
> SUyACeNoZHt7rovPh65ldt7G9F4LJjSmpaYQp+bLyRU8zuc89Oj514ZvgM2Y276E
> DKEchsjD+fVFbBPCi95/A7RyZkIFubxXgWCrOfxuR0j4btu9cnTi1qhgOdoEZCyA
> 305EWpVOH04uFH6pl/ZAEsJyL4g=
> =CB2q
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: dsn config issues

[M. Manna]

I am not saying you are wrong, i am simply asking of you have tried a
different location.



On 6 Feb 2018 9:11 pm, "Rob Turner" <r...@gvtc.com> wrote:

Sorry, I don’t understand the question.  I’m a noob at tomcat.  I assume
the jar file should load since it’s in the same location as all of the
other jar files.

> On Feb 6, 2018, at 2:57 PM, M. Manna <manme...@gmail.com> wrote:
>
> How r u bootstrapping the application? As installed service or invoking
> main() usimg bootstrap.jar?
>
> Also, I would try loading the jar from -classpath location. Typically, it
> should be placed into WEB-INF/lib folder. But may be you want to try
> loading it from classpath and see how it goes.
>
> Regards,
>
>
>
>
> On 6 Feb 2018 8:46 pm, "Rob Turner" <r...@gvtc.com> wrote:
>
> Yes.  CATAKINA_HOME = /usr/tomcat8.  I don’t see any errors during
> startup.  The only message I see that looks unusual is:
> 'org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was
scanned
> for TLDs yet contained no TLDs.'
>
>> On Feb 6, 2018, at 1:27 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Rob,
>>
>> On 2/6/18 1:28 PM, Rob Turner wrote:
>>> My jdbc jar file is located in /usr/tomcat8/lib.
>>
>> Is CATALINA_HOME == /usr/tomcat8?
>>
>>> I see the same error in my log files as on my web page.  Our
>>> application traps the errors and displays them on the page.  I
>>> tried to remove the error trapping mechanism and now receive the
>>> following when accessing a page containing database access:
>>>
>>> org.apache.jasper.JasperException: An exception occurred processing
>>> JSP page /fbc/../common/client_configuration.inc at line 286
>>>
>>> 283:  throws NoSuchMethodException, InstantiationException, 284:
>>> IllegalAccessException, java.lang.reflect.InvocationTargetException
>>> { 285: return (Exception) e.getClass().getConstructor(new
>>> Class[]{(new String()).getClass()}) 286: .newInstance(new
>>> String[]{additionalMessage + ". " + e.getMessage()}); 287: } 288:
>>> 289:
>>>
>>>
>>> Stacktrace:
>>> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServ
>> letWrapper.java:588)
>>>
>>>
>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
>> va:466)
>>> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:38
>> 5)
>>>
>>>
>> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329)
>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
>>> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>>>
>>>
>> root cause
>>>
>>> javax.servlet.ServletException: javax.naming.NameNotFoundException:
>>> Invalid or unavailable DSN in Fort Bend County. Opening database
>>> connection. Name [jdbc/test] is not bound in this Context. Unable
>>> to find [jdbc].
>>
>>
>> Any errors during startup? Usually, Tomcat would attempt to connect to
>> the database in order to pool at least one connection.
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlp6AaQdHGNocmlzQGNo
>> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh6MA/+P5LR+JTSKQGBkTyb
>> o6haKEV5wpQm1JZiZmlkFniTgi1OBebPnAbXVlBeYjZYrEf8Fn7KgFyKWYxdodI3
>> RH+6AJAfHob8A6hn2DsOcP6c2tOx4Xrz9BYpt235OQlmWiSfwDvBvhq/Ao+8z8s1
>> cCerzeWVzdiiHppv01/tGcbHgEuJPzh++yN6b6guOFM9U4WDPrdifTyKYhyLqOfV
>> fXU00KG6m3t8qyTEBfmMVJao4DXmI02uiwNZebRoWlvJaWrJfdnoj3TY5nI45ptm
>> 4BM0Z7PvAWsmAvZTjA/yNFtyhMHDZejmcpAKHyObJUUgYMKDjR4BJ0rQ7TWE2uXd
>> Xf9Df6znWHDiC2mnhQqy1APiNif8BgGdlW8NbrbN8acvFRIlUdKEO0b+Nhl22lkN
>> xnqJ/1WwogPRI8YVcpXR+3eIESRNDX/sxbY5rraoTJVK53V4OqBAByv0+ZCRVaVI
>> g0TOu9fsS1m47TVTFzHGOQBW6UGmQUdWe9rDn7l0FM/4Q3dlBmW0S7WqOsAKlQOf
>> iB0YwNAQRhPdgnMGk4eYGhxByay2LsCdLvBy18Vj5zp9H7/G5iTYUR/111cxDR69
>> swH+LtOQ1VDzuesRX+YxpBNUAp82pO2t/TeYqDAs+VuYjpjkcSkWXE/M2lSfOhlj
>> kSVnzxNc7aY7VBrXiLR1KXl8VZQ=
>> =7qS/
>> -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


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

Re: dsn config issues

[M. Manna]

 How r u bootstrapping the application? As installed service or invoking
main() usimg bootstrap.jar?

Also, I would try loading the jar from -classpath location. Typically, it
should be placed into WEB-INF/lib folder. But may be you want to try
loading it from classpath and see how it goes.

Regards,




On 6 Feb 2018 8:46 pm, "Rob Turner"  wrote:

Yes.  CATAKINA_HOME = /usr/tomcat8.  I don’t see any errors during
startup.  The only message I see that looks unusual is:
'org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned
for TLDs yet contained no TLDs.'

> On Feb 6, 2018, at 1:27 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Rob,
>
> On 2/6/18 1:28 PM, Rob Turner wrote:
>> My jdbc jar file is located in /usr/tomcat8/lib.
>
> Is CATALINA_HOME == /usr/tomcat8?
>
>> I see the same error in my log files as on my web page.  Our
>> application traps the errors and displays them on the page.  I
>> tried to remove the error trapping mechanism and now receive the
>> following when accessing a page containing database access:
>>
>> org.apache.jasper.JasperException: An exception occurred processing
>> JSP page /fbc/../common/client_configuration.inc at line 286
>>
>> 283:  throws NoSuchMethodException, InstantiationException, 284:
>> IllegalAccessException, java.lang.reflect.InvocationTargetException
>> { 285: return (Exception) e.getClass().getConstructor(new
>> Class[]{(new String()).getClass()}) 286: .newInstance(new
>> String[]{additionalMessage + ". " + e.getMessage()}); 287: } 288:
>> 289:
>>
>>
>> Stacktrace:
>> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServ
> letWrapper.java:588)
>>
>>
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
> va:466)
>> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:38
> 5)
>>
>>
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329)
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
>> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>>
>>
> root cause
>>
>> javax.servlet.ServletException: javax.naming.NameNotFoundException:
>> Invalid or unavailable DSN in Fort Bend County. Opening database
>> connection. Name [jdbc/test] is not bound in this Context. Unable
>> to find [jdbc].
>
>
> Any errors during startup? Usually, Tomcat would attempt to connect to
> the database in order to pool at least one connection.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlp6AaQdHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh6MA/+P5LR+JTSKQGBkTyb
> o6haKEV5wpQm1JZiZmlkFniTgi1OBebPnAbXVlBeYjZYrEf8Fn7KgFyKWYxdodI3
> RH+6AJAfHob8A6hn2DsOcP6c2tOx4Xrz9BYpt235OQlmWiSfwDvBvhq/Ao+8z8s1
> cCerzeWVzdiiHppv01/tGcbHgEuJPzh++yN6b6guOFM9U4WDPrdifTyKYhyLqOfV
> fXU00KG6m3t8qyTEBfmMVJao4DXmI02uiwNZebRoWlvJaWrJfdnoj3TY5nI45ptm
> 4BM0Z7PvAWsmAvZTjA/yNFtyhMHDZejmcpAKHyObJUUgYMKDjR4BJ0rQ7TWE2uXd
> Xf9Df6znWHDiC2mnhQqy1APiNif8BgGdlW8NbrbN8acvFRIlUdKEO0b+Nhl22lkN
> xnqJ/1WwogPRI8YVcpXR+3eIESRNDX/sxbY5rraoTJVK53V4OqBAByv0+ZCRVaVI
> g0TOu9fsS1m47TVTFzHGOQBW6UGmQUdWe9rDn7l0FM/4Q3dlBmW0S7WqOsAKlQOf
> iB0YwNAQRhPdgnMGk4eYGhxByay2LsCdLvBy18Vj5zp9H7/G5iTYUR/111cxDR69
> swH+LtOQ1VDzuesRX+YxpBNUAp82pO2t/TeYqDAs+VuYjpjkcSkWXE/M2lSfOhlj
> kSVnzxNc7aY7VBrXiLR1KXl8VZQ=
> =7qS/
> -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: Tomcat7 with jre 1.7 error during starting

[M. Manna]

And did you try running it with jre7? In other words, all 7 ?

On 26 Jan 2018 18:08, "Rajesh Cherukuri"  wrote:

> HI
>
> we have a existing  running tomcat version 5 running on solaris with out
> any issues ,  recently we have  installed tomcat 7 on the same solaris 10
> server  with no application deployed , and configured java version as
> jre1.6 in setenv.sh  i couldn't start the tomcats after my installation ,
> and below is the error what i get when i start tomcat with java1.7  later i
> tired the to configure the java version as 1.8 , i still get the same error
> but slightly different error but both are failing at "
>
> *org.apache.catalina.util.ExtensionValidator.getManifest(
> ExtensionValidator.java:402)*
> can some one let me know if there are any pre-requisites to run a
> tomcat on 7 on Soalris  10 ,
>
>
>
>
> *With java 1.6*
>
> ib:/opt/CA/SharedComponents/lib/:/opt/CA/DSM/scripts/
> install/:/opt/CA/DSM/caf/lib/:.:/opt/CA/SharedComponents/
> lib:/opt/CA/CAlib:/opt/CA/DSM/caf/lib:/usr/jdk/packages/lib/
> sparc:/usr/local/lib:/usr/lib
> 26-Jan-2018 10:49:52 org.apache.catalina.startup.Catalina load
> SEVERE: Catalina.start
> *org.apache.catalina.LifecycleException: Failed to initialize component
> [StandardServer[8075]]*
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:106)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:638)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:663)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:280)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:459)
> *Caused by: java.lang.ExceptionInInitializerError*
> at
> org.apache.catalina.core.StandardServer.initInternal(
> StandardServer.java:806)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
> ... 8 more
> *Caused by: java.lang.IllegalArgumentException*
> at
> java.util.zip.ZipInputStream.getUTF8String(ZipInputStream.java:303)
> at java.util.zip.ZipInputStream.getFileName(ZipInputStream.
> java:436)
> at java.util.zip.ZipInputStream.readLOC(ZipInputStream.java:255)
> at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.
> java:82)
> at java.util.jar.JarInputStream.(JarInputStream.java:67)
> at java.util.jar.JarInputStream.(JarInputStream.java:44)
> at
> org.apache.catalina.util.ExtensionValidator.getManifest(
> ExtensionValidator.java:402)
> at
> org.apache.catalina.util.ExtensionValidator.addSystemResource(
> ExtensionValidator.java:230)
> at
> org.apache.catalina.util.ExtensionValidator.addFolderList(
> ExtensionValidator.java:440)
> at
> org.apache.catalina.util.ExtensionValidator.(
> ExtensionValidator.java:107)
> ... 10 more
>
>
>
>
>
> *Tomcat configured with Java 1.7 *INFO: The APR based Apache Tomcat Native
> library which allows optimal performance in production environments was not
> found on the java.library.path:
> /lib:/usr/lib:/usr/local/lib:/usr/local/ssl/lib:/usr/share/
> lib:/usr/sadm/lib:/usr/ccs/lib:/usr/openwin/lib:/usr/dt/
> lib:/etc/lib:/swhome/retlogic/solve1ultima/SENTINEL_LM/lib:/
> opt/CA/SharedComponents/lib/:/opt/CA/DSM/scripts/install/:/
> opt/CA/DSM/caf/lib/:.:/opt/CA/SharedComponents/lib:/opt/CA/
> CAlib:/opt/CA/DSM/caf/lib:/usr/jdk/packages/lib/sparcv9:/
> lib/64:/usr/lib/64
> Jan 26, 2018 10:46:23 AM org.apache.catalina.startup.Catalina load
> SEVERE: Catalina.start
> *org.apache.catalina.LifecycleException: Failed to initialize component
> [StandardServer[8075]]*
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:106)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:638)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:663)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:280)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:459)
> *Caused by: java.lang.ExceptionInInitializerError*
> at
> org.apache.catalina.core.StandardServer.initInternal(
> StandardServer.java:806)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
> ... 8 more
> *Caused by: java.lang.IllegalArgumentException: 

Re: White-space encoding issue in 8.5.16

[M. Manna]

Actually, it's the same issue (and even error stack) reported here:

http://tomcat.10.x6.nabble.com/Tomcat-8-5-4-uses-RFC-6265-by-default-which-does-not-appear-to-be-Servlet-3-1-compliant-td5054685.html



On 13 November 2017 at 09:00, Mark Thomas <ma...@apache.org> wrote:

> On 12/11/17 22:25, M. Manna wrote:
> > Hi,
> >
> > We are currently encountering an issue where some of our REST  API calls
> > are failing because of a white-space not being encoded (i.e. %20). This
> has
> > started with 8.5.16 and our previous version didn't have this problem -
> > 8.0.29.
> >
> > Is this something anyone has seen before? I am assuming that it's RFC
> 6265
> > where whitespace is not allowed? But is there any work around?
>
> You are going to need to be more specific about the problem. You need to
> provide enough information for someone else to reproduce the issue and
> investigate it.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

White-space encoding issue in 8.5.16

[M. Manna]

Hi,

We are currently encountering an issue where some of our REST  API calls
are failing because of a white-space not being encoded (i.e. %20). This has
started with 8.5.16 and our previous version didn't have this problem -
8.0.29.

Is this something anyone has seen before? I am assuming that it's RFC 6265
where whitespace is not allowed? But is there any work around?

Kindest Regards,