WebLogic Server

Digg This!

BEA's name is synonymous with the application server. Most applications running on Unix in North America run on BEA's WebLogic server, particularly financial apps. The current stable WebLogic 8.1 version does a lot more than earlier versions. Migrating to new versions is always challenging and risky, but is done for efficiency and new capabilities, and to stay current with a vendor's products and support.

Most applications developed on the WebLogic 6.1 used JDK 1.3 or earlier. A move from WebLogic 6.1 to 8.1 means making our applications compatible with JDK 1.4.1 or higher since WebLogic 8.1 shipped with JDK 1.4. Most of the common migration hazards are discussed at bea.com. I am going to share few personal observations.

These will be our discussion points.

• 6.1 to 8.1 migration, the current application scenario
• Common upgrade issues
• Getter and setter methods
• Serializable objects
• WL cache
• Tweak JVM memory usage
• Page directive with language attributes
• Java.net.SocketException: Too many open files
• Miscellaneous issues

6.1 to 8.1 Migration - The Current Application Scenario
Our application will be migrated to WebLogic 8.1. The current environment is:
Operating System: Solaris 5.8 P4
WebLogic Server 8.1P2
Java Release 1.4.2_06
Actuate 7.1SP6
Popular RDBMS and it has no impact on migration
Struts1.1 Framework
Model II Web Architecture

Common Upgrade Issues
Common issues in migrating from WebLogic 6.1 to 8.1 like class path, system path, environmental variables, data sources, deployment, JSP parsing, security, server configuration, and XML parsing are discussed in length at www.bea.com.

For example, take XML parsing. Unlike WebLogic 6.1 and earlier, WebLogic 8.1 doesn't tolerate encoding errors. So modify encoding from Unicode to utf-16.

Also there are no more JSP recompilations so the following lines have to be removed from the web.xml.

  <servlet>
    <servlet-name>JSPClassServlet</servlet-name>
    <servlet-class>WebLogic.servlet.JSPClassServlet</servlet-class>
  </servlet>

  <servlet-mapping>
    <servlet-name>JSPClassServlet</servlet-name>
    <url-pattern>*.JSP</url-pattern>
  </servlet-mapping>

Getter and Setter Methods
Applications running under WebLogic 8.1 use JDK 1.4 or later. So when we migrate from WebLogic 6.1 to 8.1, we are obviously moving to JDK 1.4.1 or later. The later versions of JDK adhere to stricter Java specifications, which means that any improper code that may have worked well under earlier JDKs can cause errors in the JDK 1.4.1 and later.

For example, there was an error in using tag library uri='/WEB-INF/tlds/taglib.tld' prefix='j2ee': There is no setter method for property 'Items' for Tag class 'com.sun.j2ee.apps.application.taglib.list. SearchListTag' probably occurred because of an error in /template.JSP line 8: <%@ taglib uri="/WEB-INF/tlds/taglib.tld" prefix="j2ee" %>

This failure occurs in JSPs and beans that are subject to the Introspector API. One good example is getter and setter methods. If the setter is an integer, the getter must be an integer too, and can't be a string.

Serializable Objects
To support the replication of an Http session in memory, all object data have to be serializable. Otherwise session replication would fail. When debugging is enabled, WebLogic outputs a warning message indicating that the session hasn't replicated:

"Failed to replicate non-serializable object"

If this happens, find the page throwing the error and make sure that all the data put in the session is serializable. Every object stored in the session has to implement a serializable interface for replication to happen.

WL Cache
The cache always has to be removed from each node for WebLogic to pick up any revised code using scripts. (Normally there are multiple nodes in a production environment for contingency, fault tolerance, and load balancing.) The WebLogic 8.1 server cache tag has attributes such as timeout, scope, key, async, name, size, and flush. When flush is set to true, the cache is flushed. A simple cache tag is shown below:

<wl:cache>
<!--the content between these tags will only be
 refreshed on server restart-->
</wl:cache>

Using a cache tag forces the cached values to be erased every time fresh values are calculated. The cache must be named with the name attribute. The size attribute will flush all values; the key attribute will flush specific values. WebLogic 8.1 has two versions of cache and this gives us the option of using the soft references for caching to avoid excessive use of the system memory. However, we can't use soft references when WebLogic is running in the Hotspot VM.

Tweak JVM Memory Usage
If the new environment has a JVM with a limited heap size then the files will have to be refactored. If we try to incorporate lots of content on a JSP page, it will have JVM memory problems. We all know that the JSP gets compiled into a servlet as a single method. If there are more tags, then the servlet method will be too big for the JVM to understand. In that case, the user will see an error saying, "Illegal target of jump or branch." It means that the JSP has exceeded the size and has to refactor them.

One solution is to increase the JVM's heap size to a higher value if more memory is required to run the files. Increasing the heap size can reduce delay and add stability. So, on the JVM options line in the binTogether.bat file, change -Xms64m to -Xms256m (or higher).

Another solution is to break a big page into many smaller pages and bring them together at runtime using include. Using <%@include> won't work because that's a compile-time include.

Still another approach is to look for places to save the tags. For example, the tag <html:option>, which was extended to let the text display. You can replace this:

<Html:option ... ><bean:message key="foo"/></html:option>

with this:

<html:option ... key="foo"/>

The more cases of this type there are the better the situation. Besides the <html:option> tag, some other struts tags are shortcuts to including the text. You might also consider replacing <html:option> sequences with <html:options> if you can build an appropriate collection upfront.

One resolution is to have our own tags. Changing some frequently used tags by extending BodyTagSupport to extending Tag Support and marking them with <body content>empty</body content> in the .tld file significantly reduces generated code size. This may not always be the way out, but it helps.

Whenever the JSP is too big, one must set the variable com.sun.tools.javac.main.largebranch to true.

In that case, you have to use JRocket, which is bundled with WebLogic 8.1. It can handle memory better than the JDK.

Page Directive with Language Attribute
In some JSP code, the value for attribute language is specified multiple times. This worked in WebLogic 6.1 but in migrating code to WebLogic 8.1, we can specify the values only once or else it will throw an JSPException as required in the J2EE specification.

Java.net.SocketException: Too Many Open Files
Just after converting to WebLogic 8.1, the server is going to go down and send the following message. It may not be related to the migration, but it has to be resolved.

<Critical> <WebLogicServer> <BEA-000204>
<Failed to listen on port 7001, failure count: 1, failing for 0 seconds,
java.net.Socke tException: Too many open files>

An immediate step to take is to increase the rlim_fd_max to 8192 in /etc/system. But this can lead to the usage going up to 7000 and may not prove a solution.

The best thing to do is fine-tune the TCP parameters on the operating system.

Java.lang.OutOfMemoryError
The error is Runtime Exception trying to execute a procedure using Sybase Pool in WLS 8.1 SP3. This error occurrs when we use WebLogic 8.1 SP3. BEA recognized this issue and it is now fixed in the WebLogic 8.1SP4 (CR196372). For those who would like to use 8.1SP3, BEA is providing a patch by means of a JAR file.

Miscellaneous
a) Page directive with language attribute
In some JSP code in some files the value for the attribute language is specified multiple times. This worked in WebLogic 6.1 but in migrating to WebLogic 8.1, we have to be sure to specify the values only once or else it will throw an JSPException in compliance with the J2EE specification.
b) Deploying the application in Staging Mode
WebLogic 8.1 lets applications be deployed in multiple modes depending on the situation. In deploying on a single server the domain always use the no_stage mode pattern.
c) Defining context root
Ours is a standalone application, the snippet below should be added to the web.xml.

<context-root>isoft/iSoft</context-root>

Summary
In all applications, code compliance with J2EE specification is mandatory regardless of the application server guidelines.

References

www.serverwatch.com/tutorials/article.php/10825_3418341_2

www.bea.com/framework.jsp?CNT=wpabst00014.htm&FP=/content/newsevents/white_papers

http://e-docs.bea.com/wls/docs81/upgrade/quickupgrade.html

http://developer.bea.com/products/wlserver81/articles/JSP_reloaded.jsp

http://support.bea.com/support_news/product_troubleshooting/Too_Many_Open_Files_Pattern.html

http://e-docs.bea.com/wls/docs81/notes/resolved_sp04.html

http://e-docs.bea.com/wls/docs81/deployment/overview.html

http://e-docs.bea.com/wls/docs81/webapp/web_xml.html#1054754