Tag: Weblogic

Configuring Multiple Weblogic IIS Plug-Ins On Same IIS Server

As some of you may know, I’ve been working on a deployment of BEA Weblogic these past couple of weeks. We were doing some testing today and found an interesting side effect that was positively unexpected. Let me first say that the issues we encountered were with IIS configuration, not specifically with Weblogic. However, the … Continue reading “Configuring Multiple Weblogic IIS Plug-Ins On Same IIS Server”

As some of you may know, I’ve been working on a deployment of BEA Weblogic these past couple of weeks. We were doing some testing today and found an interesting side effect that was positively unexpected. Let me first say that the issues we encountered were with IIS configuration, not specifically with Weblogic. However, the issue wouldn’t have come up if we weren’t working on configuring the BEA-provided iisproxy.dll IIS plug-in.

Here’s the issue: We want to configure our production server to run two sites. The primary site is the production site and the secondary site is a staging site which we’re going to try to configure to behave exactly like production and have a configuration that matches production as well. So, we want to have two separate Weblogic Domains (that listen on different ports) and two separate IIS servers (that listen on separate ports). The desired configuration looks something like this:

Continue reading “Configuring Multiple Weblogic IIS Plug-Ins On Same IIS Server”

Configuring Weblogic For Restart After Reboot on Windows

I have been working on a customer project involving new installations of Oracle Database (a two-node failover cluster using Oracle Clusterware–good stuff) and two load-balanced BEA Oracle Weblogic servers for the middle tier. The middle tier environment runs on Windows Server 2003 Enterprise x64 Edition and is managed by an outsourced hosting facility. I had … Continue reading “Configuring Weblogic For Restart After Reboot on Windows”

I have been working on a customer project involving new installations of Oracle Database (a two-node failover cluster using Oracle Clusterware–good stuff) and two load-balanced BEA Oracle Weblogic servers for the middle tier. The middle tier environment runs on Windows Server 2003 Enterprise x64 Edition and is managed by an outsourced hosting facility.

I had worked with Weblogic before this project, but not on Windows and I was a little surprised by the difficulty finding relatively simple information on BEA’s support site as well as in their documentation.

<rant>I have to say that I’m pleased that Oracle closed this deal so that (I never thought I’d say this) they can make BEA’s support as good as Oracle Support and Metalink. I know it will take quite a while–probably 6-12 months–but it absolutely needs to happen. It’s little reminders like these that make me glad I work with Oracle (or the companies they ultimately buy) and not other software. I’m as guilty as anyone of not knowing how good we Oracle professionals have it when it comes to good, well-organized documentation, a solid support site with a killer knowledge repository (with an awesome search), and a warm, active community of users (too many “thanks to” to mention at this point).</rant>

Back to the reason you’re reading: this post will summarize what turns out to be the relatively easy changes required to ensure that your Windows-based Weblogic managed servers will start up at boot time.

When creating a new Weblogic Domain on Windows, you’ll sometimes have the opportunity to choose the Sun JDK or BEA JRockit JDK to use for your domain’s Java engine. Be conscious of which one you choose (for WL 10.0, it’s on the screen where you choose a Development or Production configuration). I chose BEA JRockit for my environment’s servers because on 64-bit Windows, it’s the only one supported. For 32-bit Windows, you have the option to use Sun’s JDK, but then we’d have a mix and more potential for new bugs to pop up due to the JDK differences. There’s a small change in this process when using Sun’s JDK versus BEA JRockit and I’ll note that as well.

To ensure that your Windows-based BEA Weblogic Managed Server(s) start at boot time, follow these steps:

  1. After creating the new domain and the new Managed Server (Managed Server is a Weblogic term to identify the differences between an Admin Server and the application server where applications should be deployed), modify the Managed Server settings.
  2. Lock & Edit the configuration and proceed to Environment > Servers > (name of your Managed Server) > Configuration tab > Server Start subtab. Then scroll down to the Arguments box and enter -Xnohup in the box. If you’re using Sun’s JDK instead of BEA JRockit, enter -Xrs in that box instead. This is documented at http://edocs.bea.com/wls/docs100/server_start/nodemgr.html#wp1101004.
  3. Once that’s in place, you can Activate Changes.
  4. The admin server says that no restarts are needed, but I would restart it just to make sure. I’m not sure how the admin server can change a JDK flag without restarting the application server. Maybe I’m just not knowledgeable enough to know how it works, but I think it’s just not smart enough to know that you *do* have to restart.
  5. The last change was the one that I missed initially. Briefly, the reason I missed it was that it has to do with crash recovery and in my opinion, a server reboot shouldn’t cause an application server to crash, so I ignored this part of the documentation. One has to ask why you wouldn’t want crash recovery enabled by default anyway, but that’s probably for another rant some other day. Anyway, the final change is to modify a property for the node manager process. Edit BEA_HOME\wlserver_10.0\common\nodemanager\nodemanager.properties and set CrashRecoveryEnabled=true (it is in the file set to false by default). Save and exit the editor.
  6. This is Windows, so go to the Services control panel and restart the BEA Products NodeManager service to put the change into effect.
  7. Ensure that your managed server is up and running. Then, test the changes you’ve made by rebooting the node and see that your managed server restarts after the reboot is complete (and you’ve given time for node manager to start the managed server).

If you have problems, check the node manager logfile (BEA_HOME\wlserver_10.0\common\nodemanager\nodemanager.log) as it will be most useful in determining what happened. If you don’t see any hint that it even tried to restart the server after the reboot, then it’s probably because the crash recovery setting is not enabled–make sure you changed the right thing in the right file.

I didn’t test to see if this process will restart the admin server as well, but I think it probably will or at least should. With a production configuration, you have to enter the username/password for the admin server when starting it, so you may have to store that in the admin server configuration, but that should be a relatively easy fix. In my case, we didn’t want our admin server running all the time and only start it when needed, so having it start after a reboot wasn’t necessary or desired.