Skip to content

Commit a079599

Browse files
committed
Silence some grammar nits from IntelliJ
1 parent 9ed7a24 commit a079599

File tree

2 files changed

+6
-6
lines changed

2 files changed

+6
-6
lines changed

x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authz/accesscontrol/DocumentSubsetBitsetCache.java

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -73,8 +73,8 @@
7373
* customisation. On a 32Gb heap, a 10% cache would be 3.2Gb which is large enough to store BitSets representing 25 billion docs.
7474
* <p>
7575
* However, because queries can be templated by user metadata and that metadata can change frequently, it is common for the
76-
* effetively lifetime of a single DLS query to be relatively short. We do not want to sacrifice 10% of heap to a cache that is storing
77-
* BitSets that are not longer needed, so we set the TTL on this cache to be 2 hours ({@link #CACHE_TTL_SETTING}). This time has been
76+
* effective lifetime of a single DLS query to be relatively short. We do not want to sacrifice 10% of heap to a cache that is storing
77+
* BitSets that are no longer needed, so we set the TTL on this cache to be 2 hours ({@link #CACHE_TTL_SETTING}). This time has been
7878
* chosen so that it will retain BitSets that are in active use during a user's session, but not be an ongoing drain on memory.
7979
*
8080
* @see org.elasticsearch.index.cache.bitset.BitsetFilterCache
@@ -171,7 +171,7 @@ private void onCacheEviction(RemovalNotification<BitsetCacheKey, BitSet> notific
171171
}
172172
// We push this to a background thread, so that it reduces the risk of blocking searches, but also so that the lock management is
173173
// simpler - this callback is likely to take place on a thread that is actively adding something to the cache, and is therefore
174-
// holding the read ("update") side of the lock. It is not possible to upgrade a read lock to a write ("eviction") lock, but we
174+
// holding the read ("update") side of the lock. It is not possible to upgrade a read lock to a write lock ("eviction"), but we
175175
// need to acquire that lock here.
176176
cleanupExecutor.submit(() -> {
177177
try (ReleasableLock ignored = cacheEvictionLock.acquire()) {
@@ -214,7 +214,7 @@ public long ramBytesUsed() {
214214
/**
215215
* Obtain the {@link BitSet} for the given {@code query} in the given {@code context}.
216216
* If there is a cached entry for that query and context, it will be returned.
217-
* Otherwise a new BitSet will be created and stored in the cache.
217+
* Otherwise, a new BitSet will be created and stored in the cache.
218218
* The returned BitSet may be null (e.g. if the query has no results).
219219
*/
220220
@Nullable

x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authz/accesscontrol/DocumentSubsetReader.java

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -195,8 +195,8 @@ public Bits getLiveDocs() {
195195
computeNumDocsIfNeeded();
196196
final Bits actualLiveDocs = in.getLiveDocs();
197197
if (roleQueryBits == null) {
198-
// If we would return a <code>null</code> liveDocs then that would mean that no docs are marked as deleted,
199-
// but that isn't the case. No docs match with the role query and therefore all docs are marked as deleted
198+
// If we were to return a <code>null</code> liveDocs then that would mean that no docs are marked as deleted,
199+
// but that isn't the case. No docs match with the role query and therefore all docs are marked as deleted.
200200
return new Bits.MatchNoBits(in.maxDoc());
201201
} else if (roleQueryBits instanceof MatchAllBitSet) {
202202
return actualLiveDocs;

0 commit comments

Comments
 (0)