This was fixed on trunk in
LUCENE-1044 but I'd like to separately
backport it to 2.3.
With ConcurrentMergeScheduler there is a bug, only when CFS is on,
whereby after the final merge of an optimize has finished and while
it's building its CFS, the merge policy may incorrectly ask for
another merge to collapse that segment into a compound file. The net
effect is optimize can spend many extra iterations unecessarily
merging a single segment to collapse it to compound file.
I believe the case is rare (hard to hit), and maybe only if you have
multiple threads calling optimize at once (the TestThreadedOptimize
test can hit it), but it's a low-risk fix so I plan to commit to 2.3