TRACE Log Level in KitodoRestClient results in not usable application

[henning-gerhardt]

Describe the bug

On setting up a new system the log level for the org.kitodo namespace was set to trace to see issues in detail. In general this is a not bad idea but it cause now a new issue: "The elastic search server is not running." message. But the Elastic Search server was running and even accessible. Configuration was correct as same configuration on an other system was working. As on trace log level a lot of messages appear maybe the right message was overseen. So I changed the log level to info for org.kitodo and restarted the application. Now the Elastic Search server was available and the index could be created.

After some testing the issue must be in the class KitodoRestClient as through the method getServerInformation the error text is displayed or not (side note: the message is not translated!). Digging deeper in the class all access to the Elastic instance are concentrated in the method performRequest which as an interesting logging statement. If the log level is debug or trace a debug message (even in the trace case!) is created but only in the trace case the message of the not running Elastic server appears. The used EntityUtils.toString(response.getEntity()) is there called to get the response body information which get logged. But this call is closing or destroying the response body of the executed request so the response body can not used later like in many places in this method.

To Reproduce
Steps to reproduce the behavior:

1. Set the logging for org.kitodo or org.kitodo.data.elasticsearch.KitodoRestClient in the log4j2 configuration file
2. Start the application and switch maybe to the indexing tab of the system page
3. See the message "The elastic search server is not running." and no other information like how many data sets are indexed or not.

Expected behavior
Setting log level to TRACE should not influence the application in such way. More log information are okay but not a unusable application.

Release
3.7.1 (and maybe before), master Branch

Additional context
Do not use the TRACE log level for the class org.kitodo.data.elasticsearch.KitodoRestClient or general org.kitodo to avoid this issue.

[matthias-ronge]

That's a surprise. I've never had any problems. The output to the log was just to see what's going through the interface. If it causes an error, we need to remove the functionality. It's not important.

[henning-gerhardt]

I think that the call EntityUtils.toString(response.getEntity()) is causing this issue. I don't know if this behaviour is descripted in any way.

I know such a behaviour from an other language: if I access there the body content of a HTTP response object the internal pointer to this body data is set to the end of the body data and any future call to the response body content is returning an empty string. If I want to access the whole response body again I must reset this pointer to the beginning of the response body. In most cases this is not necessary but there are some cases where this must be done.

// edit: maybe cloning this object before using it in the EntityUtils.toString() method could solve this but cloning objects could be difficult if this objects are complex.

[henning-gerhardt]

I looked into the used EntityUtils and the HttpEntity classes. HttpEntity writes for the getContent() method:

Returns a content stream of the entity. Repeatable entities are expected to create a new instance of InputStream for each invocation of this method and therefore can be consumed multiple times. Entities that are not repeatable are expected to return the same InputStream instance and therefore may not be consumed more than once.

Its looks like that in our case the used Entity is not repeatable, which can be checked with the isRepeatable() method and so the content could not be retrieved a second or third time.