Community
Participate
Working Groups
This behaviour has been seen with the Apache java agent. When the agent is invoked through the IAC it launches as per usual, but there is a large delay before any of the root fragments are received from the agent. It appears as though the agent is only receiving the request for its root fragments after some time (approximately 45 seconds). This behaviour was not seen in the previous build. The C IAC agents such as the Perfmon Agent do not show this behaviour, although they tend to return far more data in the root fragments (the Apache agent sends about 450 bytes, whereas the Perfmon Agent is often over 8K) which might indicate some form of buffer flushing issue. When invoking the agent using the RAC, the root counters appear with hardly any delay once the agent is being monitored.
George, please give us detailed description of the steps to reproduce this. Thanks.
Well, as the bug report says, the way to reproduce this is to run an Apache Agent. As the documentation states, the agent requests pages from an Apache / IHS server, querying the inbuilt server-status pages. Enabling the server-status page is a simple process requiring some minor tweaks to a servers httpd.conf. For the sake of simplicity, you can get your web server to serve the attached static page. This will save you having to alter any configuration files. Just drop the ss.htm page into your servers htdocs directory. Try and point a browser at it to see if the server is serving the page. Next... 1) Switch to the Profiling and Logging Perspective 2) Create a new Profile Launch Configuration 3) Create a new Statistical Launch Configuration 4) Select a Local Direct Connection in the Host Tab 5) Select an Apache Agent in the agent's tab 6) Enter the server status URL in the Settings tab under the Apache Server Status URL 7) Click Apply, Profile When the agent appears click the Start Monitoring button. Now, wait for about 45 seconds. In the meantime you can open the agent control view and link the view with the Profiling Monitor. You will notice that an Apache Agent appears in the controls view with *no* child counters. After 45 seconds, the agent receives the request for it's child descriptors, servers the descriptors and they appear in the Control view. There should be no 45 second delay. When running through the RAC, there is no delay, and the agent code is identical.
Created attachment 30305 [details] Sample Server Status Page
George, using 20051117A build, I could not reproduce the problem. The Agent Control View showed all the tree view reasonably quick, not in 45 sec. as you observed. I used the instructions you gave me by puting ss.htm into htdocs directory. Can you verify again? Thanks.
Hendra, I've reproduced this with the TPTP-4.1.0-200511170100B build on my Windows 2000 machine. It still takes a good 45 seconds to return the counters. I ran further tests on a second XP machine and the counters returned quickly (and you are seeing). I am just about to try it on a second 2000 machine to try and reproduce the delay elsewhere.
I've managed to reproduce this on three Windows 2000 boxes. The time taken varies from between 30 to 50 seconds. The behaviour is always the same, and is not dependent on what JRE or parser used.
George, it looks like the problem occurs on Win2000 and not on XP. I suggest that we defer this bugzilla to 4.2 and create a README on this. Please let me know if you have any concern with my suggestion. Thanks
Transfering to 4.2 and will create a README for 4.1.
Ignore Comment #9 It was sent by accident. Sorry
Will take a look in i3.
Moving to TPTP 4.3.
Not containable in 4.3 and retarget to 4.4. Please let me know if you have any concern.
Retarget to future due to resource limitation.
Should be resolved once bug 173330 is implemented.
Not in the official plan but will try and fix in i3.
Fixed through bug 173330
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.
