Le 31/03/2012 21:10, Andrew Haley a écrit :
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?Hold on, do you see this problem outside OpenVZ? I know that there is a virtualization container that doesn't support memory overcommit, but I can't remember its name. If so, that's a big problem; Java's GC strategy really needs overcommit to work.
This problem doesn't happen outside the OpenVZ container.OpenVZ has a setting to fiddle with memory overcommit (the privvmpages parameter), but I'm not sure it'll work with a 32 bits container and 4GB assigned, the limit can't be extended.
If the JVM could allocate gradually the memory as the heap grows that would help, but I guess that's not possible.
That's probably one more good reason to replace authbind with iptable in my case. The other reason being the lack of IPv6 support.Right. I expect that every Java VM will move to IPv6, so authbind would stop working everywhere.
The sad thing is there is no good alternative yet. I realized today that ip6table doesn't support port redirection (because it works with NAT and NAT is discouraged with IPv6). The only solution left is to put a reverse proxy in front of Tomcat.
Emmanuel Bourg
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature