From the Cluster Topology page of Enterprise Manager Application Server Control, you get a hierarchical view of your OC4J Instances and their applications. You can click into each to undeploy, but sometimes you want to undeploy multiple applications (like multiple human tasks from your undeployed BPEL processes — since the BPEL Console undeploy does not actually undeploy the human tasks). Here are a list of steps that would allow you to undeploy multiple applications from oracle application server:
- Login to oracle “Application Server Control”
- Scroll to Groups tab
- Select the proper “OC4J Instance”. The instance that contains you deployments.
- Click on the “Applications” tab
This window allows you to start, stop, undeploy or redeploy mutliple applications.
Our friends at Oracle give us a nice list of requirements for their Application Server and Portal products, to help us define to our customers what is needed to run these mammoths of ability and power. But can you make it run on less? And if so, how much less?
NOTE - ORACLE does not condone or recommend any of the following practices. In a real production environment, I agree. This was done as a test to see if it could be done.
Oracle says that to run Application Server 10g you need a few things. For this post, we are on the Windows Server OS. It is put forth you need to be on at least SP1 of Server 2003, Have a minimum 300 MHz CPU (although they recommend a 450, and really recommend 2 GHz and up), and 1 GB of RAM, on an NTFS file system. There is of course the need for a Network interface, and some other ancillary items, but above are the core hardware specs, pulled from their installation documents.
If I said you could make it work in 640 MB of RAM, at 1.4 GHz of CPU on a desktop motherboard, you might say I’m crazy. Well it can be done, and has been done. The trick is to understand what Oracle needs to install, and how to give it that, or make it think it has it.
The OS itself needs to be as lean as it can get. If you don’t need it, don’t enable it. This goes for server roles, as well as secondary applications. Since Oracle installs Apache, you don’t even need to enable Web server functions. The less you have to install the better. The breakdown is below for how I made this work.
Your primary enemy is timeouts. They alone can bring an otherwise perfect concept to it’s knees. Also, you need to know what it is you really need installed. Obviously, to run Portal as well as OAS, you need the full Infrastructure with Identity Management installed, not much option there, and that usually will install without much issue. The trick is in Portal itself. Installing the Portal system gives you many options, and many packages they need to be deployed and setup, and as anyone who has done this knows, if it fails, it UN-deploys anything in process. Portal deployment is where most of the timeouts tend to occur in this build.
The fix? Once the infrastructure is in, and running (and for safety sake, a backup made) the timeouts need to be increased, doubling them usually works, in some cases tripling them is better. If there is a retry setting available, bump it up a notch or two. While it seems crazy, the object is to get it to install. Tweaking them back down can be done once it’s up and running. Also, look into limiting the number of connections, and the settings that affect, or are affected by those numbers. Also don’t shy from touching the settings that dictate how much RAM Oracle looks for and allocates itself at start-up. ORACLE says not to touch them for the record, but by reading the documentation carefully, for the purposes of NON-PRODUCTION systems, you have a little wiggle room. For the install referenced here, the Web Cache, J2EE, Portal and Wireless options were installed, Business intelligence was left out, as even with the increased timeouts, the system couldn’t handle the load.
Now yes, this does make your normal 90 minute install of OAS and Portal take upwards of 3-4 hours, but it will take. Of course, backup the whole system once it’s in, and then go back to tweaking the timeouts back down. Surprisingly, you can actually get the system to respond well to external requests, even though the console itself runs very slow. In my configuration, the external response time was only about 5 seconds (most people say the average net person is willing to wait 3 for a response) for most pages.
The end result is a basic install of OAS and Portal, on the same box, ready for dev work or process testing. Obviously, given the limited resources, you can’t have more than about 10 concurrent users or even then the tweaks stop working and the system grinds to a halt.
The system this was built on had this for hardware:
-Intel d850 desktop mainboard, 1.4 GHz Pentium CPU, 640 MB of RAMBUS PC800 RAM
- Linksys 10/100 PCI Network Card
- Matrox Millennium G550 AGP Video
- Maxtor 20 GB UDMA100 Drive (system/ pagefile)
- Maxtor 10 GB UDMA 66 Drive (apps/data)
- Mitsumi 52x CD-Rom
Configured with each hard drive as a Master on each IDE chain, with the CD-ROM on the Secondary Slave channel. No audio whatsoever. Windows bundled video driver for video, and Linksys installed network drivers. Primary hard drive dedicated to OS and a fixed size 2GB swap file. Diskeeper installed as only other program on OS. IIS Lockdown was run, and Frontpage extensions enabled. No server roles defined. Set to optimize network traffic. Secondary drive dedicated to Oracle applications and data storage (didn’t have a 3rd drive to use for that). CD-Rom disconnected once system install complete to get every last drop of I/O out of the controllers.
Oracle was configured with only 5 users (above the built in ones) at varying levels of access privileges. Portal was upgraded to 10.1.4 and a custom front-end page was built for the Portal system. No support was purchased from Oracle, so no effective DB tuning could be performed. After each major component was installed, a complete defragmenting was performed, and a backup made.
I don’t recommend this type of exercise for the faint of heart, but it was a fun challenge, and taught me a lot about how some of the internals work together in the Windows platform Oracle install to make it all happen.
We had an issue where BAM stopped working after installing SOA Suite on a Windows 2003 Server (BAM only runs on Windows at the time of this writing). After trying to uninstall/reinstall many times ourselves, Oracle Support suggested that this was not a compatible configuration. We have done it before (in play environments), but this clearly can cause some issues that are not easy to resolve. So, in this case, we ended up splitting the installation to different machines and have been sleeping much better at night.
I wanted to note that our team received an error when managers logged into the Worklist Application on one of our implementations. There is very little information available for this online, but we were able to work with Oracle Support to get a patch. So, if you experience an error like the following, reach out to Oracle Support or even us. We’ll be happy to help.
Internal Error in Verification Service for user ADAM. getRoleBasedGroupActions.
If you need more information, please check with your administrator with the following exception-identifier:
“2007/09/28_10:43:42:782_ADAM”
Note: We had this error using BPEL 10.1.3.1, but we understand this could still exist in version 10.1.3.3. We were running on Red Hat Linux.
I have been involved in the Fusion Middleware 11g beta program as well as participating in other ways as a member of the Advisory Board for Oracle Portal and Oracle SOA Suite. Although I can’t say much, I can tell you that there is some exciting new features coming for developers, administrators, and end-users.
Oracle Fusion Middleware 11g will prove to be a very large release that is both deep and broad. As more information becomes public (or I am authorized to share more), I will do so on this blog.
Until then, just get ready.