Open henning-gerhardt opened 1 week ago
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.
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.
I looked into the used EntityUtils
and the HttpEntity
classes. HttpEntity
writes for the [getContent()](https://www.javadoc.io/doc/org.apache.httpcomponents/httpcore/4.4.12/org/apache/http/HttpEntity.html#getContent()) method:
Returns a content stream of the entity. [Repeatable](https://www.javadoc.io/static/org.apache.httpcomponents/httpcore/4.4.12/org/apache/http/HttpEntity.html#isRepeatable()) 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](https://www.javadoc.io/static/org.apache.httpcomponents/httpcore/4.4.12/org/apache/http/HttpEntity.html#isRepeatable()) 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.
Describe the bug
On setting up a new system the log level for the
org.kitodo
namespace was set totrace
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 toinfo
fororg.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 methodgetServerInformation
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 isdebug
ortrace
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 usedEntityUtils.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:
org.kitodo
ororg.kitodo.data.elasticsearch.KitodoRestClient
in the log4j2 configuration fileExpected 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 generalorg.kitodo
to avoid this issue.