I spent some time today trying to figure out why my Weblogic domain takes FOREVER to start when running under a Linux virtual machine on my new laptop. I found a couple of things that I didn’t event think to look for. Here they are:
- I run a Ubuntu 10.04 VM on a Windows 7 host. I run Weblogic 10.3 on my VM and noticed that it took a while for my domain to start up. It took anywhere from 5-10 minutes to get to a ready state BEFORE my domain started to deploy. Java uses a randomly generated number to seed its security model. Under Linux, it gets this from /dev/random. This device uses entropy to generate randomness. /dev/random is SLOW because it waits for a sufficient amount of entropy to gather before it generates a random value. While it waits, it blocks. As a result, the domain startup blocks. /dev/urandom on the other hand is non-blocking. Using this as the source from randomness shortens the startup time. Horray!
- My project is on a Spring MVC stack and I use Eclipse as my IDE (anyone who knows me knows that I prefer Netbeans, but when in Rome…). I use OEPE since it plays well with Weblogic (in theory anyway… OEPE is still wonky when it comes to dealing with successive deployments). I noticed that when my domain did deploy, the application context restarted itself from time to time. Why? I really don’t know, but I have a theory. I noticed that Weblogic sets servlet checking to a default value for development mode. I turned this value off in my weblogic.xml file and redeployed. So far, so good… I also turned of page checking. Hopefully this makes Weblogic behave.
- I use JRebel to get hot deployments of code changes. JRebel is nice because it picks up class changes and makes them available immediately rather than having to redeploy (I still can’t believe this isnt the default JVM behavior, but hey…). JRebel phones home during startup and provides usage statistics back to the mother ship. While I am sure that performance isn’t taking a hit over this, its not needed. I turned this off using a properties file generated by the Eclipse plugin.
Now, where does this leave me? Fortunately, I’ve helped get some inertia behind moving projects to a Maven2 model. My goal is to re-organize projects into a Maven structure and leave Eclipse behind fully. This will eliminate the need to bring a bunch of tools to the table when developing as Maven and JRebel play well together. As a side effect, it might be possible to leverage a smaller application container for local development (Glassfish comes to mind). When things are nice and tight, we can promote it to Weblogic using profiles to configure for that environment.