Archive

Archive for January 27th, 2009

IPv6 Setup

January 27th, 2009 1 comment

I received an email today from Jeremy Visser asking me how my blog is set up for ipv6. So intarwebs, here’s how my system works.

The server that hosts this blog is sitting in my living room connected via a router to Comcast cable Internet access. It runs a bunch of services, such as ejabberd for my xmpp server, postfix with courier for email, apache and PHP with Suhosin and XCache which hosts WordPress, mysql, and tomcat for whatever random Java webapps I’m playing with at the time.

All of the services are ipv6 enabled. For ejabberd, just add “inet6” to each listen socket. For postfix, apache, and mysql, no additional work was necessary. For tomcat, ipv6 support should work, but I run tomcat so it listens only to localhost, and access it via mod_proxy_ajp from apache, so I haven’t looked at that too much.

The router is an Asus WL-500gp running OpenWrt. Since Comcast doesn’t provide ipv6 address to their customers, I use a sixxs.net tunnel via aiccu (my tunnel type is “heartbeat” because my ipv4 address is dynamic). I then use radvd to advertise the ipv6 subnet to the other computers on the lan (such as my laptops and server). You can find a guide for how to get an ipv6 tunnel going on an OpenWrt at OpenWrt’s wiki.

Comcast blocks incoming port 25, so I can’t just run my mail server the simple way, unfortunately. To get aroud this, I have postfix listening for deliveries on a different port (8025), and I use Roller Network‘s “SMTP Redirection” service. I set the MX records for my domain to rollernet’s mail servers, then rollernet’s mail servers deliver the mail to my server on a different port. Currently, rollernet’s mail servers do not have AAAA records, but I have asked for this feature, and rollernet is usually pretty awesome, so I bet I’ll have ipv6 enabled incoming mail very soon. For outgoing mail, rollernet’s mail relay servers (which I have to use, as most mail systems automatically reject mail from personal ISPs as spam) try ipv6 delivery then ipv4; also, the relay servers do have AAAA records to my server sends mail using ipv6.

Rollernet also provides ipv6-enabled DNS services. I simply set my nameservers in my registrar to point to rollernet (rollernet’s nameservers are ipv6 enabled, which from what I understand, is rare), and start adding DNS records. I added AAAA records for my server, and clients without ipv4 connectivity can reach my web site entirely over ipv6. The same applies for XMPP.

I have certainly learned a lot about networking from my ipv6 experiment. First, most applications already support ipv6, and need no additional configuration, or at most, very little. Second, setting up an ipv6 server is not terribly hard; just get a tunnel, a subnet, and advertise it. Third, finding a DNS hosting service that is ipv6 enabled is very difficult – rollernet was the only one I could find when I started by search last year – I hope that situation improves soon. Of course, even if ipv6 DNS services do proliferate, I’m not switching away from rollernet, as their customer service is great, technical ability is outstanding, and pricing is unbelievable good. But that’s a story for another post.

And finally, I’m working on the Hurricane Electric IPv6 Certification.

IPv6 Certification Badge

IPv6 Certification Badge

Categories: Uncategorized Tags:

Preventing java.lang.OutOfMemoryError: unable to create new native thread

January 27th, 2009 2 comments

Artifactory is a Maven repository manager that does a lot of really useful things, such as cache maven artifacts (which saves external bandwidth and makes downloads faster) and stores our own artifacts (such as 3rd party software that can’t be on a public maven repository for licensing reasons). I recently upgraded from Artifactory 1.2 to 2.0.0, which was pretty painless.

The problems appeared the next day, when the application died with “java.lang.OutOfMemoryError: unable to create new native thread.” I tried a lot of things, but what worked was reducing the stack size. The JVM has an interesting implementation, the design of which I don’t completely understand, but the implication is that the more memory is allocated for the heap (not necessarily used by the heap), the less memory available in the stack, and since threads are made from the stack, in practice this means more “memory” in the heap sense (which is usually what people talk about) results in less threads being able to run concurrently.

To reduce the stack size, add “-Xss64kb” to the JVM options. I suggest you start with 64k, try the application, then if it doesn’t work (it will fail with a Java.lang.StackOverFlowError), increase the stack to 128k, then 256k, and so on. The default stack size is 8192k so there’s a wide range to test.

Also, on Linux, you’ll need to set the Linux thread stack size to the same value as the JVM stack size to get full benefits. To do that, use “ulimit -s <size in kb>”. In my case, Artifactory works great with a 128kb stack, so I used “-Xss128kb” for the JVM options and “ulimit -s 128” to set the Linux stack size. Note that the stack size applies per user, so you have to modify the init script, or edit /etc/security/limits.conf (on Debian/Ubuntu at least).

Categories: Uncategorized Tags: