This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When I try to attach the profiler to my running program, the socket cannot connect to it. There is problably different bugs in this issue as I tried several method but none of them worked. My config: C:\Java\Jetty>java -version java version "1.4.2_04" Java(TM) 2 Runtime Environment, Standard Edition build 1.4.2_04-b05) JFluid Client VM 1.4.3 (based on Java HotSpot(TM) VM) (build 1.4.2_04-b05-release, mixed mode) C:\Java\Jetty>java -jar start.jar etc\modgui.xml * First I tried with PID, I've got the following lines: *** JFluid: cannot find the introspect.hotspot file in the JVM startup directory: *** C:\Java\Jetty * Then I tried the -Xrunprofilerinterface argument: C:\Java\Jetty>java -Dorg.xins.server.config=etc\xins.properties -Xrunprofilerinterface:"\"c:\Documents and Settings\anthonyg\.netbeans\4.0\modules\profiler-ea-libs\"",5140 -jar start.jar etc\modgui.xml Error occurred during initialization of VM Could not find -Xrun library: profilerinterface.dll * Then I tried with Ctrl+Break "VM Thread" prio=5 tid=0x009911c8 nid=0x5f4 runnable "VM Periodic Task Thread" prio=10 tid=0x009ab6c0 nid=0x3fc waiting on condition "Suspend Checker Thread" prio=10 tid=0x009429e8 nid=0x400 runnable Compiler thread printing unimplemented. JFluid: current dir is C:\Java\Jetty (Shouldn't I have normally a "waiting for connection" message?) -- I succeeded to have it worked (using Ctrl+Break) a few time last week but it was after multiple tries (and reboot).
I've used "netstat -a" and I haven't any socket listening on port 5140 even after Crtl+Break.
After some investigation, I succeeded to attach it by changing the settings.properties file with Attach_Working_Dir=C\:\\Java\\Jetty as I used JFluid from another directory 1 week ago. But just after the attachment I had: *** JFluid warning: class org.apache.xerces.impl.XMLEntityManager$EntityScanner that should be instrumented is not loaded by target VM *** Requested classloader: java.net.URLClassLoader@15c7850, its class = class ja va.net.URLClassLoader, index = 1, hashcode = 22837328 *** Please report this problem to feedback@profiler.netbeans.org
Then I've removed xercesImpl.jar from my war file and then it worked. SO now I'm happy but I still think that there are some bugs: - Starting from a different directory doesn't work and is not documented. - The -Xrunprofilerinterface does not work. - If xerces is in your classpath, JFluid fails. Hope this help, Anthony
Thank you for your feedback. Some suggestions make sense, e.g. we should indeed print smth. like "waiting for connection" when we do so (the "JFluid: current directory is..." message is printed by the JFluid VM when you press Ctrl+Break in any case, irrespective of the JFluid agent actually starting or not). As for your complaints: > - Starting from a different directory doesn't work and is not > documented. This one I didn't actually quite understand, please provide more details. Just to re-iterate: when you want to attach to the running JVM, you should always give the tool the current value of the profiled JVM's "user.dir" property. > - The -Xrunprofilerinterface does not work. Well, for othe people it works :-) Most likely you forgot to add the directory where profilerinterface.dll is located to your PATH. Please check the documentation - I believe in M3 JFluid release this is specified. > - If xerces is in your classpath, JFluid fails. It's likely not that simple, but, yes, it might be a manifestation of one of the bugs we recently fixed. I will be away next week, so for now I'll just send you a "patch" now - several JAR and DLL files, that you can copy into your NB directory, that will effectively convert your current JFluid installation into the preview of the next version. You can try to use it and let us know how it works for you. Regards, Misha Dmitriev JFluid/NetBeans Profiler Team
1) I didn't see that the working directory should be specify when attching the profiler. This is probably due to the fact that it's not in the documentation and that the screenshots in the documentation doesn't contain the field. 2) Indeed I forget to add library to the PATH variable. 3) Even if Xerces was in my classpath, I was not using it so I removed the jar file to fix this issue. I used JFluid to try to find out memory leaks my API. The problem I had was that I could only see from where the objects remaining in memory were created. What I wanted is "Which object has a reference to which other object?" so I could understand why the object was not garbaged collected. In this case HP JMeter was more useful as they use an agorithm to detect possible memory leaks. When I tried to switch to a custom profiling that I just defined, I had: JFluid: exception when handling command from client: java.io.IOException: JFluid wire protocol error: code does not correspond to command or response. Value -1 JFluid: connection with agent closed
> 1) I didn't see that the working directory should be specify when > attching the profiler. This is probably due to the fact that it's > not in the documentation and that the screenshots in the > documentation doesn't contain the field. Well, it is in the documentation, and you simply can't proceed with attachment without specifying the working directory. > I used JFluid to try to find out memory leaks my API. The problem I > had was that I could only see from where the objects remaining in > memory were created. What I wanted is "Which object has a reference > to which other object?" so I could understand why the object was not > garbaged collected. Yes, this is a known (and frequently requested) missing feature, we plan to implement it in future.
Verification of old issues.
Closing old issues.