mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-07 05:28:34 +00:00
797a9b07ef
There is a pretty nasty bug in the lock factory we use that can cause nodes to use the same data dir wiping each others data. Luckily this is unlikely to happen if the nodes are running in different JVM which they do unless they are embedded. See LUCENE-5738 Closes #6424
64 lines
4.0 KiB
Plaintext
64 lines
4.0 KiB
Plaintext
@defaultMessage spawns threads with vague names; use a custom thread factory and name threads so that you can tell (by its name) which executor it is associated with
|
|
|
|
java.util.concurrent.Executors#newFixedThreadPool(int)
|
|
java.util.concurrent.Executors#newSingleThreadExecutor()
|
|
java.util.concurrent.Executors#newCachedThreadPool()
|
|
java.util.concurrent.Executors#newSingleThreadScheduledExecutor()
|
|
java.util.concurrent.Executors#newScheduledThreadPool(int)
|
|
java.util.concurrent.Executors#defaultThreadFactory()
|
|
java.util.concurrent.Executors#privilegedThreadFactory()
|
|
|
|
java.lang.Character#codePointBefore(char[],int) @ Implicit start offset is error-prone when the char[] is a buffer and the first chars are random chars
|
|
java.lang.Character#codePointAt(char[],int) @ Implicit end offset is error-prone when the char[] is a buffer and the last chars are random chars
|
|
|
|
@defaultMessage Collections.sort dumps data into an array, sorts the array and reinserts data into the list, one should rather use Lucene's CollectionUtil sort methods which sort in place
|
|
|
|
java.util.Collections#sort(java.util.List)
|
|
java.util.Collections#sort(java.util.List,java.util.Comparator)
|
|
|
|
java.io.StringReader#<init>(java.lang.String) @ Use FastStringReader instead
|
|
|
|
org.apache.lucene.util.RamUsageEstimator#sizeOf(java.lang.Object) @ This can be a perfromance trap
|
|
|
|
@defaultMessage Reference management is tricky, leave it to SearcherManager
|
|
org.apache.lucene.index.IndexReader#decRef()
|
|
org.apache.lucene.index.IndexReader#incRef()
|
|
org.apache.lucene.index.IndexReader#tryIncRef()
|
|
|
|
@defaultMessage QueryWrapperFilter is cachable by default - use Queries#wrap instead
|
|
org.apache.lucene.search.QueryWrapperFilter#<init>(org.apache.lucene.search.Query)
|
|
|
|
@defaultMessage Because the filtercache doesn't take deletes into account FilteredQuery can't be used - use XFilteredQuery instead
|
|
org.apache.lucene.search.FilteredQuery#<init>(org.apache.lucene.search.Query,org.apache.lucene.search.Filter)
|
|
org.apache.lucene.search.FilteredQuery#<init>(org.apache.lucene.search.Query,org.apache.lucene.search.Filter,org.apache.lucene.search.FilteredQuery$FilterStrategy)
|
|
|
|
@defaultMessage Pass the precision step from the mappings explicitly instead
|
|
org.apache.lucene.search.NumericRangeQuery#newDoubleRange(java.lang.String,java.lang.Double,java.lang.Double,boolean,boolean)
|
|
org.apache.lucene.search.NumericRangeQuery#newFloatRange(java.lang.String,java.lang.Float,java.lang.Float,boolean,boolean)
|
|
org.apache.lucene.search.NumericRangeQuery#newIntRange(java.lang.String,java.lang.Integer,java.lang.Integer,boolean,boolean)
|
|
org.apache.lucene.search.NumericRangeQuery#newLongRange(java.lang.String,java.lang.Long,java.lang.Long,boolean,boolean)
|
|
org.apache.lucene.search.NumericRangeFilter#newDoubleRange(java.lang.String,java.lang.Double,java.lang.Double,boolean,boolean)
|
|
org.apache.lucene.search.NumericRangeFilter#newFloatRange(java.lang.String,java.lang.Float,java.lang.Float,boolean,boolean)
|
|
org.apache.lucene.search.NumericRangeFilter#newIntRange(java.lang.String,java.lang.Integer,java.lang.Integer,boolean,boolean)
|
|
org.apache.lucene.search.NumericRangeFilter#newLongRange(java.lang.String,java.lang.Long,java.lang.Long,boolean,boolean)
|
|
|
|
@defaultMessage Only use wait / notify when really needed try to use concurrency primitives, latches or callbacks instead.
|
|
java.lang.Object#wait()
|
|
java.lang.Object#wait(long)
|
|
java.lang.Object#wait(long,int)
|
|
java.lang.Object#notify()
|
|
java.lang.Object#notifyAll()
|
|
|
|
@defaultMessage Beware of the behavior of this method on MIN_VALUE
|
|
java.lang.Math#abs(int)
|
|
java.lang.Math#abs(long)
|
|
|
|
@defaultMessage Use Long.compare instead we are on Java7
|
|
com.google.common.primitives.Longs#compare(long,long)
|
|
|
|
@defaultMessage we have an optimized XStringField to reduce analysis creation overhead
|
|
org.apache.lucene.document.Field#<init>(java.lang.String,java.lang.String,org.apache.lucene.document.FieldType)
|
|
|
|
@defaultMessage Use XNativeFSLockFactory instead of the buggy NativeFSLockFactory see LUCENE-5738 - remove once Lucene 4.9 is released
|
|
org.apache.lucene.store.NativeFSLockFactory
|