mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-22 12:56:53 +00:00
Currently we close the store and therefor the underlying directory when the engine / shard is closed ie. during relocation etc. We also just close it while there are still searches going on and/or we are recovering from it. The recoveries might fail which is ok but searches etc. will be working like pending fetch phases. The contract of the Directory doesn't prevent to read from a stream that was already opened before the Directory was closed but from a system boundary perspective and from lifecycles that we test it seems to be the right thing to do to wait until all resources are released. Additionally it will also help to make sure everything is closed properly before directories are closed itself. Note: this commit adds Object#wait & Object@#notify/All to forbidden APIs Closes #5432
43 lines
2.3 KiB
Plaintext
43 lines
2.3 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()
|
|
|
|
org.apache.lucene.index.IndexWriter#maybeMerge() @ use Merges#maybeMerge
|
|
org.apache.lucene.index.IndexWriter#forceMerge(int) @ use Merges#forceMerge
|
|
org.apache.lucene.index.IndexWriter#forceMerge(int,boolean) @ use Merges#forceMerge
|
|
org.apache.lucene.index.IndexWriter#forceMergeDeletes() @ use Merges#forceMergeDeletes
|
|
org.apache.lucene.index.IndexWriter#forceMergeDeletes(boolean) @ use Merges#forceMergeDeletes
|
|
|
|
@defaultMessage QueryWrapperFilter is cachable by default - use Queries#wrap instead
|
|
org.apache.lucene.search.QueryWrapperFilter#<init>(org.apache.lucene.search.Query)
|
|
|
|
@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()
|