Ready for prime time?
Monday, March 31st, 2008Ok, ok… so it’s been a while since I had a chance to blog, but I have two good excuses. The week before last, I was at AjaxWorld, giving a presentation and meeting a bunch of interesting people. The conference was very fruitful, but they didn’t have wireless! :-/ Anyway, thanks to everyone who came out to my presentation (all 10 of you ;-)), even though it was 5:20pm after a day that started with 7:00am keynote.
Last week, I was sick and a bit dazed, so I figured it was a good time not to blog a fever-inspired rant. 
This week, I’ll be at the MuleCon in San Francisco, checking out the cool things that people are doing with Mule. One of the fun things we did was to integrate Resin IoC with Mule so you can pull down objects configured in Resin IoC natively in your Mule configuration. If you’re going to be at MuleCon, let me know and we can meet up.
Next Monday is our Quercus tutorial at the Java Meetup group in San Francisco. The guest list is full! I’m excited, but if for some reason you can’t make it or didn’t sign up in time, I’ll be posting the presentation here afterwards.
Anyway, today I bring you a nice little gem from Scott on the Resin-Interest mailing list (you are signed up for it, aren’t you?). Someone asked how to prepare their Resin installation for “prime time” and Scott offered up these very cool suggestions:
- The default <dependency-check-interval> should be raised to a minimum of 60s or even larger.
- If you haven’t already profiled your application, remember that Resin’s /resin-admin has a profile tab. It’s surprisingly
lightweight, so it’s possible to use even on a production machine. It’s always a good idea to be aware of where your application is
spending its time. - Take a few thread dumps using the /resin-admin, so you get an idea of the baseline behavior. If something does go wrong, you’ll want to be able to distinguish the normal behavior from the unusual. It’ll also get you in the habit of taking thread dumps, for a freeze or CPU spike.
- On Linux (and other Unix), check your file descriptor max with uname -a. The defaults are surprisingly low.
- Remember that threads need virtual memory, too. That’s an issue for 32-bit systems. 1024 threads x 1m stack size = 1G memory.
- Become familiar with the jconsole view (or some other jmx admin).
If you do these and have a support question, we’ll be in a much better position to help you out. In fact, these steps will be helpful in getting to know your system even better. If anyone else has suggestions on how to prepare a system for prime time, please comment!