[ https://issues.apache.org/jira/browse/LUCENE-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027640#comment-13027640 ]
Robert Muir commented on LUCENE-3054: ------------------------------------- {quote} I propose to change SorterTemplate to fall back to mergeSort once it checks that number of iterations grows e.g. > 20 (have to test a little bit). {quote} I like the idea of some "guard" here to prevent the stack overflow, and hopefully keep the quickSort performance for the places where we know its better than mergesort. > SorterTemplate.quickSort stack overflows on broken comparators that produce > only few disticnt values in large arrays > -------------------------------------------------------------------------------------------------------------------- > > Key: LUCENE-3054 > URL: https://issues.apache.org/jira/browse/LUCENE-3054 > Project: Lucene - Java > Issue Type: Task > Affects Versions: 3.1 > Reporter: Robert Muir > Priority: Critical > Attachments: LUCENE-3054.patch, LUCENE-3054.patch > > > Looking at Otis's sort problem on the mailing list, he said: > {noformat} > * looked for other places where this call is made - found it in > MultiPhraseQuery$MultiPhraseWeight and changed that call from > ArrayUtil.quickSort to ArrayUtil.mergeSort > * now we no longer see SorterTemplate.quickSort in deep recursion when we do a > thread dump > {noformat} > I thought this was interesting because PostingsAndFreq's comparator > looks like it needs a tiebreaker. > I think in our sorts we should add some asserts to try to catch some of these > broken comparators. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org