Memory Leak in Tomcat

[Hila Valensia]

Hey,

I work in a company which we use Tomcat (5.5.26 and recently we've upgraded it to 6.0.29) to run our application.
The tomcat is running on servers with OS windows 2008 R2 STD.

The problem is-
Until now, we used SQL Authentication for the tomcat service and configuration (user and password for tomcat to access the DB was provided within the xml configuration file, under c:\Program Files\Apache Software Foundation\Tomcat 6.0\conf\catalina\localhost), but! since we changed configuration to use Windows Authentication (the user that runs tomcat is now a domain user with permissions on the DB + removed user and password from xml configuration file), we observed a trend of memory leak, where it comes to attention by the process of tomcat, which is increasing on a daily basis.

do you know why is it happening?
and what can I do to stop the memory leak (other than switching back to SQL authentication).

any suggestions here or via mail ([email protected]) would be highly appreciated.

Thanks
Hila

[Tim Holloway]

Welcome to the JavaRanch, Hila!

When you refer to SQL Authentication and Windows Authentication, are you using Tomcat security Realms or is this some sort of internal application security system?

Tomcat itself has no known memory leakage problems other than the rather infamous and un-subtle PermGenSpace issue that comes from re-deploying apps into a running server. The Realm processors internally are fairly small and simple, so problems like this are rare. Cynic that I am, I'd be more inclined to suspect a leaking DLL from a native code call.

Most memory leaks are due to problems with applications, not Tomcat. Often people don't clean up properly after exceptions, although I spent an entire month finding out (the hard way) that Oracle's definition of cache didn't include the common concept of tossing unused items to keep the cache from growing forever.

[Hila Valensia]

Hey Tim,
Thanks for your reply.

I'm not sure as for "Tomcat security Realms", if you can tell me where it's configured I can check it, but I'm not familiar with it.
I'm refering to the change of the user that runs the tomcat service and accesses the DB, from SQL user to a domain user.

these are the steps I've made for switching from SQL authentication (BTW, we work with SQL server of Microsoft, not Oracle) to Windows authentication.

1. downloading jtds 1.2.5 package, and replacing the jtds-1.2.2.jar file with the file from the package (jtds-1.2.5.jar) in the c:\program files\apache software foundation\tomcat 6.0\lib
2. placing the file "ntlmauth.dll" from the jtds package in c:\windows\system32\
3. removing user and password strings from xml configuration file, under c:\Program Files\Apache Software Foundation\Tomcat 6.0\conf\catalina\localhost
4. changing the user that the tomcat service runs with, from local system to a domain user (with permissions to DB).

do you think the ntlmauth.dll is causing issues?
In the package theres file for 32bit and 64bit, so i made sure to put the right one.

Any other suggestions, as for what can I try to eliminate the leak?


Thanks
Hila

[Tim Holloway]

OK. I was thinking webapp user authentication. You mean how the webapp itself authenticates to the database. So Tomcat Realms wouldn't apply.

I'm out of practice on the quirks of configuring MS SQL Server, but I don't think that you should have had to change anything at all on the Tomcat side. The difference between the two authentication methods is whether the connection is authenticated via user definitions within SQL server or within the Windows security environment (local machine or LAN authentication).

I don't recommend using NTLM authentication for this connection myself. For security purposes, it's better to use a userid/password that is solely for the purposes of database connection and not tied to other system resources.

But as far as setup goes, the jtds driver is a type 4 JDBC driver.. Meaning it's 100% pure Java and contains no DLLs, native-code classes or OS-specific code in it. I can say that confidently, because my webserver's Linux and any Windows-only restrictions would have prevented me from being able to use jtds. The exception is that the SSO option does use a special DLL from JTDS, and SSO does only run under Windows. Other than that, the only difference between a SQL Server authenticated connection and a domain (NTLM) authenticated connection is that you must supply the domain name as part of the connection URL.

[Hila Valensia]

Hey,

I had to change it on Tomcat side, since the user and password of the user that authenticates to the DB (The SQL user) was written in clear text on the xml configuration file under c:\Program Files\Apache Software Foundation\Tomcat 6.0\conf\catalina\localhost.
the authentication works without using ;domain=domainname in the connection URL, so I haven't used it.
the DLL (ntlmauth.dll) under jtds-1.2.5 package is indeed required for the authentication to work.

So.. you don't have any suggestions for me how to eliminate the memory leak?
and if not, is there a way at least to perform an automatic recycle to the tomcat process (without stopping and starting the service)?

Thanks
Hila :]

[Tim Holloway]

In other words, you're using SSO.

I can give no advice on memory leaks, because - unless you can find something in a bug database for Tomcat (unlikely) or jtds, there should be no memory leaks. Not knowing where it's coming from, I can't indicate a remedy. Personally, I consider recycling Tomcat to be a rather brutal solution to the problem, but a lot of people would rather do that than diagnose and solve the problem.

And no, you can't recycle Tomcat without taking the apps down. The apps are inside Tomcat, and when the Tomcat JVM is destroyed and recreated, so are the apps.

My skillset does extend to tracking down memory leaks, whether they're in the webapp, Tomcat, jtds, or even the DLL, but I don't do that kind of work cheap.

[Hila Valensia]

Ok.. Thanks.