On 04/03/2012 12:29 AM, Emmanuel Bourg wrote: > 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.
Not really. To be frank, overcommit is such a basic Linux feature that any container which doesn't fully support it is just broken. >>> 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. It doesn't look difficult to make authbind work with IPv6. I don't know why no-one has yet done it. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f7ac21d.6030...@redhat.com
