Opening an IndexWriter creates a lock file for the directory in use. Trying to open
another IndexWriter on the same directory will lead to a
LockObtainFailedException. The LockObtainFailedException
is also thrown if an IndexReader on the same directory is used to delete documents
from the index.

Expert: IndexWriter allows an optional
IndexDeletionPolicy implementation to be
specified. You can use this to control when prior commits
are deleted from the index. The default policy is KeepOnlyLastCommitDeletionPolicy which removes all prior
commits as soon as a new commit is done (this matches
behavior before 2.2). Creating your own policy can allow
you to explicitly keep previous "point in time" commits
alive in the index for some time, to allow readers to
refresh to the new commit without having the old commit
deleted out from under them. This is necessary on
filesystems like NFS that do not support "delete on last
close" semantics, which Lucene's "point in time" search
normally relies on.

NOTE: if you hit an
OutOfMemoryError then IndexWriter will quietly record this
fact and block all future segment commits. This is a
defensive measure in case any internal state (buffered
documents and deletions) were corrupted. Any subsequent
calls to commit() will throw an
IllegalStateException. The only course of action is to
call close(), which internally will call rollback(), to undo any changes to the index since the
last commit. You can also just call rollback()
directly.

NOTE: IndexWriter instances are completely thread
safe, meaning multiple threads can call any of its
methods, concurrently. If your application requires
external synchronization, you should not
synchronize on the IndexWriter instance as
this may cause deadlock; use your own (non-Lucene) objects
instead.

NOTE: If you call
Thread.interrupt() on a thread that's within
IndexWriter, IndexWriter will try to catch this (eg, if
it's in a wait() or Thread.sleep()), and will then throw
the unchecked exception ThreadInterruptedException
and clear the interrupt status on the thread.

Nested Class Summary

If DirectoryReader.open(IndexWriter,boolean) has
been called (ie, this writer is in near real-time
mode), then after a merge completes, this class can be
invoked to warm the reader on the newly merged
segment, before the merge commits.

Commits all pending changes (added & deleted
documents, segment merges, added
indexes, etc.) to the index, and syncs all referenced
index files, such that a reader will see the changes
and the index updates will survive an OS or machine
crash or power loss.

Expert: asks the mergePolicy whether any merges are
necessary now and if so, runs the requested merges and
then iterate (test again if merges are needed) until no
more merges are returned by the mergePolicy.

Atomically deletes documents matching the provided
delTerm and adds a block of documents, analyzed using
the provided analyzer, with sequentially
assigned document IDs, such that an external reader
will see all or none of the documents.

SOURCE_ADDINDEXES_READERS

MAX_TERM_LENGTH

public static final int MAX_TERM_LENGTH

Absolute hard maximum length for a term, in bytes once
encoded as UTF8. If a term arrives from the analyzer
longer than this length, it is skipped and a message is
printed to infoStream, if set (see IndexWriterConfig.setInfoStream(InfoStream)).

Constructor Detail

IndexWriter

Constructs a new IndexWriter per the settings given in conf.
Note that the passed in IndexWriterConfig is
privately cloned; if you need to make subsequent "live"
changes to the configuration use getConfig().

Parameters:

d - the index directory. The index is either created or appended
according conf.getOpenMode().

conf - the configuration settings according to which IndexWriter should
be initialized.

Throws:

IOException - if the directory cannot be read/written to, or if it does not
exist and conf.getOpenMode() is
OpenMode.APPEND or if there is any other low-level
IO error

close

Commits all changes to an index, waits for pending merges
to complete, and closes all associated files.

This is a "slow graceful shutdown" which may take a long time
especially if a big merge is pending: If you only want to close
resources use rollback(). If you only want to commit
pending changes and close resources see close(boolean).

Note that this may be a costly
operation, so, try to re-use a single writer instead of
closing and opening a new one. See commit() for
caveats about write caching done by some IO devices.

If an Exception is hit during close, eg due to disk
full or some other reason, then both the on-disk index
and the internal state of the IndexWriter instance will
be consistent. However, the close will not be complete
even though part of it (flushing buffered documents)
may have succeeded, so the write lock will still be
held.

If you can correct the underlying cause (eg free up
some disk space) then you can call close() again.
Failing that, if you want to force the write lock to be
released (dangerous, because you may then lose buffered
docs in the IndexWriter instance) then you can do
something like this:

close

Closes the index with or without waiting for currently
running merges to finish. This is only meaningful when
using a MergeScheduler that runs merges in background
threads.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer, again. See above for details.

NOTE: it is dangerous to always call
close(false), especially when IndexWriter is not open
for very long, because this can result in "merge
starvation" whereby long merges will never have a
chance to finish. This will cause too many segments in
your index over time.

Parameters:

waitForMerges - if true, this call will block
until all merges complete; else, it will ask all
running merges to abort, wait until those merges have
finished (which should be at most a few seconds), and
then return.

maxDoc

numDocs

public int numDocs()

Returns total number of docs in this index, including
docs not yet flushed (still in the RAM buffer), and
including deletions. NOTE: buffered deletions
are not counted. If you really need these to be
counted you should call commit() first.

addDocument

Note that if an Exception is hit (for example disk full)
then the index will be consistent, but this document
may not have been added. Furthermore, it's possible
the index will have one segment in non-compound format
even when using compound files (when a merge has
partially succeeded).

This method periodically flushes pending documents
to the Directory (see above), and
also periodically triggers segment merges in the index
according to the MergePolicy in use.

Merges temporarily consume space in the
directory. The amount of space required is up to 1X the
size of all segments being merged, when no
readers/searchers are open against the index, and up to
2X the size of all segments being merged when
readers/searchers are open against the index (see
forceMerge(int) for details). The sequence of
primitive merge operations performed is governed by the
merge policy.

Note that each term in the document can be no longer
than 16383 characters, otherwise an
IllegalArgumentException will be thrown.

Note that it's possible to create an invalid Unicode
string in java if a UTF16 surrogate pair is malformed.
In this case, the invalid characters are silently
replaced with the Unicode replacement character
U+FFFD.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

addDocuments

Atomically adds a block of documents with sequentially
assigned document IDs, such that an external reader
will see all or none of the documents.

WARNING: the index does not currently record
which documents were added as a block. Today this is
fine, because merging will preserve a block. The order of
documents within a segment will be preserved, even when child
documents within a block are deleted. Most search features
(like result grouping and block joining) require you to
mark documents; when these documents are deleted these
search features will not work as expected. Obviously adding
documents to an existing block will require you the reindex
the entire block.

However it's possible that in the future Lucene may
merge more aggressively re-order documents (for example,
perhaps to obtain better index compression), in which case
you may need to fully re-index your documents at that time.

See addDocument(Iterable) for details on
index and IndexWriter state after an Exception, and
flushing/merging temporary free space requirements.

NOTE: tools that do offline splitting of an index
(for example, IndexSplitter in contrib) or
re-sorting of documents (for example, IndexSorter in
contrib) are not aware of these atomically added documents
and will likely break them up. Use such tools at your
own risk!

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

updateDocuments

Atomically deletes documents matching the provided
delTerm and adds a block of documents with sequentially
assigned document IDs, such that an external reader
will see all or none of the documents.
See addDocuments(Iterable).

updateDocuments

Atomically deletes documents matching the provided
delTerm and adds a block of documents, analyzed using
the provided analyzer, with sequentially
assigned document IDs, such that an external reader
will see all or none of the documents.
See addDocuments(Iterable).

tryDeleteDocument

Expert: attempts to delete by document ID, as long as
the provided reader is a near-real-time reader (from DirectoryReader.open(IndexWriter,boolean)). If the
provided reader is an NRT reader obtained from this
writer, and its segment has not been merged away, then
the delete succeeds and this method returns true; else, it
returns false the caller must then separately delete by
Term or Query.
NOTE: this method can only delete documents
visible to the currently open NRT reader. If you need
to delete documents indexed after opening the NRT
reader you must use the other deleteDocument methods
(e.g., deleteDocuments(Term)).

updateDocument

Updates a document by first deleting the document(s)
containing term and then adding the new
document. The delete and then add are atomic as seen
by a reader on the same index (flush may happen only after
the add).

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

updateDocument

Updates a document by first deleting the document(s)
containing term and then adding the new
document. The delete and then add are atomic as seen
by a reader on the same index (flush may happen only after
the add).

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

forceMerge

Forces merge policy to merge segments until there are <=
maxNumSegments. The actual merges to be
executed are determined by the MergePolicy.

This is a horribly costly operation, especially when
you pass a small maxNumSegments; usually you
should only call this if the index is static (will no
longer be changed).

Note that this requires up to 2X the index size free
space in your Directory (3X if you're using compound
file format). For example, if your index size is 10 MB
then you need up to 20 MB free for this to complete (30
MB if you're using compound file format). Also,
it's best to call commit() afterwards,
to allow IndexWriter to free up disk space.

If some but not all readers re-open while merging
is underway, this will cause > 2X temporary
space to be consumed as those new readers will then
hold open the temporary segments at that time. It is
best not to re-open readers while merging is running.

The actual temporary usage could be much less than
these figures (it depends on many factors).

In general, once this completes, the total size of the
index will be less than the size of the starting index.
It could be quite a bit smaller (if there were many
pending deletes) or just slightly smaller.

If an Exception is hit, for example
due to disk full, the index will not be corrupted and no
documents will be lost. However, it may have
been partially merged (some segments were merged but
not all), and it's possible that one of the segments in
the index will be in non-compound format even when
using compound file format. This will occur when the
Exception is hit during conversion of the segment into
compound format.

This call will merge those segments present in
the index when the call started. If other threads are
still adding documents and flushing segments, those
newly created segments will not be merged unless you
call forceMerge again.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

forceMerge

Just like forceMerge(int), except you can
specify whether the call should block until
all merging completes. This is only meaningful with a
MergeScheduler that is able to run merges in
background threads.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

forceMergeDeletes

Just like forceMergeDeletes(), except you can
specify whether the call should block until the
operation completes. This is only meaningful with a
MergeScheduler that is able to run merges in
background threads.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

forceMergeDeletes

Forces merging of all segments that have deleted
documents. The actual merges to be executed are
determined by the MergePolicy. For example,
the default TieredMergePolicy will only
pick a segment if the percentage of
deleted docs is over 10%.

maybeMerge

Expert: asks the mergePolicy whether any merges are
necessary now and if so, runs the requested merges and
then iterate (test again if merges are needed) until no
more merges are returned by the mergePolicy.
Explicit calls to maybeMerge() are usually not
necessary. The most common case is when merge policy
parameters have changed.
This method will call the MergePolicy with
MergePolicy.MergeTrigger.EXPLICIT.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

getMergingSegments

Expert: to be used by a MergePolicy to avoid
selecting merges for segments already being merged.
The returned collection is not cloned, and thus is
only safe to access if you hold IndexWriter's lock
(which you do when IndexWriter invokes the
MergePolicy).

rollback

Close the IndexWriter without committing
any changes that have occurred since the last commit
(or since it was opened, if commit hasn't been called).
This removes any temporary files that had been created,
after which the state of the index will be the same as
it was when commit() was last called or when this
writer was first opened. This also clears a previous
call to prepareCommit().

deleteAll

This method will drop all buffered documents and will
remove all segments from the index. This change will not be
visible until a commit() has been called. This method
can be rolled back using rollback().

NOTE: this method is much faster than using deleteDocuments( new MatchAllDocsQuery() ).
Yet, this method also has different semantics compared to deleteDocuments(Query)
/ deleteDocuments(Query...) since internal data-structures are cleared as well
as all segment information is forcefully dropped anti-viral semantics like omitting norms
are reset or doc value types are cleared. Essentially a call to deleteAll() is equivalent
to creating a new IndexWriter with IndexWriterConfig.OpenMode.CREATE which a delete query only marks
documents as deleted.

addIndexes

This may be used to parallelize batch indexing. A large document
collection can be broken into sub-collections. Each sub-collection can be
indexed in parallel, on a different thread, process or machine. The
complete index can then be created by merging sub-collection indexes
with this method.

NOTE: the index in each Directory must not be
changed (opened by a writer) while this method is
running. This method does not acquire a write lock in
each input Directory, so it is up to the caller to
enforce this.

This method is transactional in how Exceptions are
handled: it does not commit a new segments_N file until
all indexes are added. This means if an Exception
occurs (for example disk full), then either no indexes
will have been added or they all will have been.

Note that this requires temporary free space in the
Directory up to 2X the sum of all input indexes
(including the starting index). If readers/searchers
are open against the starting index, then temporary
free space required will be higher by the size of the
starting index (see forceMerge(int) for details).

NOTE: this method only copies the segments of the incoming indexes
and does not merge them. Therefore deleted documents are not removed and
the new segments are not merged with the existing ones.

This requires this index not be among those to be added.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

NOTE: if this method hits an OutOfMemoryError you should immediately
close the writer. See above for details.

NOTE: this method merges all given IndexReaders in one
merge. If you intend to merge a large number of readers, it may be better
to call this method multiple times, each time with a small set of readers.
In principle, if you use a merge policy with a mergeFactor or
maxMergeAtOnce parameter, you should pass that many readers in one
call. Also, if the given readers are DirectoryReaders, they can be
opened with termIndexInterval=-1 to save RAM, since during merge
the in-memory structure is not used. See
DirectoryReader.open(Directory, int).

prepareCommit

Expert: prepare for commit. This does the
first phase of 2-phase commit. This method does all
steps necessary to commit changes since this writer
was opened: flushes pending added and deleted docs,
syncs the index files, writes most of next segments_N
file. After calling this you must call either commit() to finish the commit, or rollback() to revert the commit and undo all changes
done since the writer was opened.

You can also just call commit() directly
without prepareCommit first in which case that method
will internally call prepareCommit.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

setCommitData

Sets the commit user data map. That method is considered a transaction by
IndexWriter and will be committed even if no other
changes were made to the writer instance. Note that you must call this method
before prepareCommit(), or otherwise it won't be included in the
follow-on commit().

NOTE: the map is cloned internally, therefore altering the map's
contents after calling this method has no effect.

commit

Commits all pending changes (added & deleted
documents, segment merges, added
indexes, etc.) to the index, and syncs all referenced
index files, such that a reader will see the changes
and the index updates will survive an OS or machine
crash or power loss. Note that this does not wait for
any running background merges to finish. This may be a
costly operation, so you should test the cost in your
application and do it only when really necessary.

Note that this operation calls Directory.sync on
the index files. That call should not return until the
file contents & metadata are on stable storage. For
FSDirectory, this calls the OS's fsync. But, beware:
some hardware devices may in fact cache writes even
during fsync, and return before the bits are actually
on stable storage, to give the appearance of faster
performance. If you have such a device, and it does
not have a battery backup (for example) then on power
loss it may still lose data. Lucene cannot guarantee
consistency on such devices.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

deleteUnusedFiles

IndexWriter normally deletes unused files itself,
during indexing. However, on Windows, which disallows
deletion of open files, if there is a reader open on
the index then those files cannot be deleted. This is
fine, because IndexWriter will periodically retry
the deletion.

However, IndexWriter doesn't try that often: only
on open, close, flushing a new segment, and finishing
a merge. If you don't do any of these actions with your
IndexWriter, you'll see the unused files linger. If
that's a problem, call this method to delete them
(once you've closed the open readers that were
preventing their deletion).

In addition, you can call this method to delete
unreferenced index commits. This might be useful if you
are using an IndexDeletionPolicy which holds
onto index commits until some criteria are met, but those
commits are no longer needed. Otherwise, those commits will
be deleted the next time commit() is called.