--On Monday, February 06, 2006 1:12 AM -1000 Aaron Kagawa <[EMAIL PROTECTED]>
wrote:
Hey Guys,
Austen and I have been tackling a very puzzling error that seems to be caused
when
testing hackySensor_XmlData.
The next parts of the email is our debugging quest.... read on if you dare. :)
Wow, what a great story! Much more thrilling than King Kong, which I saw at the 50 cent
theater in Kailua this weekend. :-)
I'm going to cut out much of the story and just respond to a couple of parts.
We see the following error in the Tomcat console:
02/05 21:33:13 Received bad data from: [EMAIL PROTECTED]
java.lang.NullPointerException
Ok.. Not much information to go on and no unit tests are failing.
The lack of better error messaging the Receive method is a definite bummer. I see you've
adding a stacktrace, which is good. I added a couple more in a couple of other places as
well and updated. So hopefully in future people can debug these kinds of situations more
quickly.
1) Unit Test failures after multiple test executions.
Run the following:
ant -q freshStart
ant -q all.junit
ant -q all.junit
Test cases fail for various hackySdt_* modules on the second all.junit.
I think that since the first one has problems, it leaves the system in an inconsistent
state. So, this is not good but not something we need to fix; it's just a symptom of the
underlying problem you were trying to debug in the code.
2) Running only "ant hackySensor_XmlData.junit" (instead of "ant all.junit")
does not
reproduce the error. We have no idea why! I checked the classpaths and
everything
appears to be ok.
Not yet you don't! Of course, as the story proceeds, the reader learns that the error
really wasn't in the XmlData module at all, but in FileMetric processing, so this does
eventually make perfect sense.
3) Another strange thing was that the build\war\download\*.jar files were on the
classpath.
[junit] '-classpath'
....
C:\java\svn\hackyCore_Build\build\war\download\sensor.xmldata.jar;
...
Not sure if it matters, but does that directory really need to be on the
classpath?
I'll have to look into this further.
So, we added a stack trace printout to the NullPointerException. Something
which we
should have done a lot earlier, but we had a lot of problems just reproducing
the error
on both our machines.
Now that stacktrace will be printed automatically, so future hackers won't get hung up
here.
We quickly realized that for FileMetric entries that the
JavaClassWorkspaceMapManager
expects a className with every Java FileMetric entry. Our test filemetric.xml
file did
not contain a className attribute. Well, as you may know, className is not a
required
SDT attribute, so we didn't put it in our test data. Unfortunately, className is
required (not in the SDT, but in the background processing in Hackystat) for
Java
FileMetric entries. Whether or not that is a good thing can be debated later.
Ooh, SDT evolution ripple effect at work! I just fixed the
JavaClassWorkspaceMapManager.isJavaClassName method to check for a null className, so
that should help with this kind of situation in future. My ultimate goal is to entirely
rid ourselves of these workspace maps.
At one point Austen and I were getting the "We're hosed... " message. Hm...
Basically,
it seems that hackySdt_BadData should always be required. Otherwise, we could
be hosed.
Very good catch! I forgot about that dependency during the Version 7 restructuring.
Thinking about this issue made me realize that there's actually a nice solution which
improves the hackystat architecture in general. Currently, hackyCore_Kernel includes the
definition of an EvolSdt SDT which is used to enable basic SDT testing within the kernel
where the SDT mechanisms are defined. What I am going to do is move the EvolSdt into its
own module (hackySdt_EvolSdt), and get rid of the hackySdt_BadData module, moving that
code into hackyCore_Kernel. This solves a couple of problems: first, it means anyone
with the kernel gets the BadData SDT, which is what we want, and second, all
configurations won't be getting the EvolSdt SDT automatically, which was always kind of
bogus. Entered into Jira (for after 7.3) as:
<http://hackydev.ics.hawaii.edu:8080/browse/HACK-541>
2) The last interesting/strange thing is related to the NullPointerException we
were
having.
[ Commentary about the test data and bad data simultaneously ]
This is indeed interesting. I think it has to do with the fact that the
WorkspaceMapManager gets called as a hook function during the construction of a sensor
data instance from disk. I'll need to look into this further, though. It may not be an
"error", per se.
thanks, aaron
and thanks to austen for accompanying me on this debugging journey! :)
You two get the HHotW (Hackystat Hackers of the Week) award!
Cheers,
Philip
