[
https://issues.apache.org/jira/browse/LUCENE-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey closed LUCENE-5862.
--------------------------------
Resolution: Cannot Reproduce
The new rebuild created indexes with the correct size. The only difference I
can think of: This time, before the rebuild started, the build cores contained
an index that had been built by 4.7.2 and then modified by 4.9.0, whereas for
the last rebuild the build cores contained an index built by 4.7.2 with no
changes by 4.9.0.
I have one more thing to try, but I am not supremely confident that it will
create the same behavior, so I'm closing this issue. If others run into this
problem, or I can reproduce it, the issue is already here and can be re-opened.
> Old segments not deleted on merge
> ---------------------------------
>
> Key: LUCENE-5862
> URL: https://issues.apache.org/jira/browse/LUCENE-5862
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: 4.9
> Environment: Linux bigindy5 3.14.1-1.el6.elrepo.x86_64 #1 SMP Mon Apr
> 14 19:29:19 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_55"
> Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
> [root@bigindy5 s5_0]# cat /etc/redhat-release
> CentOS release 6.5 (Final)
> Reporter: Shawn Heisey
> Fix For: 5.0, 4.10
>
>
> After a full rebuild with the dataimport handler on a Solr install upgraded
> to Solr 4.9.0, I ended up with an index that was considerably larger than the
> one it replaced (built by 4.7.2), 28GB instead of 20GB. I also upgraded a
> third-party component at the same time, to a version which has been tested
> with Solr 4.9.0. The config didn't change at all. Optimizing the index did
> not shrink it.
> At first I thought there must have been something different about the way the
> new version worked, or possibly a change/bug in the third-party component.
> After looking deeper, I discovered that the optimization process had created
> one segment that was 20GB in size, but there were also a number of other
> segments on the disk, all of which were several hours older than the large
> segment. Another optimize created a new segment of 20GB, and the previous
> segment of 20GB was deleted, but the older segments remained.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
