I've also just committed an additional fix to this problem, and closed the issue. Here's
some additional info from my comment to the Jira closure:
Actually, the logical error is not located in SensorShell, but in the JUnitSensor. The
basic issue is that JUnit does not record very precise information about the time at
which a test is executed. All we really have to go on is the timestamp at which the Junit
results XML file was created/last modified (which might only be accurate to a second on a
windows platform), as well as the internal "elapsedTime" attribute associated with each
test case, which is often simply "0.0" and thus totally useless. What we need is a way to
associate a unique tstamp with each test case, but also have that tstamp be repeatable,
since one of the design constraints of Hackystat is that if you send the same set of data
to the server twice, the second set should override the first. Thus, we can't simply call
Random.
The solution in the JUnitSensor was to basically hash on the test name. Unfortunately,
there was a bug introduced during a modification to that code that resulted in the hash
being computed on just the test class, not the test class and the test method. This meant
that the same hash was being computed on all of the test cases in a single file.
The sensorshell implemented a simple "one lookback" timestamp tweak which would fix the
problem of when two entries with the exact same timestamp appeared in a row. But it
wouldn't look back any farther than the last timestamp, which is why when the JUnit
sensor sends five or six entries with the same timestamp in a row, only the last two of
them would end up with unique tstamps.
Hongbing's change to SensorShell means that a sequence of the same tstamps will now be
tweaked successfully, but there are other boundary conditions that this approach doesn't
fix. My commit today also fixes the underlying JUnit sensor code so that it computes the
hash based upon the class and method names, which (since each test case must have a
unique method name) should fix this problem at its root.
I want to conclude by noting that these approaches are heuristic, and that it's not
impossible (though quite unlikely) that a particular combination of tstamp and
classname/method names could result in a duplicate timestamp. I'm not sure we'll ever see
this in practice, but I just want to note the possibility.
The only real solution to this problem would be a change to the JUnit XML generator to
provide millisecond accuracy with respect to the start time of each test case. Perhaps we
should request that change from the JUnit implementors.
Cheers,
Philip
--On Friday, September 01, 2006 6:13 PM -1000 Hongbing Kou <[EMAIL PROTECTED]>
wrote:
Hi, Aaron, Austen and Philip,
This message is about the recent bug found by Aaron and Austen. The unit test
sensor data entry missing is caused by a logical error in SensorShell. The code
snippet
below increase timestamp by 1 if it equals to the last value.
long timeStampLong = timeStamp.getTime();
if (timeStampLong == this.lastTimeStamp) {
timeStampLong = this.lastTimeStamp + 1;
timeStamp = new Date(timeStampLong);
}
this.lastTimeStamp = timeStampLong;
Here lastTimeStamp is a field variable that holds last timestamp. There is a
logical
hole in these 5 lines of code. If we have 5 entries in a line with same
timestamp
1157169399580, we will have sequence of 1157169399580, 1157169399581,
1157169399580, 1157169399581, 1157169399580.
I will go ahead to fix it and close the Jira issue.
Have a good weekend!
Hongbing
