You mentioned earlier that there is are a number of JSRs in the works to specifically address requiring restarts for software updates. Do you have any other info on these? Like the JSR numbers? Any links to more info on this would be greatly appreciated.

I’m not sure I follow you with changing the user.dir or classpath comment. Setting up a new classloader after the application starts up is pretty common. This is the root of J2EE containers. Most applications insulate themselves in this manner so I’m not sure how this impacts restarts. I’ve found in most cases that it actually helps to create classloaders after startup because it allows you to throw them out and recreate them if necessary.

As for the user.dir thing. I can kinda see this since system properties are JVM scoped. Is that what you are referring to?

The situations where restarting the JVM is unavoidable, though, are when your program requires a different classpath than it has at startup, or when you want to change the value of the “user.dir” property. Changing either might seem like a rare thing, but it was necessary and caused quite a bit of headache during the development of DrJava, our open-source Java IDE (www.drjava.org).

I’ve tried other JVMs in the past at Orbitz and they just couldn’t handle the load and Jini gets really mad with JRockit. However, in many cases, you are probably correct.

Good call!

I disagree that it is a fact of life. I know for a fact it isn’t. You can build systems that don’t need restarts. In fact, there are a number of JSRs in the works to specifically address requiring restarts for software updates.

OutOfMemory errors are application bugs. Stuck threads and dead locks are also application bugs. Everything you’ve stated is essentially fixable. I say don’t settle for restarting a JVM because the bug is hard to fix. Plus, I think you are talking about failure scenarios and not the scheduled restarts that Matt was referring to. And on that front you are correct. Restarts (currently) are required to fix a broken system. It’s the only way to get your system up and running again. But, when crisis restarts turn into scheduled restarts, I get uneasy.

I have definitely been there with 24/7. But even with restarts you still get paged. I’d rather fix the problems so that so at least I’m only getting paged when the system is jacked and not when my restart cron has failed or worse the restarted box won’t come back up.

Hmmmmmmmm….. I guess my main concern is that system stability isn’t as simple as JVM restarts. I mean you remember when a simple restart brings an entire system down. Or worse, a simple restart means the box doesn’t ever come back up. I just tend to look at restarts dangerous and to be avoided. In most cases there are fixes.

However, now that I own my own company, I can definitely understand the trade-off between correct the fix and the cost effective fix.

So, I guess I’m looking at the fence from my air conditioned living room and you guys are on the other side. ;) At least I know there is a fence. hehe

I am not in favor of restarting due to instability problems overall, though. If the crashing service is one in which you expect growth, it tends to only defer the problem.

A weekly restart can turn into a 6 day restart (and then 5… 4… so on) for exactly that reason. And then when you do try to fix it, you find out that you’ve introduced a dozen other similar problems that you haven’t noticed because you’ve been papering over all of them.

It’s much better to deal with the problems as soon as possible. Getting woken up at 3 in the morning a few times will get them fixed even faster. :-)