1

I have an Ubuntu 12.04 server virtual box where basically the installed software and configuration are the default ones, plus the installation of a jetty 6 server which servers a few websites. To keep things simple I didn't install apache httpd and used iptables for exposing jetty (which runs on the 8080 port) to the port 80. These are the results of

/sbin/iptables -t nat -L

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  anywhere             localhost            tcp dpt:http redir ports 8080
REDIRECT   tcp  --  anywhere             Ubuntu-1104-natty-64-minimal  tcp dpt:http redir ports 8080

Chain INPUT (policy ACCEPT) 
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  anywhere             localhost            tcp dpt:http redir ports 8080
REDIRECT   tcp  --  anywhere             Ubuntu-1104-natty-64-minimal  tcp dpt:http redir ports 8080

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

I must confess I have a shallow comprehension of how iptables works, in particular for the different kind of chains. This thing works, but sometimes I have an explosion of sockets that stay permanently in CLOSE_WAIT state. I know about what this state means, but since I didn't write the code that manages servlets (they are handled by jetty) I can't fix the problem by patching my code. Eventually the amount of CLOSE_WAIT sockets builds up and makes the server not responsive, so I have to restart jetty.

I've looked around for similar problems wth CLOSE_WAIT, and only found cases related to the programmer's code, or problems with Tomcat, not Jetty. I was wondering whether they could be related to a partially broken iptables configuration (the alternative is a bug in Jetty 6, but I first want to exclude other possible causes).

Thanks.

1

2 Answers 2

0

So far, no feedback :-( For other people who have the some trouble, I've at least been able to write a quick crontab script that detects the problem and restarts jetty. This doesn't fully solve the problem, but mitigates the effects.

#!/bin/sh

CLOSE_WAIT_COUNT=`/bin/netstat | /bin/grep CLOSE_WAIT | /usr/bin/wc -l`
TIMESTAMP=`/bin/date`
THRESHOLD=5

echo "$TIMESTAMP Reported $CLOSE_WAIT_COUNT sockets in CLOSE_WAIT state..." >> /var/log/jettyrestarter.log

if [ $CLOSE_WAIT_COUNT -gt $THRESHOLD ]
then
    echo "$TIMESTAMP Restarting jetty" >>  /var/log/jettyrestarter.log
    service jetty restart
fi
0

Another quick follow-up, just in case it can be useful for others. A few weeks ago I've upgraded the virtual server where my jetty runs, moving from one with 512MB of RAM to one with 1GB of RAM. It seems that the problems has disappeared - in the log of the jettyrestarted (see above) the latest event is from December 6.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .