fix unnecessary logger creation

[tinder-xli]

During our perf test against elasticsearch, we noticed two synchronized block in the call stack of fetching doc values, which i think is necessary and cause a serious gc issue for us, especially when "size" param is large and fetch docvalue fields.

Logger object in DocValuesIndexFieldData.java class
Each doc value fetch will essentially create an instance of DocValuesIndexFieldData class, which will create a logger object in its constructor. However in PrefixLogger class, there is a synchronized block around marker which will block the initialization of DocValuesIndexFieldData class. We noticed a lot of thread block in PrefixLogger from JFR recording, which we believe is the root cause for super long ParNew GC:

We noticed that among all the classes which extend DocValuesIndexFieldData, only SortedSetDVOrdinalsIndexFieldData class actually uses the logger, thus we are proposing moving the logger creation to this class.
We also noticed that there are quite a few other places where loggers get initialized in constructor, e.g. BulkRequestHandler.java and AbstractComponent.java. We think it could also potentially be an issue if lots of instances of such classes are created in a short period of time and suggest revisit such use cases.

gradle test all passed in my local.

For reference, below is a sample query we used for testing:

{
  "stored_fields": "_none_",
  "docvalue_fields": ["user_number"],
  "size": 33000,
  "query": {
    "bool": {
    	 "must": [
    	   {
    	   	"match_all":{}
    	   }
    	 ]
    }
  }
}

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[tinder-xli]

@jasontedor

[dnhatn]

@elasticmachine please test this.

[jasontedor]

We also noticed that there are quite a few other places where loggers get initialized in constructor, e.g. BulkRequestHandler.java and AbstractComponent.java. We think it could also potentially be an issue if lots of instances of such classes are created in a short period of time and suggest revisit such use cases.

This is not expected for either of these; it is expected that a client application using the bulk processor would not be creating many instances of bulk request handler, especially in a short period of time.

The same is true for abstract component, these are not oft-creates instances (think at the level of a system component, like an internal service).

[jasontedor]

LGTM.