Community
Participate
Working Groups
When continuously importing a log file from 'localhost', the progress dialog hangs. This seems to be due to the progress dialog only terminating when the logging agent has completed parsing the log file, and since the agent is continuously monitoring this results in the progress bar never completing. Attempting to cancel the operation also has no effect, and the workbench must be restarted. This behaviour differs when importing from a host other than 'localhost'. In this situation, a connection to the agent controller is established which in turn launches an agent. Once the agent has been launched, the progress dialog completes, and the events appear as they are parsed. I am testing against the 20041112_1553 3.2 build.
Just to point out, once the progress dialog hangs, the workbench must be manually killed. There is no way of cleanly exiting and restarting the workbench and any user who wishes to continously import a log file will encounter this problem.
I re-imported some log file several times and I was unable to reproduce the problem. Is there a step, that I'm perhaps missing? Is there a log file associated with it, that I can look at?
The problem appears during the invocation of any continuous logging agent importing from localhost. I think it is log file & agent independent. I think the problem is somewhere around line 372 of org.eclipse.hyades.log.ui.internal.wizards.ImportLogWizard The switch on localhost leads to parserLoader.startParsing(); being called, which I assume attempts to parse the entire log file and blocks until the parsing is complete. But since the agent is continuous, it doesnt complete, and so everything ?might? lock here. Attempting to cancel also doesnt work as the OperationCanceledException is only thrown once importing is complete. I could be missing something here...
To test: Change the continuousOperation attribute in org.eclipse.hyades.logging.adapter.config\Apache\access\v1.3.26\regex.adapter to 'true', and maximumIdleTime to something like 20000. An import using this adapter will result in the UI being locked for 20 seconds, and then completing once the agent dies. If the agent is continuous and does not die, then the UI locks.
Alex, please look into this
You can use the loopback ip address 127.0.0.1 to import continuously local log files, it will use the RAC and launch a logging agent.
Yes, a loopback address works, but this surely can barely pass as a workaround. I dont see how a workaround with the user having to kill their workbench process could ever be satisfactory. There is also no mention of this in the documentation. If using a loopback address is a workaround, then their should be no switching on host, and all hosts should be treated as remote - just like the datacollection agents.
If the loopback address is used the monitoring agent can be terminated so there is no need for killing the workbench, or am I mistaken. I agree, localhost imports are broken in the described scenario, in fact at the time the UI was designed, continuosly importing log files was not supported by the GLA, this feature was actually implemented not too long ago, leaving the UI a bit behind. The problem will be documented for this release.
I see. So terminating the logging agent itself should notify the workbench that the agent has completed, and return the UI. Will you be looking at a more permanent solution for 3.3/4.0?
workaround exists and this is a dup of feature 74900 as a long term fix *** This bug has been marked as a duplicate of 74900 ***
Yes, we have a feature nr.74900 that will also address this limitation. To get into more details on the issue discussed, when using loopback a network connection is established so a logging agent is launched, the import wizard is closing and opening the log viewer on the monitored agent. The user is able to refresh the log viewer, the log viewer will be refreshed automatically only when the logging agent finishes, but this doesn't happen in the continuous import scenario. Then the user is able to manually terminate the logging agent once he finished taking the snapshot he wanted to investigate, otherwise he will reach at some point the memory limit as the log records in our EMF model are accumulating and the model is stored only in memory. As we know database serialization of EMF models is not available in Hyades for now.
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.
