FAQs: Server-Related Questions


Q. What should I do if my server "hangs" or "freezes"?

A. If your WebLogic Server "freezes," you will need to collect certain diagnostic information, including thread dumps and Java garbage collection metrics, before contacting BEA Technical Support. For details, see Generate a Log File and Check Garbage Collection.


Q. How do I configure WebLogic to use a SOCKS proxy?

A. You can configure a java.net socket to use SOCKS by setting a Java system property. For details, see How do I make Java work with a proxy server?. Once the property is set, WebLogic socket connections use the SOCKS proxy.


Q. How can I speed up connection responses?

A. Connection delays are often caused by DNS problems. WebLogic performs a reverse lookup on the hostname from which a new connection is made. If the DNS reverse lookup is not working properly because the connection is coming from a proxy server, it could be responsible for the delay. You might want to work with your system administrator to determine whether DNS and the third-party networking software are working properly. Try writing a simple server program that performs a reverse lookup on any connection made to it. If that lookup is delayed, then you know that the proxy server is the source of the problem.


Q. How does WebLogic support CORBA and client communication via IIOP?

A. "CORBA" support means many things to many people. It often means simply IIOP and ORB support and does not use many CORBA services. WebLogic supports CORBA in multiple ways. The WebLogic Server 8.1 implementation of RMI-IIOP allows you to: connect Java RMI clients to WebLogic Server using the standardized IIOP protocol; connect CORBA/IDL clients, including those written in C++, to WebLogic Server; interoperate between WebLogic Server and Tuxedo clients; connect a variety of clients to EJBs hosted on WebLogic Server. For more information, see Using WebLogic RMI over IIOP.


Q. How do I speed up HTTP tunneling?

A. Unfortunately, a significant performance hit occurs when you use HTTP tunneling. We have optimized it somewhat, but, because everything is encapsulated in HTTP, HTTP tunneling is slower than direct Java-to-Java TCP/IP connections.

Be sure that you really need to use HTTP tunneling. For example, if your firewall can pass IP packets through port 80, you can use the fast T3 protocol on port 80.

If use HTTP tunneling to go through a firewall, e-Border http://www.eborder.nec.com has a product that performs better than HTTP proxies.

Q. Can WebLogic Server start with a UNIX boot?

A. You can add a startup script to your UNIX rc scripts to run WebLogic Server at UNIX boot time. For information about creating startup scripts, refer to Starting an Administration Server Using a Script" in Administration Console Online Help.


Q. What affects servlet performance besides clients and traffic?

A. Response time for a servlet is about 5 times slower when you are running a screen saver on the machine, particularly for the OpenGL screen savers. Try turning off your screen saver and see if that helps!


Q. Why do I get "NoClassDefFound"/"Too Many Open files"messages on Solaris?

Problem: When I am using WebLogic Server on Solaris and try to run my application, I get a "NoClassDefFound" error, although the class causing the error does exist and is in the right directory. In fact, there are other classes in the same directory that are getting loaded. I also get a "Too many open files" error.

A. We have seen this situation when the user account runs out of file descriptors. On Solaris, each user account has a certain limited number of file descriptors. You can find out how many file descriptors you have with the limit command in csh.

You can increase file descriptors if you have enough privileges with the ulimit command in the csh. Otherwise, ask your system administrator to increase the file descriptors available to your processes.

Q. How do I increase WebLogic Server memory?

A. Increase the allocation of Java heap memory for WebLogic Server. (Set the minimum and the maximum to the same size.) This example starts the server with a fixed heap size of 200MB: 

  $ java ... -ms200m -mx200m ...

This allocates 32 megabytes of Java heap memory to WebLogic Server, which improves performance and allows WebLogic Server to handle more simultaneous connections. You can increase this value if necessary.

Q. Java-CORBA integration: RMI-IIOP or Java IDL?

A. It is important to understand the distinction between these two ways of integrating Java with CORBA.

RMI-IIOP is for Java programmers who want to program to the RMI interfaces but use IIOP as the underlying transport. RMI-IIOP provides interoperability with other CORBA objects implemented in various languages, but only if all the remote interfaces are originally defined as Java RMI interfaces. It is of particular interest to programmers using Enterprise JavaBeans , because the remote object model for EJB is RMI-based. It also allows you to use the standardized IIOP protocol and have a lightweight (minimal weblogic classes) client.

Java IDL is for CORBA programmers who want to program in Java based on interfaces defined in CORBA IDL. This is "business as usual" CORBA programming, supporting Java in exactly the same way as other languages like C++ or COBOL. If you want to integrate C++ (or any other language your orb supports into IDL) you would use the CORBA IDL method of programming.

Q. How do an RMI-IIOP application and an existing CORBA object interoperate?

A. If the existing CORBA object has its remote interfaces defined originally in CORBA IDL, then interoperability is not possible. RMI-IIOP applications can interoperate with other CORBA objects only when their remote interfaces are originally defined as Java RMI interfaces.

For example, to interoperate between an RMI-IIOP client and a C++ object you need to:

  1. Define the remote interface of the object in Java as an RMI interface..
  2. Run rmic -idl against the interface to produce IDL compatible with the RMI interface.
  3. Run a C++ stub compiler against the IDL file to produce the C++ skeleton for your C++ server object.

Q. What is the function of T3 in WebLogic Server?

A. T3 provides a framework for WebLogic Server messages that support for enhancements. These enhancements include abbreviations and features, such as object replacement, that work in the context of WebLogic Server clusters and HTTP and other product tunneling.

T3 predates Java Object Serialization and RMI, while closely tracking and leveraging these specifications. T3 is a superset of Java Object. Serialization or RMI; anything you can do in Java Object Serialization and RMI can be done over T3.

T3 is mandated between WebLogic Servers and between programmatic clients and a WebLogic Server cluster. HTTP and IIOP are optional protocols that can be used to communicate between other processes and WebLogic Server. It depends on what you want to do. For example, when you want to communicate between

  • A browser and WebLogic Server-use HTTP
  • An ORB and WebLogic Server-IIOP.

Q. How can I debug the Java code that I have running in WebLogic Server?

A. You can use tools such as WebGain, JBuilder, NetBeans and JDB that rely on the Java Platform Debugger Architecture (JPDA) to debug your Java code running in WebLogic Server.

JPDA is integrated in the Java 2 Platform, Standard Edition (J2SE) SDK 1.3 on all platforms and SDK 1.2.2 for Linux. There is a download available from Sun to add JPDA support to the J2SE SDK 1.2.2 on Solaris and Microsoft Window platforms. If you are using J2SE SDK 1.2.2 on these platforms first get this download.

To allow a debugger to attach to the virtual machine that WebLogic runs you have to start WebLogic in debug mode. In order to start WebLogic in debug mode using a Sun virtual machine follow these steps (start with step one only if using a Solaris platform):

  1. If using a Solaris platform, change the LD_LIBRARY_PATH environment variable to prepend $JAVA_HOME/lib/sparc: 
    export LD_LIBRARY_PATH=$JAVA_HOME/lib/sparc:$LD_LIBRARY_PATH
  2. Add the following parameters to the java command line (before the "weblogic.Server" string) that launches WebLogic server: 
    -Xdebug



    -Xnoagent



    -Xrunjdwp:transport=dt_socket



    server=y



    address=<port_for_debugger_to_connect>



    suspend=n



    -Djava.compiler=NONE

Note that with the Hotspot Performance engine the -Xnoagent and -Djava.compiler=NONE options are no longer required, but are accepted and ignored for compatibility reasons.

If server=y and no address parameter is supplied, WebLogic Server chooses the transport address and prints it to the standard output stream. So, if a line such as:

Listening for transport dt_socket at address: 46666

prints in your standard output stream when the server starts, the number 46666 is the port number to be supplied to your tool's remote debugger in order to attach it to WebLogic's virutal machine.

Skip navigation bar  Back to Top Previous Next