Well if the debug results seem correct then there must be some bug in the
submission script. :/ It is a pretty old piece of code, so it is possible
that something is going awry in there.
Let us know if you notice further problems like this. I won't have time to
look into them in the near term, but I'll try to put in on the short list
to get to when I get free cycles. If you happen to come across a repeater
scenario (not likely since this seems like something difficult
to reproduce) that would help the debugging effort.
Thanks and sorry for the trouble...
On Fri, Jan 6, 2012 at 2:07 PM, Eugene Loh <eugene.loh_at_[hidden]> wrote:
> On 01/06/12 08:52, Josh Hursey wrote:
> Weird. I don't know what is going on here, unless the client is somehow
> submitting some of the results too many times. One thing to check is the
> debug output file that the MTT client is submitting to the server. Check
> that for duplicates.
> Sorry, I don't understand where to check. I do know that if I look at the
> output from the MTT client, I see a bunch of messages like this:
> >> Reported to MTTDatabase client: 1 successful submit, 0 failed submits
> (total of 6 results)
> If I add up those numbers of results submitted, the totals match what I
> would expect. So, there is some indication that the number of client
> submissions is right.
> That will help determine whether this is a server side problem or client
> side problem. I have not noticed this behavior on the server before,
> I haven't either, but I only just started looking more closely at
> results. Mostly, in any case, things look fine.
> but might be something with the submit.php script - just a guess though at
> this point.
> Unfortunately I have zero time to spend on MTT for a few weeks at least.
> -- Josh
> On Thu, Jan 5, 2012 at 8:11 PM, Eugene Loh <eugene.loh_at_[hidden]> wrote:
>> I go to MTT and I choose:
>> Test run
>> Date range: 2012-01-05 05:00:00 - 2012-01-05 12:00:00
>> Org: Oracle
>> Platform name: $burl-ct-v20z-2$
>> Suite: intel-64
>> and I get:
>> 1 oracle burl-ct-v20z-2 i86pc SunOS ompi-nightly-trunk 1.7a1r25692
>> intel-64 4 870 0 86 0 0
>> 2 oracle burl-ct-v20z-2 i86pc SunOS ompi-nightly-v1.5 1.5.5rc2r25683
>> intel-64 4 915 0 92 0 0
>> I get more tests (passing and skipped) with v1.5 than I do with the trunk
>> run. I have lots of ways of judging what the numbers should be. The
>> "trunk" numbers are right. The "v1.5" numbers are too high; they should
>> be the same as the trunk numbers.
>> I can see the explanation by clicking on "Detail" and looking at
>> individual runs. (To get time stamps, I add a " | by minute" qualifier
>> before clicking on "Detail". Maybe there's a more proper way of getting
>> time stamps, but that seems to work for me.) Starting with record 890 and
>> ending with 991, records are repeated. That is, 890 and 891 have identical
>> command lines, time stamps, output, etc. One of them is a duplicate. Same
>> with 892 and 893, then for 894 and 895, then 896 and 897, and so on. So,
>> for about a one-hour period, the records sent in by this test run appear
>> duplicated when I submit queries to the database. These 51 duplicates are
>> the 45 extra passes and 6 extra skips seen in the results above.
>> Can someone figure out what's going wrong here? Clearly, I'd like to be
>> able to rely on query results.
> mtt-devel mailing list
Postdoctoral Research Associate
Oak Ridge National Laboratory