Community
Participate
Working Groups
Using 3.4RC3 but already happened in 3.4RC2. All JDT/Text tests after DocumentLineDifferInitializationTest#testInitializationWithFewChanges() (included) only have data in graph and tables for the 3 of 4 last builds with only one baseline result to compare with... Note that for 3.4RC1 all these tests had *no* results and that for 3.4M7 they seemed to be OK...
Increase severity as this loss of information makes the performance survey really difficult to do on these tests. Note that using a local copy of the releng database, I was not able to reproduce this issue and got correct results pages for all JDT/Text tests...
It's a problem with the JDT/Text local data file which seems not to be big enough.
I've removed the local data file to generate all JDT/Text results directly from the database numbers, this should fix the problem...
Unfortunately, looking at I20080609-1311 perfs results, it seems that deleting the JDT/Text local data file didn't fix the issue => reopen...
I'm investigating... Kim, if you have some time, could put the database please at the usual place? TIA
Can we target this for 3.4? 3.4 shouldn't go live with the such broken results.
(In reply to comment #6) > Can we target this for 3.4? 3.4 shouldn't go live with the such broken results. > Of course, the next try will be to generate results without local data. This issue is a little bit tricky as I cannot reproduce it locally... Kim will send me the console output of the generation, I hope there will be more clue to narrow what's wrong with these tests!
>It's a problem with the JDT/Text local data file which seems not to be big >enough. Can you explain a bit more? Does it mean Text results are actually too big?
(In reply to comment #8) > >It's a problem with the JDT/Text local data file which seems not to be big > >enough. > Can you explain a bit more? Does it mean Text results are actually too big? > To speed up results generation, previous builds results used in graphs and raw data tables are stored in local files. For an unknown reason, although JTD/Text has the bigger number of scenarios (166), its local data file is smaller (773Kb) than most of the other components (e.g. JDT/Core local file size is 2,547Kb with 'only' 57 scenarios...). While generating locally, the local data file for JDT/Text is around 4Mb, hence should be around the same size after having generated the results on the build server...
Created attachment 104329 [details] log from generating perf results using local file
(In reply to comment #10) > Created an attachment (id=104329) [details] > log from generating perf results using local file > Hmm, unfortunately, this is the log when you regenerated the results this morning: [java] Parameters used to generate performance results (6/10/08 10:50 AM): As the wrong local JDT/Text data file already exists after the initial generation, it was used during the generation :-( Hence, this explain the incomplete graphs and tables for JDT/Text tests and does not give me any more information... I thought that delete the local file was not enough but in fact, I deleted it on fullmoon! But these local files are copied from the build server aren't they? So, it obviously must be deleted from the build server instead! Kim, instead of removing the -dataDir argument from the command line, could you simply remove the org.eclipse.jdt.text.dat file from the build server? Then, I guess it really should fix this issue...
This is target milestone 3.4 but 3.4 is basically over. Please move milestone if appropriate.
I've removed org.eclipse.jdt.text.dat from the build server.
>This is target milestone 3.4 but 3.4 is basically over. Please move milestone >if appropriate. This needs to be fixed in final 3.4. If you know of a better target milestone (e.g. 3.4 RC5) I'm happy to change it.
(In reply to comment #12) > This is target milestone 3.4 but 3.4 is basically over. Please move milestone > if appropriate. > The proposed change affects only releng scripts/processes to generate performance results pages. This has no impact at all on the Eclipse 3.4 SDK content. So, I guess that the Eclipse development end cycle rules are not supposed to be applied on such changes...
Unfortunately, results generation for build I20080611-2000 failed in the middle of JDT/Text tests. Kim, I need the console output again to investigate why this failure occurred, thanks
I verified that numbers are OK in the database, which confirms that this problem is only while generating the results...
Created attachment 104863 [details] log from regenerating results for I20080611-2000
(In reply to comment #18) > Created an attachment (id=104863) [details] > log from regenerating results for I20080611-2000 > I do not see anything wrong in the console output which can explain that not all results were generated. However, as the JDT/Text local data file was not deleted before the re-generation, it was the incorrect local data which have been used instead of numbers from the releng perfs database... So, the next step is to zip the perfDb34 database and send it to me. Then, I'll to reproduce the issue locally hence have a chance to figure out what happens there... TIA
Unfortunately, even with this last updated database, I still cannot reproduce the behavior observed on the build server machine while generating the perfs results. I made the following tries: 1) without -dataDir argument 2) with -dataDir argument but no existing local data files 3) with -dataDir argument and existing local data files from a previous build (I20080603-2000) 4) with -dataDir argument and existing local data files from same build (I20080613-2000) 5) with -dataDir argument and existing local data files from same build (I20080613-2000) except for JDT/Text local data file All these tests produced correct HTML pages for results with no failures and all numbers in graphs and tables...
Created attachment 105138 [details] Console output while generating without -dataDir argument The trace shows that the generation stops abruptly during the JDT/Core tests, but I can see on the build perfs results page that it still was stopped on the JDT/Text test... Perhaps the .log file of the workspace used to run the generation application will give some more clues?
Created attachment 105139 [details] .log file while generating wihtout -dataDir argument Fortunately, this log gives me more clues... :-) There's an unexpected disconnection from the the database while generating, hence explaining the missing results! I was not able to reproduce this failure but I'm generating on a Windows box although the log shows that it's run on a Linux box. I'll try to setup a similar config and see if I have more chance to reproduce the problem...
Kim, I also saw in the .log that the eclipse build used to generate is 3.4M5: eclipse.buildId=200802071530 Would it be possible to upgrade it to last build and see if the failures still occurs?
Regarding comment #23, the build is actually using RC3, however I just forgot to update the buildId in the config.ini of basebuilder. There is this error at the console of the database machine Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 215d; Error Code Value = 1d org.apache.derby.impl.drda.DRDAProtocolException at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.invalidCodePoint(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseCNTQRY(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.splitQRYDTA(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) null org.apache.derby.impl.drda.DRDAProtocolException at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.invalidCodePoint(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseCNTQRY(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.splitQRYDTA(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) I'm investigating the error messages.
This looks like a similar problem. http://issues.apache.org/jira/browse/DERBY-614 I'll try updating to a more recent copy of the database after the release. bug 237470 tracks the db update
Results are OK now for JDT/Text in R3_4_maintenance stream, hence close this bug as fixed...
