• We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Lucene 2.3 was released in January 08 with huge performance improvements over 2.2. Given it's a drop-in replacement with no recompiling needed can we get this shipped ASAP and then worry about using some of the new methods?

            [JRASERVER-14582] Upgrade Lucene to 2.3

            The Lucene upgrade was completed in JRA-15517.

            Mark Lassau (Inactive) added a comment - The Lucene upgrade was completed in JRA-15517 .

            AntonA added a comment -

            Hi Sam,

            While we would like to help, we are, unfortuantely, absolutely bogged down with 4.0 work. Due to this, we cannot spend time time on this. We are looking forward to upgrading Lucene though.

            Sorry to disappoint.

            Cheers,
            Anton

            AntonA added a comment - Hi Sam, While we would like to help, we are, unfortuantely, absolutely bogged down with 4.0 work. Due to this, we cannot spend time time on this. We are looking forward to upgrading Lucene though. Sorry to disappoint. Cheers, Anton

            Sam Gaw added a comment - - edited

            Bummer

            In that case I'll push my luck... can you look at the value of maxNumSegments to do partial optimizations on the index? With 2.3's smaller footprint this would let us run more regular jobs without increasing the merge cost. Also, reading the new docs, optimizing is done in the background now so for the larger instances would it be worthwhile reducing mergeFactor so that it can merge while indexing?

            You guys would know more about Lucene than me so if I'm way off on this I'd be more than happy to be schooled

            Edit: I'm talking about optimizing a crazy ass search engine and can't even get the wiki tags right. Teach me to try to sound clever.

            Sam Gaw added a comment - - edited Bummer In that case I'll push my luck... can you look at the value of maxNumSegments to do partial optimizations on the index? With 2.3's smaller footprint this would let us run more regular jobs without increasing the merge cost. Also, reading the new docs, optimizing is done in the background now so for the larger instances would it be worthwhile reducing mergeFactor so that it can merge while indexing? You guys would know more about Lucene than me so if I'm way off on this I'd be more than happy to be schooled Edit: I'm talking about optimizing a crazy ass search engine and can't even get the wiki tags right. Teach me to try to sound clever.

            Also, while lucene-core 2.3 is a drop-in replacement for 2.2, the same can't be said for lucene-analyzers. The big problem is that they completely rewrote the StandardTokenizer and our code uses the now removed StandardTokenizerConstants interface.

            Otherwise we'd ask you to test it and tell us what improvement you see

            Jed Wesley-Smith (Inactive) added a comment - Also, while lucene-core 2.3 is a drop-in replacement for 2.2, the same can't be said for lucene-analyzers . The big problem is that they completely rewrote the StandardTokenizer and our code uses the now removed StandardTokenizerConstants interface. Otherwise we'd ask you to test it and tell us what improvement you see

            AntonA added a comment -

            Hi Sam,

            Agreed. We are look forward getting this done as well.

            Cheers,
            Anton

            AntonA added a comment - Hi Sam, Agreed. We are look forward getting this done as well. Cheers, Anton

            Sam Gaw added a comment -

            Cheers Anton. The reason I raised the point of the upgrade was because we've found that anything using the Lucene cache is the slowest part of the system and anything to improve performance would be greatly appreciated.

            Sam Gaw added a comment - Cheers Anton. The reason I raised the point of the upgrade was because we've found that anything using the Lucene cache is the slowest part of the system and anything to improve performance would be greatly appreciated.

            AntonA added a comment -

            Hi Sam,

            Thank you for the suggestion. We are hoping to upgrade lucene to 2.3 when we have a chance.

            The reason we do not have an exact implementation datre for this, is that usually we find that upgrades, even if they are drop in replacements need some testing. We are quite busy working on features that are already scheduled for 4.0, so this may not make the cut.

            We are hoping to look into this as soon as we can.

            Cheers,
            Anton

            AntonA added a comment - Hi Sam, Thank you for the suggestion. We are hoping to upgrade lucene to 2.3 when we have a chance. The reason we do not have an exact implementation datre for this, is that usually we find that upgrades, even if they are drop in replacements need some testing. We are quite busy working on features that are already scheduled for 4.0, so this may not make the cut. We are hoping to look into this as soon as we can. Cheers, Anton

              Unassigned Unassigned
              3b39d92693cb Sam Gaw
              Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: