Upgrading Embedded Tomcat 7.x to 10.x

2023-08-30 Thread Matthew Robinson
Please may I have some assistance to upgrade a JAVA Maven project which uses 
embedded Tomcat 7 to use embedded Tomcat 10?
I’m having extreme difficulty determining the appropriate versions of the 
various components such that they play nice together.
I am also planning to upgrade from JAVA 7 to JAVA 9. I’t a general 
modernisation operation.

It is set up as a Maven project and uses Apache CXF and Spring to provide a 
RESTful API, a SOAP Client and minimal Web Server functionality.
All Tomcat configuration is by direct JAVA code - no configuration files - to 
ensure it runs standalone and cannot be interfered with by the user.
There are no database or JNDI requirements in Tomcat, but the product uses a 
SOAP API for data retrieval.

The Versions currently used are:
3.1.1.RELEASE
3.1.7.RELEASE
7.0.70
2.7.14
3.0
1.9.11
3.4
1
1.8.0
2.2
3.1.4
1.0.13
1.7

Has anyone executed a similar upgrade and can help me find the appropriate 
mash-up of componentry and versions?

Thanks!

Re: [EXTERNAL] RE: DataSource Connection pool leak

2023-08-30 Thread Christopher Schultz

Tim,

On 8/29/23 10:33, Scott,Tim wrote:

Hi all,

Thanks for your responses. I think I've found the problem.

My wrapping class which detects the invocation of the close() method to 
decrement its count is no longer decrementing its count because 
method.getDeclaringClass() has changed from java.sql.Connection to 
java.lang.AutoCloseable.

Is it safe to check for either java.sql.Connection or java.lang.AutoCloseable?

.. or should I just check for the "close()" method invocation, based on the 
fact that I'm not wrapping anything (here) that I shouldn't be counting?


That depends upon the point of the whole thing. What, um, is the point 
of the whole thing?


-chris

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



Re: Tomcat 9.0.x on Windows crashing

2023-08-30 Thread Christopher Schultz

Daniel,

On 8/28/23 14:37, Daniel Savard wrote:

Le jeu. 24 août 2023 à 13:06, Christopher Schultz <
ch...@christopherschultz.net> a écrit :


Daniel,

On 8/23/23 13:03, Daniel Savard wrote:

I didn't specify the actual Tomcat version because the problem occurs

under

all versions. We are running a commercial web application and all of

sudden

after a while Tomcat is crashing without issuing any message. It is very
likely due to the application. But the vendor was of no help to solve

this

problem which has existed for a long time. I suspect something like
insufficient memory allocated to the VM or something like that. Is there
anything I can do to gather more information on the root cause of this
issue?

Tomcat is running as a service and is restarted automatically if it
crashes. Again, the problem is very unlikely to be with Tomcat itself,

but

the tuning of the VM.


What kind of environment (e.g. Windows vs UNIX, etc.)? What is running
the service? Are there log files for the service which are different
than usual (e.g. syslog vs catalina.out)?

What are your memory settings, and how much physical RAM do you have?

It's unlikely that the JVM is just disappearing without leaving any
trace. If you are on Linux, maybe you are the victim of oome-killer?
That will show in the syslog with a whole lot of output. Search syslog
for "oom" and you will probably find it right away if that's the cause.

-chris



Hi Chris,

Thanks for the answer.  It is running on Windows and it is running as a
service which is configured to restart if it fails. No different log files
at my knowledge except application logs.

There is 14 GB physical RAM on this server. Initial memory pool is 4 GB and
maximum memory pool is 8 GB.

Well, the only thing I can say is Tomcat is failing at some point and
shutting itself down or being shutdown or killed, I cannot say the JVM
itself gets killed.


Windows... so Linux oome killer isn't a likely cause :)

"Windows Service" could mean a lot of things. Are you using the 
procrun-based service that Tomcat ships with? That should create 
stderr-* and stdout-* files in your logs directory which will be 
completely different than application logs.


Look at catalina.out, stderr/stdout and see if you see anything in there 
around the suspected time of termination.


-chris

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