| Summary: | java.io.IOException: Unexpected error [104] writing data to the APR/native socket | ||
|---|---|---|---|
| Product: | Tomcat 9 | Reporter: | slash |
| Component: | Connectors | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 9.0.43 | ||
| Target Milestone: | ----- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: | java.io.IOException stack example | ||
|
Description
slash
2021-02-22 11:45:15 UTC
Error code 104 is "Connection reset by peer". Therefore, this is not a Tomcat issue. I recommend NIO rather than NIO2 unless performance testing has indicated a clear benefit of using NIO2. Further assistance, if required, can be obtained from the users mailing list. We also have "Unexpected error [32]". And how do you explain that the switch from APR does eliminate the issue? Currently I have 2 tomcats with the exact same configuration except one is using APR and the other one is using NIO2 and I see the errors only on the first one. Also the tomcat that did have issues last week with APR doesn't have any issue today with NIO2. Anyway, thank you for pointing us to NIO, we'll check it out. Of course, you can disregard this report, we'll keep future issues to our self if they don't interest you. I thought that it would be interesting to know that such problem existed, but it seems you prefer to consider that it's simply a "Connection reset by peer", OK. This is the result on one application:
# for n in {01..22}; do echo -n "log.2021-02-${n}_09.log "; grep "Unexpected error" log.2021-02-${n}_09.log | wc -l; done
log.2021-02-01_09.log 6144
log.2021-02-02_09.log 5469
log.2021-02-03_09.log 5476
log.2021-02-04_09.log 4653
log.2021-02-05_09.log 5471
log.2021-02-06_09.log 4348
log.2021-02-07_09.log 0 (Sunday, almost 0 activity)
log.2021-02-08_09.log 2997
log.2021-02-09_09.log 4523
log.2021-02-10_09.log 4709
log.2021-02-11_09.log 4291
log.2021-02-12_09.log 5725
log.2021-02-13_09.log 3398
log.2021-02-14_09.log 7 (Sunday, almost 0 activity)
log.2021-02-15_09.log 4216
log.2021-02-16_09.log 4078
log.2021-02-17_09.log 4064
log.2021-02-18_09.log 4112
(switch from APR to NIO2)
log.2021-02-19_09.log 0
log.2021-02-20_09.log 0
log.2021-02-21_09.log 0
log.2021-02-22_09.log 0
Of course, you can say that switching to NIO2 did nothing, but I think that it did.
Error code 104 is a client disconnect. That is never a Tomcat bug. Error code 32 is a broken pipe. That error code was never mentioned in the original bug report. The Tomcat Native/APR code does not use pipes as far as I can tell although it is possible I am missing something under the covers in either the APR library or OpenSSL. If you have a test case that reproduces the 32 error on a clean install of the latest Tomcat 9 and Native Connector then please open a new bug report and provide the steps to reproduce the error and any additional information in that new bug report. If we're comparing the connectors as of right now, I would say I prefer NIO2 over NIO on Java 8, since Oracle was not fixing or improving NIO then. Now with the next LTS coming up, I would say NIO is now better since it has fixes/refactorings and new features [NIO2 does not have the new features]. On clients I would say NIO2 is always better as long as the new features are not needed. So I would have, if things don't change: Java 8: NIO2 > NIO Java 11: tie Java 17: NIO > NIO 2 This is not making things better overall ... |