honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/core-signatures.txt

36 lines
2.1 KiB
Plaintext
Raw Normal View History

Integrate forbiddenAPI checks into Maven build. This commit integrates the forbiddenAPI checks that checks Java byte code against a list of "forbidden" API signatures. The commit also contains the fixes of the current source code that didn't pass the default API checks. See https://code.google.com/p/forbidden-apis/ for details. Closes #3059
2013-05-18 17:49:04 -04:00
@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()
Forbid usage of Character.codePoint(At|Before) and Collections.sort. Character.codePointAt and codePointBefore have two versions: one which only accepts an offset, and one which accepts an offset and a limit. The former can be dangerous when working with buffers of characters because if the offset is the last char of the buffer, a char outside the buffer might be used to compute the code point, so one should always use the version which accepts a limit. Collections.sort is wasteful on random-access lists: it dumps data into an array, sorts the list and then adds elements back to the list. However, the sorting can easily be performed in-place by using Lucene's CollectionUtil.(merge|quick|tim)Sort.
2013-06-13 03:23:01 -04:00
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)
Forbid usage of StringReader in favor of FastStringReader. StringReader is synchronized although input streams should always be consumed by a single thread at a time. FastStringReader on the other hand is completely thread unsafe. Closes #3411
2013-07-30 12:50:58 -04:00
java.io.StringReader#<init>(java.lang.String) @ Use FastStringReader instead
Add RamUsageEstimator#sizeOf(Object) to forbidden APIs This method can be a performance trap since it traverse the entire object tree that is referenced by the provided object. See LUCENE-5373
2014-01-31 15:38:39 -05:00
org.apache.lucene.util.RamUsageEstimator#sizeOf(java.lang.Object) @ This can be a perfromance trap
Add IndexReader reference counting methods to forbidden APIs.
2014-02-06 14:47:31 -05:00
@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()
Force merges to not happen when indexing a doc / flush Today, even though our merge policy doesn't return new merge specs on SEGMENT_FLUSH, merge on the scheduler is still called on flush time, and can cause merges to stall indexing during merges. Both for the concurrent merge scheduler (the default) and the serial merge scheduler. This behavior become worse when throttling kicks in (today at 20mb per sec). In order to solve it (outside of Lucene for now), we wrap the merge scheduler with an EnableMergeScheduler, where, on the thread level, using a thread local, the call to merge can be enabled/disabled. A Merges helper class is added where all explicit merges operations should go through. If the scheduler is the enabled one, it will enable merges before calling the relevant explicit method call. In order to make sure Merges is the only class that calls the explicit merge calls, the IW variant of them is added to the forbidden APIs list. closes #5319
2014-03-05 07:26:26 -05:00
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
Enforce query instance checking before it wrapper as a filter We have the default QueryWrapperFilter as well as our custom one while our wrapper is explicitly marked as no_cache such that it will never be included in a cache. This was not consistenly used and caused several problems during tests where p/c related queries were used as filters and ended up in the cache. This commit adds the QueryWrapperFilter ctor to the forbidden APIs to enforce the query instance checks.
2014-03-14 09:13:06 -04:00
@defaultMessage QueryWrapperFilter is cachable by default - use Queries#wrap instead
org.apache.lucene.search.QueryWrapperFilter#<init>(org.apache.lucene.search.Query)