Bug 50273 - AprEndpoint logs socket accept fails altough error is harmless
AprEndpoint logs socket accept fails altough error is harmless
Status: RESOLVED FIXED
Product: Tomcat 6
Classification: Unclassified
Component: Connectors
6.0.29
HP HP-UX
: P2 normal (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2010-11-15 10:39 UTC by Michael Osipov
Modified: 2014-02-17 13:54 UTC (History)
0 users



Attachments
Proposed patch for Tomcat 7 (1.59 KB, patch)
2010-11-21 14:38 UTC, Mark Thomas
Details | Diff
Binary patch for Tomcat 6 (1.95 KB, application/octet-stream)
2010-11-21 14:50 UTC, Mark Thomas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Osipov 2010-11-15 10:39:37 UTC
I use the above Tomcat on my HP-UX 11.23 system. I have compiled libtcnative 1.1.20 successfully. Tomcat is spamming my log files with this error message:

5.11.2010 09:06:29 org.apache.tomcat.util.net.AprEndpoint$Acceptor run
SCHWERWIEGEND: Socket accept failed
org.apache.tomcat.jni.Error: Kein Pufferplatz verfügbar
        at org.apache.tomcat.jni.Socket.accept(Native Method)
        at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:1169)
        at java.lang.Thread.run(Thread.java:619)

In English: No buffer space available. I googled for the problem and this out:
http://forums.devx.com/archive/index.php/t-99967.html

This bug occurs with the IE6 & IE8 on our setup. I wasn't able to filter this our with java logging, it simple ignored loading my filter.
Searching the APR docs I found this: http://dev.ariel-networks.com/apr/apr-tutorial/html/apr-tutorial-13.html Section "Detection of the remote host closed the socket"

The error seems to be harmless, a debug or info would satisfy here but in the level severe it simply spams my disk.

Is there a way to fix that according to the APR docs? I have no clue in C.
Comment 1 Mark Thomas 2010-11-19 14:05:10 UTC
We need to figure out the error number to correctly filter out this particular error. I'll take a look and see if I can figure out what it is from the Tomcat native / APR source (233 is looking like a good bet). In case I can't and for future use, I have modified the 7.0.x code to include it in the exception message.
Comment 2 Mark Thomas 2010-11-19 14:43:32 UTC
Hmm. The error code is indeed 233 but the HP-UX folks have re-used an existing error code that can also a genuine error has occurred. Therefore, we can't ignore this universally since it will represent real problems on other platforms (and possibly also on HP-UX). There is some useful info in this httpd thread http://httpd.markmail.org/thread/djrcyntamxrkulns

I have a couple of ideas for this that I need to try out.
Comment 3 Michael Osipov 2010-11-19 16:37:58 UTC
Mark,

if I can assist somehow, please let me now. I am running 6.0.x only. I can recompile a patched libtcnative and see if this works and a modified tomcat for test purposes with the current libtcnative.
Comment 4 Mark Thomas 2010-11-21 14:38:37 UTC
Created attachment 26323 [details]
Proposed patch for Tomcat 7

The proposed patch adds a separate logger for the acceptor and reduces the log level from SEVERE to WARNING if the error code is 233. This should allow it to be filtered out on HP-UX but it will still be logged by default on other platforms.
To filter these messages out, add the following to logging.properties
org.apache.tomcat.util.net.AprEndpoint$Acceptor.level = SEVERE
Comment 5 Mark Thomas 2010-11-21 14:50:02 UTC
Created attachment 26324 [details]
Binary patch for Tomcat 6

The attached binary patch for Tomcat 6 is purely for the OP to test this on their test platform. It is not an official release from the ASF. Use it at your own risk.

To test this patch, create the following directory structure under the instance's lib directory:
org/apache/tomcat/util/net
and place the file AprEndpoint$Acceptor.class in that directory. Restart Tomcat and you should be able to filter out the message using the logging configuration above. Please report back either way.

If it works, I'll apply the fix to Tomcat 7 and proposed it for Tomcat 6. It it doesn't work, then I'll provide a patch with further debugging info and we can go from there.
Comment 6 Michael Osipov 2010-11-21 15:18:51 UTC
Mark,
thanks for the the binary patch. Will test this tomorrow. Btw, the patch is incorrect. Bug Id stated in the patch has to be 50273 and not 50773
Comment 7 Michael Osipov 2010-11-22 07:40:03 UTC
Mark,

now I get this:

INFO: Pausing Coyote HTTP/1.1 on http-8443
22.11.2010 13:30:21 org.apache.tomcat.util.net.AprEndpoint$Acceptor run
WARNUNG: Socket accept failed
org.apache.tomcat.jni.Error: Kein Pufferplatz verfügbar
        at org.apache.tomcat.jni.Socket.accept(Native Method)
        at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:1170)
        at java.lang.Thread.run(Thread.java:619)
22.11.2010 13:30:22 org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina

Which seems correct. I changed the log level and will check the logs in the next couple of days. But it seems to be fixed by that.

I am just curious if the root cause of this can be fixed in APR or not? Your solution is a mere workaround.
Comment 8 Mark Thomas 2010-11-22 08:26:06 UTC
Thanks for your testing. This is good news. I'll get this fix into 7.0.x and proposed for 6.0.x later today.

Yes the solution is a workaround but while HP-UX is returning this error code for multiple errors - some of which are fatal and some of which are not - there isn't a huge amount that can be done about it.

It is probably possible to put a work-around into Tomcat's native connector or maybe even the APR library but I avoided that for two reasons:
- my C knowledge is only very basic
- the fact that the error message can't just be ignored - even on HP-UX means that an error code has to be returned to Tomcat's acceptor thread anyway which would require a work-around not dissimilar from what I already wrote.
Comment 9 Mark Thomas 2010-11-22 08:45:45 UTC
Fixed in 7.0.x and will be included in 7.0.5 onwards
Proposed for 6.0.x
Comment 10 Michael Osipov 2010-11-22 09:00:00 UTC
Great news. Thanks for the quick help.
Do you think it is worth raising a ticket at APR with a link to this one?
Comment 11 Mark Thomas 2010-11-25 12:22:25 UTC
Fixed in 6.0.x and will be included in 6.0.30 onwards.