How to debug Tomcat compression issue?

I have two tomcat servers on two different CentOS machines running the same application (my dev environment and my test environment). One of them had compression enabled in its server.xml and the other had not, so I added the same configuration to the tomcat which hadn't compression enabled.

The relevant part of server.xml on both of the machines looks like this:

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           compression="on" 
           compressionMinSize="2048" 
           noCompressionUserAgents="gozilla, traviata" 
           compressableMimeType="text/html,text/xml,application/json,text/plain"
           redirectPort="8443" />

Before I enabled the compression I could call both applications with Postman from my local machine with no problem (only the second response wasn't compressed)

Now that compression is enabled, when I call the second application (where I enabled compression) I get an error:

Content-Encoding Error (content_encoding_error) 

Server response could not be decoded using encoding type returned by server.
This is typically caused by a Web Site presenting a content encoding
header of one type, and then encoding the data differently.

I made several observations:

Both servers have the exact same configuration (at least I am pretty sure of that) and the first application works flawlessly.
If I call the second application with a curl command on a Unix box I get the response with no problem. (But it doesn't work with postman from a Windows box)
The response from the second application doesn't have the header Content-Encoding
The logs don't show anything work (all the requests are logged as processed with status 200, but postman show a 502 error)
The working application runs on tomcat 7.0.64 and the one not working on tomcat 7.0.76 but I haven't found anything related in the changelog between these versions.

So I am pretty puzzled as to why one server would work and not the other.

What can I check to try to find where the error comes from?

Solution

The problem came from the JDK version I was using (1.8.0.161) which contains a bug reported here, at least I think it was the same bug...

The servers didn't have the same version installed so I solved my problem by installing the working JDK of the server 1 to the server 2.