I'll try to check what you suggested. sounds like something that maybe shed some light on this issue. Thanks :]
2011/2/23 André Warnier <a...@ice-sa.com> > הילה 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 > >
