Post date: 2007-09-20 12:17Hi Thomas,
That seems to be the way to go (jvm/lib/ext). The "old" way, using JavaUserClasses (255 character limit), now have a successor also in "JavaUserClassesExt" (from 6.0.4 and 6.5.1) where you can basically to this:
JavaUserClassesExt=QPJC1,QPJC2,QPJC3,QPJC4,QPJC5,QPJC6,QPJC7,QPJC8,QPJC9
QPJC1=C:\SERVER\651\LOTUS\DOMINO\quickplace.jar
QPJC2=C:\SERVER\651\LOTUS\DOMINO\xercesImpl.jar
QPJC3=C:\SERVER\651\LOTUS\DOMINO\xalan.jar
QPJC4=C:\SERVER\651\LOTUS\DOMINO\xml-apis.jar
QPJC5=C:\SERVER\651\LOTUS\DOMINO\log4j-118compat.jar
QPJC6=C:\SERVER\651\LOTUS\DOMINO\STMtgManagement.jar
QPJC7=C:\SERVER\651\LOTUS\DOMINO\STCore.jar
QPJC8=C:\SERVER\651\LOTUS\DOMINO\ibmjsse.jar
QPJC9=C:\SERVER\651\LOTUS\DOMINO\cs.jar
The 255 char limit still applies for the JavaUserClassesExt, but since the entries can be substituted by variables, this is no longer the same problem.
The classloading mechanism is to blame in your original problem described above. When one attaches "external" code as jar or zip in the agent, the resources never seem to be released. This is due to the fact that the agent, every time it runs, uses the "agent class loader" as opposed to the "system class loader". So by instantiating the driver in the agent, it keeps holding the reference in memory even when the agent quits ( = leaks).
I know that there are tricks one can use to execute the agent inside another "Threadgroup" which is not the same Threadgroup that the agent normally runs inside. This way, you can keep from getting other nasty errors from the JVM
Kind regards
Daniel
|