Community
Participate
Working Groups
http://build.eclipse.org/webtools/committers/wtp-R3.0-M/20090507033519/M-3.0.5-20090507033519/
I loaded up the tomcat plugins and try to run the junit several times and I get inconsistent results. At times it would pass the failed testcases reported by the build but it would failed in other places. At first I was concerned that this regarding the changes that we did for the publishing, but the testcase just failed on the latest build, so that makes me think that it doesn't have anything to do with the publishing changes. Larry can you take a look at it and let me know if this is of a concern?
To provide a quick response, I'm not aware of any changes that would cause this. Since I don't have any 3.0.5 changes planned, I don't have a 3.0.5 development environment I can test with. In the past, tests would spuriously fail because something didn't delete properly, which might be the case here. I'll dig further and see what I can turn up. What hardware and software were you using since you managed to reproduce the failure intermittently?
All of these failures appear to be caused by a BridgedRuntime whose "stub" field is null, resulting in NPEs when calling certain methods. I'm speculating that the creation of the runtime during the test run may have a race condition that could allow this to occur. I'll investigate more tonight, though it might be after the next 3.0.5 build completes. I wouldn't be surprised if it passes this time.
Windows XP on a intel dual core
Thanks for looking at this so quickly Larry, I am lowering the severity of this bug for now and passing the smoke test so that we can declare 3.0.5
I believe there is a vulnerability not likely to happen a normal user speeds, but possible during programmatic testing as shown by these errors. RuntimeManagerImpl.bridge() in wst.common.facet.common.core is called at various times, including once per second by the RuntimeValidationThread. When bridge() creates a runtime for a server, it calls ServerCore.getRuntimes() twice, once via IRuntimeBridge.getExportedRuntimeNames() and again via IRuntimeBridge.bridge(). Since this can occur asynchronously with the creation and deletion of server runtimes, there is the potential to see different sets of server runtimes between the two calls to ServerCore.getRuntimes(). For the particular errors found in this build, I believe the following scenario has to occur. RuntimeManagerImpl.bridge() is called when no bridged runtime for the Tomcat runtime exists yet. The IRuntimeBridge.getExportedRuntimeNames() is called when the Tomcat runtime does exist, but by the time IRuntimeBridge.bridge() is called, that runtime has been deleted and the method returns null which gets used as the Stub. Provided the Tomcat runtime exists again before next RuntimeManagerImpl.bridge() call occurs, then the one with the null Stub will get used, resulting in the NPEs. I was able to simulate this scenario in a debug session using breakpoints and verified that the exact same failures occur. This should be simple to fix. For example, calling RuntimeManager.getRuntimes() before and after the Tomcat runtime deletion that occurs in the test1001Delete test will prevent RuntimeManagerImpl.bridge() from seeing the inconsistent set of Tomcat runtimes the scenario requires. I'll see what I can come up with this weekend and commit something for WTP 3.1. Since I suspect this vulnerability has been around a while, do we bother fixing this in WTP 3.0.5? It would mean bumping the version of the tomcat.core.tests plug-in as well as the jst.server_tests feature.
Further checking in WTP 3.1 shows that the RuntimeManagerImpl.RuntimeValidationThread does not get started during a test run, unlike WTP 3.0 where it's unconditionally started when RuntimeManagerImpl is instantiated. Without the asynchronous execution of RuntimeManagerImpl.bridge() caused by RuntimeValidationThread, it doesn't appear the problem scenario can occur in WTP 3.1 testing. Since the problem is only in WTP 3.0.x and happens rarely, it seems not worth the trouble to fix for WTP 3.0.5, given its late stage of development and that there may not be any WTP 3.0.x development beyond 3.0.5. Thus, I'm updating the title to be a little more specific and marking this as WONTFIX. If others would like to have this fixed for WTP 3.0.5, I have no problem re-opening and applying the necessary changes and version increments.
