Let me state first, my solr version is 5.5.3
In the previous blog, I said that when updating SolrIndexSearcher, it is not just calling warm-up, but also other operations, so what are they all? Look at SolrCore's getSearcher method (the one with the most parameters), if if (newSearcher ! = currSearcher) , that is, the index has changed (whether commit or softCommit is a change), not only calling the warm mentioned in the previous blog, but also the following operations:
if (currSearcher == null) {
future = searcherExecutor.submit(new Callable() {
@Override
public Object call() throws Exception {
try {
for (SolrEventListener listener : firstSearcherListeners) {//Loop firstSearcherListener, call its newSearcher method, the first parameter is the newly generated searcher, and the second is null
listener.newSearcher(newSearcher, null);
}
} catch (Throwable e) {
SolrException.log(log, null, e);
if (e instanceof Error) {
throw (Error) e;
}
}
return null;
}
});
}
if (currSearcher != null) {
future = searcherExecutor.submit(new Callable() {
@Override
public Object call() throws Exception {
try {
for (SolrEventListener listener : newSearcherListeners) {//Same as firstSearcherListener above, except that the second parameter here is the current searcher.
listener.newSearcher(newSearcher, currSearcher);
}
} catch (Throwable e) {
SolrException.log(log, null, e);
if (e instanceof Error) {
throw (Error) e;
}
}
return null;
}
});
}
The above firstearcherListener and newSearcherListener are both List<SolrEventListener>, that is, multiple SolrEventListeners. It can be concluded that when SolrIndexSearcher is switched, the newSearcher method of our configured listener will be triggered, and the parameters passed in for different names (firstSearcherListener or newSearcherListener) are still Different.
How to configure monitoring? I am referring to this blog: http://blog.csdn.net/duck_genuine/article/details/7862454 .
The specific configuration is to add the following code in <query></query> in solrconfig.xml:
<listener event="newSearcher" class="com.comall.solr.listener.HelloWordListener"> <!--This is the configured newSearcher, that is, the two parameters passed in the old and new SolrIndexSearcher --> <arr name="sortFields"> <!-- arr is encapsulated as an arraylist --> <str>title</str> <!-- str is a string --> <str>id</str> </arr> <!-- str is a string --> <str name="queryKeyFile">/Users/yzygenuine/56workspace/solr_jetty/solr/extConf/query.txt</str> <arr name="queries"> <lst> <!--lst is encapsulated as NamedList org.apache.solr.common.util.NamedList The result of the encapsulation here is my experiment --> <str name="q">solr</str> <str name="qt">standard</str> <str name="sort">price desc</str> </lst> </arr> </listener>
The code for my HelloWordListener is:
public class HelloWordListener extends AbstractSolrEventListener {//继承自org.apache.solr.core.AbstractSolrEventListener
static Logger logger = LoggerFactory.getLogger(HelloWordListener.class);
public HelloWordListener(SolrCore core) {
super(core);
logger.info("Initialize HelloWordListener");
}
@Override
public void init(@SuppressWarnings("rawtypes") NamedList args) {//Initialization, args is the configured parameter, I use this to detect the type of encapsulation.
super.init(args);
StringBuffer buffer = new StringBuffer();
Object sortFields = args.get("sortFields");
buffer.append("The type of sortFields is: ")
.append(sortFields.getClass().getName())
.append("---")
.append("The type of queryKeyFile is: ");
Object queryKeyFile = args.get("queryKeyFile");
buffer.append(queryKeyFile.getClass().getName()).append("---").append("queries的类型是：");
Object que = args.get("queries");
buffer.append(que.getClass().getName()).append(", the type of the first element of queries is: ").append(((ArrayList)que).get(0).getClass(). getName())
.append(", the first element of query is: ").append(((ArrayList)que).get(0));
logger.info("Initialization parameters are: {}", buffer.toString());
// {sortFields=[title, id],queryKeyFile=/Users/yzygenuine/56workspace/solr_jetty/solr/extConf/query.txt,queries=[{q=solr,qt=standard,sort=price desc}]}
}
@Override
public void postCommit() {
logger.info("Call postCommit");
}
@Override
public void postSoftCommit() {
logger.info("Call SoftCommit");
}
@Override
public void newSearcher(SolrIndexSearcher newSearcher, SolrIndexSearcher currentSearcher) {//Call newSearcher. From the result, both searchers are indeed passed in, and this also tests softCommit. If the index is not updated, softCommit will not Causes the registered SolrINdexSearcher to change
logger.info("调用newSearcher：newSearcher:{},currentSearcher:{}",new Object[]{newSearcher,currentSearcher});
}
}
Originally, I used this listener with great hope. My original intention was to get multiple caches through SolrIndexSearcher, and then get the statistics of these caches, but unfortunately SolrIndexSearcher did not give us a way to get these Cache (I personally hate the violent operation of using reflection). However, in this blog http://blog.csdn.net/duck_genuine/article/details/7862454 I am a little inspired - that is, we use this new searcher to do some advance searches, so that the specified warm-up cannot be achieved. Okay, but I haven't tested it myself, so I'll do some testing when I need it. http://blog.csdn.net/duck_genuine/article/details/7862454, the owner of this blog seems to have a good research on solr, and is a great god.
//The following is added later,
The above said that I did not find a way to get the cache in SolrIndexSearcher. Now I found it. There is a getInfoRegistry method in solrCore, which is to get the information of all currently registered SolrIndexSearchers. This method is called when a new SolrIndexSearcher is registered. Let's see Here's how to register:
/** Register sub-objects such as caches */
public void register() {
// register self
core.getInfoRegistry().put("searcher", this);//Call the getInfoRegistry method of solrCore
core.getInfoRegistry().put(name, this);
for (SolrCache cache : cacheList) {//The cacheList here includes all the caches we configured in solrConf.xml, such as FilterCache, queryResultCache, DocumentCache, fieldValueCache, and multiple caches customized using <cache>.
cache.setState(SolrCache.State.LIVE);
core.getInfoRegistry().put(cache.name(), cache);//Put multiple caches into the core, which will overwrite the original cache.
}
registerTime = new Date();
}
In this way, we can get the various caches of the previous SolrIndexSearcher by calling solrCore.getInfoRegistry, and then get its statistics. The newSearcher code of HelloWordListener I rewrote is as follows:
public static final String filterCache_name = "filterCache";
public static final String queryResultCache_name = "queryResultCache";
public static final String documentCache_name = "documentCache";
public static final String fieldValueCache_name = "fieldValueCache";
@Override
public void newSearcher(SolrIndexSearcher newSearcher, SolrIndexSearcher currentSearcher) {
Map<String, SolrInfoMBean> info = getCore().getInfoRegistry();
SolrInfoMBean filterCache = (SolrInfoMBean) info.get(filterCache_name);
logger.info(filterCache.getStatistics().toString());
SolrInfoMBean queryCache = info.get(queryResultCache_name);
logger.info(queryCache.getStatistics().toString());
SolrInfoMBean documentCache = info.get(documentCache_name);
logger.info(documentCache.getStatistics().toString());
logger.info(info.get(fieldValueCache_name)==null?"fieldvalueCache是null":"fieldValueCache不是null");
}
In this way, the usage of Solr's cache can be found from the console. After querying several times, submit a new document, which will call the listener. The results of my own test are:
{lookups=0,hits=0,hitratio=0.0,inserts=0,evictions=0,size=0,warmupTime=0,cumulative_lookups=0,cumulative_hits=0,cumulative_hitratio=0.0,cumulative_inserts=0,cumulative_evictions=0}//filterCache的
{lookups=26,hits=23,hitratio=0.88,inserts=3,evictions=0,size=3,warmupTime=0,cumulative_lookups=26,cumulative_hits=23,cumulative_hitratio=0.88,cumulative_inserts=3,cumulative_evictions=0}//queryResultCache的
{lookups=32,hits=22,hitratio=0.69,inserts=10,evictions=0,size=10,warmupTime=0,cumulative_lookups=32,cumulative_hits=22,cumulative_hitratio=0.69,cumulative_inserts=10,cumulative_evictions=0}//documentCache的
fieldValueCache is not null//It can be found that fieldValueCache will be created by itself, although it is not configured in solrconf.xml.