[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New work on java-package



Le 29/03/2012 14:58, Andrew Haley a écrit :
I think the problem is in authbind: it only supports IPv4.

OpenVZ comes into the equation too. The bind operation fails with the message "Cannot allocate memory". This may be related to the way authbind forks the process.

OpenVZ has the unpleasant behavior to assume that the memory allocated to a process a totally used. When Tomcat is started with -Xmx512M, htop displays a java process using around 500-600M. If the system had less than 500M of memory available, the JVM would fail to start with a memory allocation error. This doesn't happen outside an OpenVZ container.

While reading the authbind documentation I saw it was doing some fork tricks behind the scene. Maybe the forked process can't allocate its memory due to OpenVZ and quits?



Try this:

  $ authbind --depth 2 java -Djava.net.preferIPv4Stack=true ListenTest
ServerSocket[addr=localhost/127.0.0.1,port=0,localport=80]

I tried this example and it failed with sun-java and openjdk. The following error is returned:

Exception in thread "main" java.net.SocketException: No such file or directory
     at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:353)
     at java.net.ServerSocket.bind(ServerSocket.java:336)
     at java.net.ServerSocket.<init>(ServerSocket.java:202)
     at ListenTest.main(ListenTest.java:6)


I changed your class to bind to any local address (with new ServerSocket(80)) and this time it worked fine with sun-java and openjdk.

Since I suspect a memory allocation issue I played a bit with the maximum heap size. With -Xmx1700M it worked with sun-java but failed with openjdk. But at 1800M it also failed with sun-java. I refined the thresholds and found the upper limit for sun-java (1707M) and openjdk (1640M). At this time the system had about 3650M of free memory. That seems to indicate that the program needs twice the maximum heap size to start properly.

Without authbind the thresholds are higher, the program runs up to 2678M with sun-java and 2616M with openjdk.

So this issue might be simply due to a different memory usage of the OpenJDK JVM vs the Sun JVM. When I adjusted the heap size of Tomcat to the maximum possible I didn't realize it was about half of the available memory on the system. And when I switched to OpenJDK I've been bitten by the slightly increased memory usage.

That's probably one more good reason to replace authbind with iptable in my case. The other reason being the lack of IPv6 support.


Emmanuel Bourg


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


Reply to: