memory leak using Directory Services 2.3.1 when logging in through LAPI?

JohnL

(Cross posted on the LAPI forum as well)I'm troubleshooting a problem we are having against 9.5 and 9.5.1 Livelink instances which have Directory Services 2.3.1 installed with LDAP authetication enabled (with or without synchronization). We have a LAPI (Java) program that deletes and creates data into the database. I'm noticing that when I run that program against the configs listed above the llserver process grows in memory size and does not release the memory when it's finished. It will continue to do this until ultimately the server becomes unresponsive:- the thread logs indicate there have been errors, and that one of the errors was an attempt to write out a trace file. - the process is still running, but I get a blank html screen- from our program I see errors such as the following:XMLImport failed: [java] [java] ImportErrors = [java] ParserErrors = [java] Status: 108205 [java] Status Msg: Cound not create temp output file [java] Api Msg: [java] Err Msg: [java] java.lang.Exception: XMLImport failed: [java] [java] ImportErrors = [java] ParserErrors = or:[ODBC SQL Server Driver] Memory allocation failureThe following configuration repeatedly work finek:9.2, with DS 2.2.2 installed and configured 9.5, without DS9.5.1 without DS9.5.1 with DS 2.3.1 installed, but without configuration. In an attempt to spot the error indicated in the log file, I tried running builder instead of the llserver.exe and was able to run my program repeatedly without ever hitting the problem. It doesn't seem to matter what I am creating, I've tried varying sizes of data and different object types. Larger sets of data trigger the proble more quickly, but I can run small sets until I hit the memory ceiling (which seems to be between around 270-340M)I've also tried unsuccessfully to recreate the problem outside of lapi, i.e. copying large amounts of data into Livelink using the UI directly.One thing that's interesting is that when we're creating the data, we're not even logging in as an autheticated user, we're logging in as Admin, so I'm surprised that the DS module is even involved in this, but I can uninstall it, not see the memory usage grow, reinstall it and recreate the problem.I've also tried this on different machines, with similar results. Any suggestions? Is there anything in particular we should be doing w/in LAPI as far as logging in and authenticating that may have changes between DS releases? I am using the LAPI 9501 release. For what it's worth our application does not do repeated logins, it logs in once and then creates all the data. Thanks in advance for any assistance. Dawn