Question : Using JProbe in a clustered Weblogic env.

We have set up a new cluster in our QA area and wish to attach JProbe against it to ensure that some memory leaks have been addressed before we deploy to production. However, all of the JProbe documentation shows JProbe being attached to the startWebLogic.sh script and thus being tied to the starting and stopping of the individual application server.

How do we use JProbe in a clustered weblogic env? Do we attach it to the startManagedServers script on the admin server? Do we somehow attach it to each individual clustered server? We are currently trying to query quest for this information but their documentation is certainly lacking in this area. Any help that can be provided would be most appreciated...

thanks.

Answer : Using JProbe in a clustered Weblogic env.

JProbe and a few other JVM behaviour/memory analysis tools work by attaching agents to the server which they need to probe. So, if you need to use JProbe in cluster you would have to attach your JProbe to each individual managed servers. Hence, the procedure to be followed is going to be same for doing so  i.e. in case of manged server you modify you 'startManagedWeblogic' script file, instead of 'startWelogic' script.

So, the chnages that you would need to make to the script for managed server will be same for eg:-

A. set START_CMD="C:\Program Files\JProbe Suite 5.0.1\bin\jplauncher.exe"

B. set JPLFILE=C:\JProbe\MyTest.jpl

C. %START_CMD% -jp_input=%JPLFILE% %JAVA_VM%

Once the server has started with JProbe settings, you can connect your profiler to individual servers and monitor the behaviour.

It is important to understand that each server has it's own instance of JVM for running the applications. And so JProbe gives you the JVM behaviour on each JVMs, which may or maynot be different unless there is something which has a possibility of going wrong while the managed servers communicate - which in my experience would be a rare case.

The possibility of your application leaking on single node is going to be same/equally-high as the possibility of it leaking in a cluster - since it will behave the same on cluster where it will have it's own instance of JVM.

Hope this helps.

-A.