Community
Participate
Working Groups
No data in the views. Although the agent has been attached to the JVM (WSADIE5.1) there is no data being collected in the views despite attaching to the views, refreshing, requesting collection of instance data ...etc. Hyades driver: v3_0_M8 JVM: JRE 1.3.1 IBM Windows 32 build cn131-20031021
Please take a look
Did you start monitoring the agent? In order to collect data after attaching to an agent, you need to start monitoring..
Yes, I did start monitoring the agent. Rob Danek was sitting next to me, so talk to him.
When we attach to the WSADIE application, and start monitoring with the server in enabled mode, no data is being collected, the agent says it's monitoring...but doesn't show that it's collecting. As a result the views are empty. As well, running garbage collection or collecting instance data caused the profiled JVM to crash. The workaround, for now ,seems to be to start WSADIE with the server in controlled mode, attach to it..and then start monitoring. WSADIE may be installed fromt http://rolo. I use the 20040319_084
Rob, Can you see if there was a regression in the agent.
This is not a regression between 1.3 and 3.0 since the problem appears in both. In particular, the problem was arising on Kris's machine when he launched using -Xmx2000M. We were able to get data in the views without using server=controlled when we didn't include -Xmx2000M. Furthermore, I've been able to reproduce the problem on my machine using StartStop when -Xmx2000M is set (if I set it to something less, like -Xmx1500M, there's no problem). The problem only seems reproducible when using -Xmx2000M, so I'm downgrading the severity and will continue to investigate as to why this setting has such an undesirable impact. (Kris's application does not require 2000M heap size; he had only set it to this because of the out of memory errors he received doing a heap dump, which is a separate issue.)
Created attachment 9000 [details] RAC log
I was able to reproduce this on my machine. I wasn't doing anything special.. just profiling a simple helloworld app. I wasn't using an -Xm option, and it didn't matter whether I specified controlled or enabled, I never got anything. Rebooting my machine fixed the problem. I found something in the RAC log that may be of interest, however... <SERVER_MSG time="2004:3:29:17:56:9" severity="SEVERE" text="Shared memory allocation failure: -516"/> If you look in the previous attachment for the whole log, you'll see this msg (search for "SEVERE"). It started appearing in the latter part of the log, right about when I started having this trouble. After I rebooted, I tried launching again and it worked, and the message didn't appear in the log (see the end of the log).
added logging message to indicate when the profiler cannot establish a connection with the RAC, and suggested that a possible fix to the problem is for the user to increase memory or reduce the value of dataChannelSize in the serviceconfig.xml. (The problem on Kris's machine, as already discussed in an earlier comment, was because of the -Xmx2000M param, which was causing the shared memory connection between the profiler and the RAC to not be created; reducing the value of the -Xmx parameter and reducing the value of dataChannelSize in serviceconfig.xml both alleviated the problem.) The "fixed" status I'm changing this bug to is "fixed" in the sense that the error is now reported instead of just silently failing. I suspect the version of this problem reported by Curtis has something to do with the excessive memory usage that Curtis observed in bug 57129; I will add a comment to that bug indicating this so that in can be investigated when 57129 is dealt with.
Has the information about the range of numbers for dataChannelSize and -Xmx parameter acceptable by the profiling tooling been documented in the readme or profiling documentation ?
Document the range of numbers for dataChannelSize and -Xmx parameter acceptable by the profiling tooling either in the readme or profiling documentation.
This is now a straight forward readme defect; opened a separate bug for this to eliminate the clutter. *** This bug has been marked as a duplicate of 57786 ***
house keeping
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
