Re: How to turn up logging for tomcat-embed-core in SpringBoot
I've managed to find a solution that works. The info I found has me using the "log4j-jul" bridge (and excluding spring-boot-starter-logging from spring-boot-starter-web), which redirects from jul to log4j, which effectively redirects to logback, which allows me to configure loggers in the same place as my other loggers, in the logback.xml file. I haven't yet verified this with the Tomcat startup error I was looking at (that was apparently resolved in some other way), but I've verified that I can see other log messages from StandardContext, so it's pretty likely this will work. On Sat, Apr 19, 2025, 11:49 AM KARR, DAVID wrote: > This is an issue I've tried to pursue multiple times in the past, and each > time I've given up and used an awkward solution that won't work in the > current situation I'm seeing this. I thought perhaps I had asked it here > before, but I don't see it in the archives. > > We have a couple hundred Java SpringBoot services, most of them using > SpringBoot 3.2.5. Internally, it is using Tomcat through the > "tomcat-embed-core" artifact, version 10.1.30. > > Every once in a while, I run into a problem where the service startup > fails with some variation of this: > > WebServerException: Unable to start embedded Tomcat > > The stacktrace provided in this case has no stack entries in application > code. It provides no clue of what actually went wrong. Whenever I run into > this, if I can run the service on my desktop, I set breakpoints in the > StandardContext class wherever it sets "ok" to false. That always leads to > the solution. It almost always points to a conflict with dependencies, but > knowing that fact doesn't help me until I know what the conflict is. > > I really shouldn't have to do this. I can clearly see in the > StandardContext class that it tries to log the exception message (usually a > "MultiException" or something like that). Ideally, I should just be able to > configure the logging for tomcat-embed-core to make it print the exception > details. Several times I have struggled to make this work, and I've never > been able to get it working. Tomcat uses java.util.logging, but it seems to > have some variations that seemingly make it more difficult to configure. > I've tried variations with a "logging.properties" file, but it never seems > to make any difference. I've seen some posts that try to address this, but > I've never found a complete solution for getting this working in a > SpringBoot application. > > In the latest instance, I'm seeing this happen in an environment I can't > run the debugger in, so I have no way to diagnose this. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Best practices to set heap memory
Hello team, How to decide on heap memory size? is it 25% of total memory? or 50% total memory? What is the ideal value (in %) for heap memory ? Regards, Ramesh
Re: Content type unknown after upgrading Tomcat 10.1.39 => 10.1.40
Thorsten,
On 4/17/25 1:54 AM, Thorsten Heit wrote:
Hi Chris,
That definitely sounds odd. Do you have anything on the network
between the client (browser) and the server (Tomcat)? Specifically,
anything like a load-balancer, proxy, or similar?
I just want to remove other possible causes before diving into Tomcat
(but from your description, Tomcat does seem to be the suspicious
component, here).
No, there's nothing in between me and Tomcat. It's reproducible also by
directly using curl on the command line:
"curl -v --insecure --noproxy '*' https://.../"; gives me the following
on 10.1.39 (private data replaced for security):
Note: Using embedded CA bundle (233263 bytes)
Note: Using embedded CA bundle, for proxies (233263 bytes)
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:--
--:--:-- 0* Host myhost.example.com:8448 was resolved.
* IPv6: 2a02:5a0:f019:1:4448:4350:a9b4:9022
* IPv4: 10.192.141.7
* Trying [2a02:5a0:f019:1:4448:4350:a9b4:9022]:8448...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [317 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Unknown (8):
{ [41 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [5210 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [520 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
* subject: ...
* start date: May 6 10:01:48 2024 GMT
* expire date: Dec 26 10:01:48 2048 GMT
* issuer: ...
* SSL certificate verify result: self signed certificate in certificate
chain (19), continuing anyway.
* Certificate level 0: Public key type ? (4096/128 Bits/secBits),
signed using sha256WithRSAEncryption
* Certificate level 1: Public key type ? (4096/128 Bits/secBits),
signed using sha256WithRSAEncryption
* Certificate level 2: Public key type ? (4096/128 Bits/secBits),
signed using sha512WithRSAEncryption
* Connected to myhost.example.com (2a02:5a0:f019:1:4448:4350:a9b4:9022)
port 8448
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://myhost.example.com:8448/my/
servlet/app?version=!!1.22.32-4-g8a3c060!!
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: myhost.example.com:8448]
* [HTTP/2] [1] [:path: /my/servlet/app?version=!!1.22.32-4-g8a3c060!!]
* [HTTP/2] [1] [user-agent: curl/8.12.1]
* [HTTP/2] [1] [accept: */*]
> GET /my/servlet/app?version=!!1.22.32-4-g8a3c060!! HTTP/2
> Host: myhost.example.com:8448
> User-Agent: curl/8.12.1
> Accept: */*
>
* Request completely sent off
0 0 0 0 0 0 0 0 --:--:-- --:--:--
--:--:-- 0< HTTP/2 200
< cache-control: max-age=0
< expires: Wed, 16 Apr 2025 16:22:16 GMT
< content-type: text/html;charset=UTF-8
< content-length: 7999
< date: Wed, 16 Apr 2025 16:22:16 GMT
<
{ [7999 bytes data]
100 7999 100 7999 0 0 31126 0 --:--:-- --:--:-- --:--:--
31246
* Connection #0 to host myhost.example.com left intact
With 10.1.40 using exactly the same command the result is the same apart
from the content-type:
(...)
* Request completely sent off
0 0 0 0 0 0 0 0 --:--:-- --:--:--
--:--:-- 0< HTTP/2 200
< cache-control: max-age=0
< expires: Wed, 16 Apr 2025 16:19:48 GMT
< content-type: content/unknown;charset=UTF-8
< content-length: 7999
< date: Wed, 16 Apr 2025 16:19:48 GMT
<
{ [7999 bytes data]
100 7999 100 7999 0 0 32015 0 --:--:-- --:--:-- --:--:--
32124
This is what's puzzling me...
BTW, I'm using a system-wide Tomcat installation under /usr/local/share
and a user installation with its own ./conf directory; basically the
same what Ubuntu is offering via the packages "tomcat10-common" and
"tomcat10-user".
This way I can switch the Tomcat version to be used by simply changing
the CATALINA_HOME variable in the startup script. But I guess this
shouldn't matter...
Tomcat is never going to figure out what MIME type should be used for a
request like "/my/servlet/app?version=!!1.22.32-4-g8a3c060!!"
So I think Mark is probably right (well, he's right like 99.999% of the
time, so...) about this being related to
https://bz.apache.org/bugzilla/show_bug.cgi?id=69623 but I suspect your
servlet is not explicitly setting a content-type.
I would be expecting Tomcat to set a default content-type of text/html
if the servlet does not explicitly set the type. If that's not
happening, it's a spec violation and we will fix it one way or another.
A quick way to fix this would be to edit the servlet or JSP that
generates this response and explici
Re: Apache Tomcat 12+
Rémy, On 4/17/25 11:47 AM, Rémy Maucherat wrote: On Thu, Apr 17, 2025 at 5:16 PM William Crowell wrote: Hi, A few questions on the future direction of the project. It seems like Project Panama is still in preview mode as of JDK 24. Is that correct? No, it's a stable regular part of Java since Java 22. Availability of the API will become better with the next Java LTS as users become more confident about deploying a JVM that supports the API. > Is there any update on QUIC transport protocol over HTTP/3 support in Tomcat 11? Does it have anything to do with JEP draft 8291976? https://openjdk.org/jeps/8291976 What are the plans for the next major release of Tomcat? The QUIC plans have been on and off. A bit off topic, but this is my favorite thing from the recently-released Java 24: https://openjdk.org/jeps/491 JEP 491: Synchronize Virtual Threads without Pinning This JEP makes using Virtual Threads practical for most web applications. Support for Virtual Threads was added in previous Tomcat versions (that is, earlier than Tomcat 12), but the nature of VTs in the JVM has kind of made them a bit of a flop since there is so much synchronized code out there in the world. Having Java 24 remove pinning of those threads means that every JDBC driver is no longer a boat-anchor on every web application that uses those drivers, and the promise of "simpler code that performs well" that Virtual Threads was meant to deliver is actually, well, deliverable. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9.0.104 Crashing at Startup on RHEL 8.4
Mark, On 4/17/25 4:56 PM, Mark Thomas wrote: On 17/04/2025 20:32, RAY, DAVID wrote: I updated from Tomcat 9.0.102 to 9.0.104 on two RHEL servers. Both are 'crashing' at startup after the update. Version 9.0.102 and prior versions ran fine. No issues. Version 9.0.104 is crashing at startup. Any suggestions much appreciated: That looks a JVM bug. One for your JVM vendor / RedHat depending on where you got it from. No obvious changes on the Tomcat side that might have triggered the bug. There is always the possibility of a hardware fault as well. If you are using a reasonably stable version of Java (like 21 or earlier) then I would guess bad hardware, probably RAM. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
