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.
FFJ 4.0 - Orion CE #020318_1 jdk1.4.0, linux rh71, gnome1.4, kde 2.1 ======================================== I decided to start filling bugs against the module by result of automated test fauilure. Starting with command History: ============================== attaching the screenshot wich is the clearest evidence of module (might be vcscore?) problem. After initial checkout, in Runtime TAB there is no node representanting just finished Checkout (look at the status line in MainFrame)
Created attachment 5096 [details] screenshot of IDE
CC'ing Adam
i'll take a look at it.
i could not reproduce the problem manually. neither in dev build nor in orion. Therefore I assume it's the problem of the test. Here is what happens with the runtime node.. RequestProcessor.postRequest() is called for addition or update of the new node to the runtime tab structure... one of the explanations ofr the failure might be that the request processor is busy and this task was not yet run. if you want to see the core responsible for the runtime additions please see and debug with your test: updateCommand() in RuntimeSupport class.. pleas enote that this class is common among the different vcs modules.. and showStartCommand() + finishCommand() in JavaCvsRuntimeCommand that are adding/updating the node when the command is being executed. the code is quite straightforward here and I have no clue what might be the problem. There must be some kind of locking between the test framework and the app.. rumtime stuf uses threading and synchronization extensively..
Thanks Milos, asynchroned tasks are the most paintfull problem of automated tests: You wrote the following: >one of the explanations of the failure might be that >the request processor is busy and this task was not yet run. Which invokes a question: Why is the request processor busy? What else is ran at the background? The test goes as straight as it is possible: when the IDE is started it mounts empty JavaCVS FS. (no refresh, or anything else might run on background). Initial checkout is performed and after the output window is closed then goes into RunTime TAB and tries to find the command node. I can't realy imagine what could block the command task in request processor. Well, I set up some short timeout:-( But how long should it be? 1,2 seconds or 1 minute? It's just kind of hacking/amatuer coding (from my side). I need something resonable then prolonging the wainting on the command node... It is potentional performance bug, IMHO. And if it is not for this module, it's problem of other parts of the IDE. But VERIFIING it:-) Adjusting the timeout(say 1000ms), hope, that I won't need to reopen it as a performance bug:-)
on the background can be various things, one that comes to my mind is the java parsing or just refreshing of the filesystem. (which does happen when the command ends.) another thing might be the mounting of the filesystem, the adding of the runtime fs node is also asynchronous. I wonder if that's just the case of the initial checkout.. can you run the automated test with other commands, eg. repeatedly do status or log and see if the items are there? a human acceptable delay is probably the limit.. thus it should not exceed 10 seconds.. maybe even less..
Resolved for 3.4.x or earlier, no new info since then -> closing.