הילה wrote:
Yes, I've read you other mail about the Jprofiler. I've run the Jprofiler
for a weak until it generated a stuck process on the DB and crashed the
application (even though it ran on the app server, and not the DB server)
I'm not too familiar with Tomcat tweaks and java monitoring, so i'll try to
go over your mail again and see if I can extract from it something that I
can work with :]
I hate to barge in (again?) in what is starting to look like a nice slinging match, but I
think that we have already pretty much established that the memory leak, if any, happens
in the jDTS (?) driver and/or the ntlmauth.dll that it is using, and not in Tomcat code.
If it is in the ntlmauth.dll, I doubt that any Java tool will show anything.
הילה, how exactly are you seeing that the Tomcat process is leaking memory ?
With the MS Task Manager ?
And, where exactly does that ntlmauth.dll come from ?
@Chris :
Apparently, the database being used accepts either plain text authentication, or NTLM
authentication.
And apparently also, the setup is such that in either case, the login to the database is
done using a single user-id, provided "by Tomcat".
One can discuss if this is, in the general scheme of things, an appropriate way in terms
of security of access to the data in the database.
But in the case of plain text authentication, the user-id and password used are stored in
a Tomcat configuration file, in plain text.
In the case of the NTLM authentication, the user-id under which tomcat runs can be easily
discovered, but the password cannot.
So I would think that in that limited sense, using NTLM offers an improvement.
Now of course if at the same time, a bug in the jDTS driver or the ntlmauth.dll causes the
Tomcat process to need more and more memory over time, the advantage is less evident.
To nevertheless make some progress at identifying the culprit, I suggest the following
procedure :
Leave the user-id under which Tomcat itself is running as it is, using the Windows Domain
user. Also leave the database as it is.
But change back the authentication used for the database, to the plain-text
setting.
This way, the jDTS driver will still be there, but it will no longer be using the
additional dll, and will authenticate to the DB with the plain-text user-id and password.
Then check if the Tomcat process is still leaking memory.
If it is not, then you know for sure that the leak is in ntlmauth.dll (or in the jDTS
driver, but only when it using NTLM authentication).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
