5 Reasons Why Oracle WebLogic Server Sucks

"Oracle WebLogic Server 12c is the industry's best application server."

~Oracle website

Okay, so Oracle WebLogic Server 11g doesn't suck. The marketplace tends to agree that WebLogic Server is one of the leading Java application servers on the market. In fact, Gartner ranks Oracle as the leader in Enterprise Application Servers, so for once it's not all hype.

I've used many Java application servers throughout the years, including WebSphere and JBoss. But I'm certified in and have 10 years of experience with Oracle Application Server. So this becomes the basis of my comparison.

For those who don't know, when Oracle acquired BEA, they ended up having two enterprise Java application servers; Oracle Application Server and BEA WebLogic Server. After much analysis, Oracle decided to stick to the more superior WebLogic Server and effectively kill Oracle Application Server.

Oracle WebLogic Server is the primary underlying Java application server for the majority of Oracle Fusion Middleware products, and I've had a solid 2 years of extensive experience working with it as a result. There are definite improvements I can definitely see compared to Oracle Application Server, but I also have some major gripes with it.

In this article, I list out the 5 biggest issues with Oracle WebLogic Server 11g.

1. It is not possible to have truly highly available JMS destinations.

A JMS destination can either be a JMS queue or a JMS topic. These can be created in WebLogic Server very easily, and its reliability is excellent. JMS destinations are used extensively for integration development, particularly in point-to-point and publish-subscribe models.

Let's say that I have a 4-node cluster. I have some Java (or SOA) code deployed to all nodes of the cluster. I also have a JMS topic in this cluster.

I expect the following:

1. If I have 1 consumer to this topic, I expect that despite this code being deployed to all 4 nodes of the cluster, that the message is consumed only once. 
2. I expect that the message is equally available to all 4 nodes of the cluster, so if any 3 of the nodes fail, the message is still available and can be consumed without manual intervention.

Point #1 is not possible if you set the forwarding policy to "Replicated". Point #2 is not possible if the destination's forwarding policy is set to "Partitioned". Granted these are the only two options available to me, I pretty much can't satisfy the two basic and necessary requirements needed for high availability queues and topics.

In a clustered environment, there is no simple way to create a simple JMS destination that is targeted to all managed servers and accessible via a single JNDI. Yes, I'm aware of all the little workarounds and tricks people do, but this issue is WebLogic Server's biggest failing.

2. The AdminServer must use a floating IP address in a cluster.

In a standard Oracle Application Server 10g installation, a default OC4J "home" J2EE container is created which hosts Application Server Control, which is the primary administration console. Typically, additional OC4J containers are created to host your applications. In a clustered installation, this "home" container should only be started up on a single node. In plain English, you can only have the admin console running on only a single node in your cluster. You cannot start it up on all nodes of the cluster.

Fortunately, if that node is down, you can simply start it up on any of the other active nodes. In fact, you can configure it so that if the "home" container is down, it is automatically started up on an alternate node. Simple and sweet!

In theory, the WebLogic Server Administration Console behaves the same way... it can only be running on a single node in the cluster. But the Oracle documentation states that "the Administration Server must be configured to listen on a floating IP Address to enable it to seamlessly failover from one host to another." What this means is that if the AdminServer is running on host1 and that server crashes, the only way for it to be started up on host2 is if you have a floating IP address that is moved to that second host. Why?! Why add additional annoying and unnecessary manual failover steps?

3. A shared filesystem is required to setup a WebLogic Server cluster.

Basically, there is absolutely no way to setup a valid WebLogic Server cluster except with a shared file system. This was not the case with Oracle Application Server.

At minimum, this shared file system is required to maintain the tlogs (and other file-persistent stores that you may create) in a clustered setup. The Oracle documentation states that "you must set up the default persistent store so that it stores records in a shared storage system that is accessible to any potential machine to which a failed migratable server might be migrated."

I understand that there may be technical reasons why the shared file system is needed, but that's only because it was designed that way. It annoys me to no end to know that there is absolutely no way I can install a cluster without a decently performing NFS share.

4. The AdminServer consumes all CPU resources when a managed server has issues.

If you have your applications deployed to several managed servers, you technically don't have to have the AdminServer running. Essentially, your applications can continue to function just fine with the AdminServer down. This is typically the case with most Java application servers out there.

The AdminServer constantly pings the managed servers to obtain realtime metrics, health information, and statistics. Yet it baffles me that when certain issues happen on one of the managed servers, the AdminServer spins out of control and starts occupying over 95% of the CPU.

So you're telling me that if I have 3 separate managed servers, each hosting completely separate applications, and one of them behaves erratically, that the AdminServer will consume the entire CPU, thus adversely affecting my other independent applications? Yes! That's what happens!

5. It is not possible to handle stuck threads, which occurs quite regularly.

The Oracle documentation states that "WebLogic Server checks for stuck threads periodically." So what is a stuck thread really? All I know is that when I have a stuck thread, I get a "Warning" on my managed server as seen below.

So what am I supposed to do now exactly?

Get this, I tried deploying some code and it hung. I saw a warning similar to what you see above and after some investigation, I confirmed that there was a stuck thread due to the deployment. Ummm... okay? Now what? My deployment is hung, all subsequent deployments are also hanging, and I have no choice but to restart the managed server. So is that the solution every time?

I'm glad that WebLogic Server (compared to Oracle Application Server) gives me the ability to track down what code is associated with the stuck thread, but in almost all cases, I end up having to restart the managed server. I'll admit that I can't talk about the specifics on how threads exactly operate and behave behind the scenes by the engine, but as an administrator, I frankly am at a loss as what to do in this case.

-----

I'm not trying to bash Oracle WebLogic Server here, but these issues need to be looked at in future releases. Over the years, the Oracle Database has continuously been improved to simplify the administration on the DBA by introducing features that automate database management. I hope the WebLogic Server product development team follows their lead.