Life, code and stuff
Posted by Marc Sturlese

09 Mar 09 Lucene 2.4.1 available from today

A new official release of Lucene in now available! Lucene 2.4.1 is a bug fix version.

We will be able to see more new features in the Lucene 2.9 release (available in developers version).

Here I mention all the improvements of Lucene 2.4.1, wich I read from the official lucene’s site:

  • Fixed silent data-loss case whereby binary fields are truncated to 0 bytes during merging if the segments being merged are non-congruent (same field name maps to different field numbers).
  • Don’t throw incorrect IllegalStateException from IndexWriter.close() if you’ve hit an OOM when autoCommit is true.
  • If IndexReader.flush() is called twice when there were pending deletions, it could lead to later false AssertionError during IndexReader.open.
  • Fix false AlreadyClosedException from IndexReader.open (masking an actual IOException) that takes String or File path.
  • Multiple-valued NOT_ANALYZED fields can double-count token offsets.
  • Ensure IndexReader.reopen() does not result in incorrectly closing the shared FSDirectory. This bug would only happen if you use IndexReader.open with a File or String argument.
  • Fix possible overflow bugs during binary searches.
  • Fix CachingWrapperFilter to not throw exception if both bits() and getDocIdSet() methods are called.
  • Fix int overflow bug during segment merging.
  • Fix int overflow bug when flushing segment.
  • Fix deadlock in IndexWriter.addIndexes(IndexReader[]).
  • NearSpansOrdered returns payloads from first possible match rather than the correct, shortest match; Payloads could be returned even if the max slop was exceeded; The wrong payload could be returned in certain situations.
  • Add Analyzer.close() to free internal ThreadLocal resources.
  • Fix IndexWriter.addIndexes(IndexReader[]) to properly rollback IndexWriter’s internal state on hitting an exception.

Related posts

Tags: ,

Reader's Comments

  1. |

    Hello Marc..
    I want know a way where i can merge attributes across cores into single DOC not just merging cores; it will not merge attributes in same single doc..

    I split my data in different cores wid different schemas in hierarchy..
    Now i want to perform search across all cores that i am doing using Shards concepts..
    But i have a problem that is regarding Logical operator..
    I cannot perform AND operation across cores..
    The result will fail..(as data in cores different)
    Is there any way of dynamic merging of attributes..So that i can fix this logical operator problem..

  2. |

    Hey Rajani,
    I supose you are working with Solr and not directly with Lucene. For a correct usage of Solr sharding I would recomend you keep the same schema for all the shards.
    There isn’t a way to merge fields from different documents in a single doc on the Solr distributed search merging process.
    I think you should consider reorganizing the data in your index. Shards are meant to scale data horizontally.

Leave a Comment