/metrics output got truncated on Japanese locale

[fmhwong]

We recently got a PMR (TS001217448) on the mpMetrics endpoint /metrics and the response got truncated when Japanese locale was used. L2 found https://www-01.ibm.com/support/docview.wss?uid=swg1PM71666 and we worked around the problem.

The question is whether application code should explicitly close the Writer or not.

open-liberty/dev/com.ibm.ws.microprofile.metrics/src/com/ibm/ws/microprofile/metrics/writer/PrometheusMetricWriter.java

Line 244 in b2286b2

writer.close();

Should writer.close() be changed to writer.flush() in line 244?

I emailed Manuel Saldana and Phu Dinh.

Here is the reply from Manuel Saldana:
Since this is primarily Web Container code, I think it would be to our benefit to include Phu Dinh in the conversation. Looking over the code, the issue seems to be in how the JDK eventually handles multi byte characters. The client could be told that there are less bytes to read than what will actually be sent. The close method looks to be calling flush at the very end of its instrumentation. As such, I'm not convinced that doing flush, without setting the custom property, guarantees that the issue is avoided. What the custom property does is set the content length header and set the commit flag immediately after, but before calling flush. If flush is called without the property, then I do not see any special consideration made on the content length header.

Here is the reply from Phu:
You may want to test out with flush() to see what happen. The main point to focus on is whether the content-length header is set or not when you change to flush(). Some customers are sensitive to the content-length VS chunked response (due to performance).

With the custom property set, we skip the setting for content-length header but still call flush(). The content-length will eventually set automatically at the end.