The symptom is similar to the one once decribed in WFLY-9397. However, this issue has been resolved for a long time.

JBoss EAP 7.4 seems to base its decision on whether to close a connection after its peer closed it upon the presence of the "Connection: close" HTTP header. Given the peer previously included this header, JBoss EAP 7.4 reliably closes the connection soon after its peer did so. But in case the peer did not include "Connection: close", i.e. the peer intended the connection to stay alive, JBoss EAP 7.4 does not close its end even after the peer closed it.

This is in my opinion dangerous as bugs or indended malicious behavior of clients can render the server unresponsive as soon as it shows too many connections in CLOSE_WAIT state, because it runs out of file descriptors.