EarlyTerminatingCollectorException thrown during auto-warming

Our production Solr-Slaves-Cores (we have about 40 Cores (each has a moderate size about 10K documents to 90K documents)) produce many exceptions of type:

014-11-05 15:06:06.247 [searcherExecutor-158-thread-1] ERROR org.apache.solr.search.SolrCache: Error during auto-warming of key:org.apache.solr.search.QueryResultKey@62340b01:org.apache.solr.search.EarlyTerminatingCollectorException

Our relevant solrconfig is

<updateHandler class="solr.DirectUpdateHandler2">
<autoCommit>
<maxTime>180000</maxTime><!-- in ms -->
</autoCommit>
</updateHandler>

<query>
<maxWarmingSearchers>2</maxWarmingSearchers>
<filterCache
class="solr.FastLRUCache"
size="8192"
initialSize="8192"
autowarmCount="4096"/>

<!-- queryResultCache caches results of searches - ordered lists of
document ids (DocList) based on a query, a sort, and the range
of documents requested. -->
<queryResultCache
class="solr.FastLRUCache"
size="8192"
initialSize="8192"
autowarmCount="4096"/>

<!-- documentCache caches Lucene Document objects (the stored fields for each document).
Since Lucene internal document ids are transient, this cache will not be autowarmed. -->
<documentCache
class="solr.FastLRUCache"
size="8192"
initialSize="8192"
autowarmCount="4096"/>
</query>

Answer from List (Mikhail Khludnev):

https://github.com/apache/lucene-solr/blob/20f9303f5e2378e2238a5381291414881ddb8172/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L522
at least this ERRORs broke nothing see
https://github.com/apache/lucene-solr/blob/20f9303f5e2378e2238a5381291414881ddb8172/solr/core/src/java/org/apache/solr/search/FastLRUCache.java#L165

anyway, here are two usability issues:

• of key:org.apache.solr.search.QueryResultKey@62340b01 lack of readable
  toString()
• I don't think regeneration exceptions are ERRORs, they seem WARNs for me
  or even lower. also for courtesy, particularly
  EarlyTerminatingCollectorExcepions can be recognized, and even ignored,
  providing SolrIndexSearcher.java#L522

-> Maybe the log-level could be set to info/warn, if there are no implications on the functionality?